Nginx 一次性搞清楚Nginx處理HTTP請求的11個階段

原創 取个名太难了！ 2020-06-02 10:33

Nginx 處理一個 HTTP 請求的全過程

處理 HTTP 請求的階段了。先看下面這張圖，這張圖是 Nginx 處理 HTTP 請求的示意圖，雖然簡單，但是卻很好的說明了整個過程。

  1. Read Request Headers：解析請求頭。
  2. Identify Configuration Block：識別由哪一個 location 進行處理，匹配 URL。
  3. Apply Rate Limits：判斷是否限速。例如可能這個請求併發的連接數太多超過了限制，或者 QPS 太高。
  4. Perform Authentication：連接控制，驗證請求。例如可能根據 Referrer 頭部做一些防盜鏈的設置，或者驗證用戶的權限。
  5. Generate Content：生成返回給用戶的響應。爲了生成這個響應，做反向代理的時候可能會和上游服務（Upstream Services）進行通信，然後這個過程中還可能會有些子請求或者重定向，那麼還會走一下這個過程（Internal redirects and subrequests）。
  6. Response Filters：過濾返回給用戶的響應。比如壓縮響應，或者對圖片進行處理。
  7. Log：記錄日誌。

以上這七個步驟從整體上介紹了一下處理流程，下面還會再說一下實際的處理過程。

Nginx 處理 HTTP 請求的 11 個階段

下面介紹一下詳細的 11 個階段，每個階段都可能對應着一個甚至多個 HTTP 模塊，通過這樣一個模塊對比，我們也能夠很好的理解這些模塊具體是怎麼樣發揮作用的。

  1. POST_READ：在 read 完請求的頭部之後，在沒有對頭部做任何處理之前，想要獲取到一些原始的值，就應該在這個階段進行處理。這裏面會涉及到一個 realip 模塊。
  2. SERVER_REWRITE：和下面的 REWRITE 階段一樣，都只有一個模塊叫 rewrite 模塊，一般沒有第三方模塊會處理這個階段。
  3. FIND_CONFIG：做 location 的匹配，暫時沒有模塊會用到。
  4. REWRITE：對 URL 做一些處理。
  5. POST_WRITE：處於 REWRITE 之後，也是暫時沒有模塊會在這個階段出現。

接下來是確認用戶訪問權限的三個模塊：

  1. PREACCESS：是在 ACCESS 之前要做一些工作，例如併發連接和 QPS 需要進行限制，涉及到兩個模塊：limt_conn 和 limit_req
  2. ACCESS：核心要解決的是用戶能不能訪問的問題，例如 auth_basic 是用戶名和密碼，access 是用戶訪問 IP，auth_request 根據第三方服務返回是否可以去訪問。
  3. POST_ACCESS：是在 ACCESS 之後會做一些事情，同樣暫時沒有模塊會用到。

最後的三個階段處理響應和日誌：

  1. PRECONTENT：在處理 CONTENT 之前會做一些事情，例如會把子請求發送給第三方的服務去處理，try_files 模塊也是在這個階段中。
  2. CONTENT：這個階段涉及到的模塊就非常多了，例如 index, autoindex, concat 等都是在這個階段生效的。
  3. LOG：記錄日誌 access_log 模塊。

以上的這些階段都是嚴格按照順序進行處理的，當然，每個階段中各個 HTTP 模塊的處理順序也很重要，如果某個模塊不把請求向下傳遞，後面的模塊是接收不到請求的。而且每個階段中的模塊也不一定所有都要執行一遍，下面就接着講一下各個階段模塊之間的請求順序。

 

11 個階段的順序處理

如下圖所示，每一個模塊處理之間是有序的，那麼這個順序怎麼才能得到呢？其實非常簡單，在源碼 ngx_module.c 中，有一個數組 ngx_module_name，其中包含了在編譯 Nginx 的時候的 with 指令所包含的所有模塊，它們之間的順序非常關鍵，在數組中順序是相反的。

char *ngx_module_names[] = {
    … …
    "ngx_http_static_module",
    "ngx_http_autoindex_module",
    "ngx_http_index_module",
    "ngx_http_random_index_module",
    "ngx_http_mirror_module",
    "ngx_http_try_files_module",
    "ngx_http_auth_request_module",
    "ngx_http_auth_basic_module",
    "ngx_http_access_module",
    "ngx_http_limit_conn_module",
    "ngx_http_limit_req_module",
    "ngx_http_realip_module",
    "ngx_http_referer_module",
    "ngx_http_rewrite_module",
    "ngx_http_concat_module",
    … …
}

灰色部分的模塊是 Nginx 的框架部分去執行處理的，第三方模塊沒有機會在這裏得到處理。

在依次向下執行的過程中，也可能不按照這樣的順序。例如，在 access 階段中，有一個指令叫 satisfy，它可以指示當有一個滿足的時候就直接跳到下一個階段進行處理，例如當 access 滿足了，就直接跳到 try_files 模塊進行處理，而不會再執行 auth_basic、auth_request 模塊。

在 content 階段中，當 index 模塊執行了，就不會再執行 auto_index 模塊，而是直接跳到 log 模塊。

整個 11 個階段所涉及到的模塊和先後順序如下圖所示：

下面開始詳細講解一下各個階段。先來看下第一個階段 postread 階段，顧名思義，postread 階段是在正式處理請求之前起作用的。

postread 階段

postread 階段，是 11 個階段的第 1 個階段，這個階段剛剛獲取到了請求的頭部，還沒有進行任何處理，我們可以拿到一些原始的信息。例如，拿到用戶的真實 IP 地址

問題：如何拿到用戶的真實 IP 地址？

我們知道，TCP 連接是由一個四元組構成的，在四元組中，包含了源 IP 地址。而在真實的互聯網中，存在非常多的正向代理和反向代理。例如最終的用戶有自己的內網 IP 地址，運營商會分配一個公網 IP，然後訪問某個網站的時候，這個網站可能使用了 CDN 加速一些靜態文件或圖片，如果 CDN 沒有命中，那麼就會回源，回源的時候可能還要經過一個反向代理，例如阿里雲的 SLB，然後纔會到達 Nginx。

我們要拿到的地址應該是運營商給用戶分配的公網 IP 地址 115.204.33.1，對這個 IP 來進行併發連接的控制或者限速，而 Nginx 拿到的卻是 2.2.2.2，那麼怎麼才能拿到真實的用戶 IP 呢？

HTTP 協議中，有兩個頭部可以用來獲取用戶 IP：

  • X-Forwardex-For 是用來傳遞 IP 的，這個頭部會把經過的節點 IP 都記錄下來
  • X-Real-IP：可以記錄用戶真實的 IP 地址，只能有一個

拿到真實用戶 IP 後如何使用？

針對這個問題，Nginx 是基於變量來使用。

例如 binary_remote_addr、remote_addr 這樣的變量，其值就是真實的 IP，這樣做連接限制也就是 limit_conn 模塊纔有意義，這也說明了，limit_conn 模塊只能在 preaccess 階段，而不能在 postread 階段生效。

realip 模塊

  • 默認不會編譯進 Nginx

    • 需要通過 --with-http_realip_module 啓用功能

  • 變量：如果還想要使用原來的 TCP 連接中的地址和端口，需要通過這兩個變量保存

    • realip_remote_addr
    • realip_remote_port

  • 功能

    • 修改客戶端地址

  • 指令

    • set_real_ip_from

      指定可信的地址，只有從該地址建立的連接，獲取的 realip 纔是可信的

    • real_ip_header

      指定從哪個頭部取真實的 IP 地址，默認從 X-Real-IP 中取，如果設置從 X-Forwarded-For 中取，會先從最後一個 IP 開始取

    • real_ip_recursive

      環回地址，默認關閉，打開的時候，如果 X-Forwarded-For 最後一個地址與客戶端地址相同，會過濾掉該地址

Syntax: set_real_ip_from address | CIDR | unix:;
Default: —
Context: http, server, location

Syntax: real_ip_header field | X-Real-IP | X-Forwarded-For | proxy_protocol;
Default: real_ip_header X-Real-IP; 
Context: http, server, location

Syntax: real_ip_recursive on | off;
Default: real_ip_recursive off; 
Context: http, server, location

實戰

上面關於 real_ip_recursive 指令可能不太容易理解，我們來實戰練習一下，先來看 real_ip_recursive 默認關閉的情況：

  • 重新編譯一個帶有 realip 模塊的 nginx
關於如何編譯 Nginx，詳見：https://iziyang.github.io/202...
# 下載 nginx 源碼，在源碼目錄下執行
./configure --prefix=自己指定的目錄 --with-http_realip_module
make
make install
  • 然後去上一步中自己指定的 Nginx 安裝目錄
#屏蔽默認的 nginx.conf 文件的 server 塊內容，並添加一行
include /Users/mtdp/myproject/nginx/test_nginx/conf/example/*.conf;
# 在 example 目錄下建立 realip.conf，set_real_ip_from 可以設置爲自己的本機 IP
server {
    listen 80;
    server_name ziyang.realip.com;
    error_log /Users/mtdp/myproject/nginx/nginx/logs/myerror.log debug;
    set_real_ip_from 192.168.0.108;
    #real_ip_header X-Real-IP;
    real_ip_recursive off;
    # real_ip_recursive on;
    real_ip_header X-Forwarded-For;

    location / {
        return 200 "Client real ip: $remote_addr\n";
    }
}

在上面的配置文件中，我設置了可信代理地址爲本機地址，real_ip_recursive 爲默認的 off，real_ip_header 設爲從 X-Forwarded-For 中取。

  • 重載配置文件
./sbin/nginx -s reload
  • 測試響應結果
➜  test_nginx curl -H 'X-Forwarded-For: 1.1.1.1,192.168.0.108' ziyang.realip.com
Client real ip: 192.168.0.108

然後再來測試 real_ip_recursive 打開的情況：

  • 配置文件中打開 real_ip_recursive
server {
    listen 80;
    server_name ziyang.realip.com;
    error_log /Users/mtdp/myproject/nginx/nginx/logs/myerror.log debug;
    set_real_ip_from 192.168.0.108;
    #real_ip_header X-Real-IP;
    #real_ip_recursive off;
    real_ip_recursive on;
    real_ip_header X-Forwarded-For;

    location / {
        return 200 "Client real ip: $remote_addr\n";
    }
}
  • 測試響應結果
➜  test_nginx curl -H 'X-Forwarded-For: 1.1.1.1,2.2.2.2,192.168.0.108' ziyang.realip.com
Client real ip: 2.2.2.2

所以這裏面也可看出來，如果使用 X-Forwarded-For 獲取 realip 的話，需要打開 real_ip_recursive，並且，realip 依賴於 set_real_ip_from 設置的可信地址。

那麼有人可能就會問了，那直接用 X-Real-IP 來選取真實的 IP 地址不就好了。這是可以的，但是 X-Real-IP 是 Nginx 獨有的，不是 RFC 規範，如果客戶端與服務器之間還有其他非 Nginx 軟件實現的代理，就會造成取不到 X-Real-IP 頭部，所以這個要根據實際情況來定。

rewrite 階段的 rewrite 模塊

下面來看一下 rewrite 模塊。

首先 rewrite 階段分爲兩個，一個是 server_rewrite 階段，一個是 rewrite，這兩個階段都涉及到一個 rewrite 模塊，而在 rewrite 模塊中，有一個 return 指令，遇到該指令就不會再向下執行，直接返回響應。

return 指令

return 指令的語法如下：

  • 返回狀態碼，後面跟上 body
  • 返回狀態碼，後面跟上 URL
  • 直接返回 URL
Syntax: return code [text];
        return code URL;
        return URL;
Default: —
Context: server, location, if

返回狀態碼包括以下幾種：

  • Nginx 自定義

    • 444：立刻關閉連接，用戶收不到響應

  • HTTP 1.0 標準

    • 301：永久重定向
    • 302：臨時重定向，禁止被緩存

  • HTTP 1.1 標準

    • 303：臨時重定向，允許改變方法，禁止被緩存
    • 307：臨時重定向，不允許改變方法，禁止被緩存
    • 308：永久重定向，不允許改變方法

return 指令與 error_page

error_page 的作用大家肯定經常見到。當訪問一個網站出現 404 的時候，一般不會直接出現一個 404 NOT FOUND，而是會有一個比較友好的頁面，這就是 error_page 的功能。

Syntax: error_page code ... [=[response]] uri;
Default: —
Context: http, server, location, if in location

我們來看幾個例子：

1. error_page 404 /404.html; 
2. error_page 500 502 503 504 /50x.html;
3. error_page 404 =200 /empty.gif; 
4. error_page 404 = /404.php; 
5. location / { 
       error_page 404 = @fallback; 
   } 
   location @fallback { 
       proxy_pass http://backend; 
   } 
6. error_page 403 http://example.com/forbidden.html; 
7. error_page 404 =301 http://example.com/notfound.html;

那麼現在就會有兩個問題，大家看下下面這個配置文件：

server {
    server_name ziyang.return.com;
    listen 80;
    root html/;
    error_page 404 /403.html;
    #return 405;
    location / {
        #return 404 "find nothing!";
    }
}
  1. 當 server 下包含 error_page 且 location 下有 return 指令的時候，會執行哪一個呢？
  2. return 指令同時出現在 server 塊下和同時出現在 location 塊下，它們有合併關係嗎？

這兩個問題我們通過實戰驗證一下。

實戰

  • 將上面的配置添加到配置文件 return.conf
  • 在本機的 hosts 文件中綁定 ziyang.return.com 爲本地的 IP 地址
  • 訪問一個不存在的頁面
➜  test_nginx curl  ziyang.return.com/text
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>

這個時候可以看到，是 error_page 生效了，返回的響應是 403。

那麼假如打開了 location 下 return 指令的註釋呢？

  • 打開 return 指令註釋，reload 配置文件
  • 重新訪問頁面
➜  test_nginx curl  ziyang.return.com/text
find nothing!%

這時候，return 指令得到了執行。也就是第一個問題，當 server 下包含 error_page 且 location 下有 return 指令的時候，會執行 return 指令。

下面再看一下 server 下的 return 指令和 location 下的 return 指令會執行哪一個。

  • 打開 server 下 return 指令的註釋，reload 配置文件
  • 重新訪問頁面
➜  test_nginx curl  ziyang.return.com/text
<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>

針對上面兩個問題也就有了答案：

  1. 當 server 下包含 error_page 且 location 下有 return 指令的時候，會執行哪一個呢？

    會執行 location 下的 return 指令。

  2. return 指令同時出現在 server 塊下和同時出現在 location 塊下，它們有合併關係嗎？

    沒有合併關係，先遇到哪個 return 指令就先執行哪一個。

rewrite 指令

rewrite 指令用於修改用戶傳入 Nginx 的 URL。來看下 rewrite 的指令規則：

Syntax: rewrite regex replacement [flag];
Default: —
Context: server, location, if

它的功能主要有下面幾點：

  • 將 regex 指定的 URL 替換成 replacement 這個新的 URL

    • 可以使用正則表達式及變量提取
  • 當 replacement 以 http:// 或者 https:// 或者 $schema 開頭，則直接返回 302 重定向

  • 替換後的 URL 根據 flag 指定的方式進行處理

    • last：用 replacement 這個 URL 進行新的 location 匹配
    • break：break 指令停止當前腳本指令的執行，等價於獨立的 break 指令
    • redirect：返回 302 重定向
    • permanent：返回 301 重定向

指令示例

現在我們有這樣的一個目錄結構：

html/first/
└── 1.txt
html/second/
└── 2.txt
html/third/
└── 3.txt

配置文件如下所示：

server {
    listen 80;
    server_name rewrite.ziyang.com;
    rewrite_log on;
    error_log logs/rewrite_error.log notice;

    root html/;
    location /first {
        rewrite /first(.*) /second$1 last;
        return 200 'first!\n';
    }

    location /second {
        rewrite /second(.*) /third$1;
        return 200 'second!\n';
    }

    location /third {
        return 200 'third!\n';
    }
    location /redirect1 {
        rewrite /redirect1(.*) $1 permanent;
    }

    location /redirect2 {
        rewrite /redirect2(.*) $1 redirect;
    }

    location /redirect3 {
        rewrite /redirect3(.*) http://rewrite.ziyang.com$1;
    }

    location /redirect4 {
        rewrite /redirect4(.*) http://rewrite.ziyang.com$1 permanent;
    }
}

那麼我們的問題是：

  1. return 指令 與 rewrite 指令的順序關係？
  2. 訪問 /first/3.txt，/second/3.txt，/third/3.txt 分別返回的是什麼？
  3. 如果不攜帶 flag 會怎麼樣？

帶着這三個問題，我們來實際演示一下。

實戰

準備工作

  • 將上面的配置添加到配置文件 rewrite.conf
  • 在本機的 hosts 文件中綁定 rewrite.ziyang.com 爲 127.0.0.1

last flag

首先訪問 rewrite.ziyang.com/first/3.txt，結果如下：

➜  ~ curl rewrite.ziyang.com/first/3.txt
second!

爲什麼結果是 second! 呢？應該是 third! 呀，可能有人會有這樣的疑問。實際的匹配步驟如下：

  • curl rewrite.ziyang.com/first/3.txt
  • 由於 rewrite /first(.*) /second$1 last; 這條指令的存在，last 表示使用新的 URL 進行 location 匹配，因此接下來會去匹配 second/3.txt
  • 匹配到 /second 塊之後，會依次執行指令，最後返回 200
  • 注意，location 塊中雖然也改寫了 URL，但是並不會去繼續匹配，因爲後面沒有指定 flag。

break flag

下面將 rewrite /second(.*) /third$1; 這條指令加上 break flag，rewrite /second(.*) /third$1 break;

繼續訪問 rewrite.ziyang.com/first/3.txt，結果如下：

➜  ~ curl rewrite.ziyang.com/first/3.txt
test3%

這時候返回的是 3.txt 文件的內容 test3。實際的匹配步驟如下：

  • curl rewrite.ziyang.com/first/3.txt
  • 由於 rewrite /first(.*) /second$1 last; 這條指令的存在，last 表示使用新的 URL 進行 location 匹配，因此接下來會去匹配 second/3.txt
  • 匹配到 /second 塊之後，由於 break flag 的存在，會繼續匹配 rewrite 過後的 URL
  • 匹配 /third location

因此，這個過程實際請求的 URL 是 rewrite.ziyang.com/third/3.txt，這樣自然結果就是 test3 了。你還可以試試訪問 rewrite.ziyang.com/third/2.txt 看看會返回什麼。

redirect 和 permanent flag

配置文件中還有 4 個 location，你可以分別試着訪問一下，結果是這樣的：

  • redirect1：返回 301
  • redirect2：返回 302
  • redirect3：返回 302
  • redirect4：返回 301

rewrite 行爲記錄日誌

主要是一個指令 rewrite_log：

Syntax: rewrite_log on | off;
Default: rewrite_log off; 
Context: http, server, location, if

這個指令打開之後，會把 rewrite 的日誌寫入 logs/rewrite_error.log 日誌文件中，這是請求 /first/3.txt 的日誌記錄：

2020/05/06 06:24:05 [notice] 86959#0: *25 "/first(.*)" matches "/first/3.txt", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 rewritten data: "/second/3.txt", args: "", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 "/second(.*)" matches "/second/3.txt", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 rewritten data: "/third/3.txt", args: "", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"

if 指令

if 指令也是在 rewrite 階段生效的，它的語法如下所示：

Syntax: if (condition) { ... }
Default: —
Context: server, location

它的規則是：

  • 條件 condition 爲真，則執行大括號內的指令；同時還遵循值指令的繼承規則（詳見我之前的文章 Nginx 的配置指令）

那麼 if 指令的條件表達式包含哪些內容呢？它的規則如下：

  1. 檢查變量爲空或者值是否爲 0
  2. 將變量與字符串做匹配，使用 = 或 !=

  3. 將變量與正則表達式做匹配

    • 大小寫敏感，~ 或者 !~
    • 大小寫不敏感，~ 或者 !~
  4. 檢查文件是否存在，使用 -f 或者 !-f
  5. 檢查目錄是否存在，使用 -d 或者 !-d
  6. 檢查文件、目錄、軟鏈接是否存在，使用 -e 或者 !-e
  7. 檢查是否爲可執行文件，使用 -x 或者 !-x

下面是一些例子：

if ($http_user_agent ~ MSIE) { # 與變量 http_user_agent 匹配
    rewrite ^(.*)$ /msie/$1 break; 
} 
if ($http_cookie ~* "id=([^;]+)(?:;|$)") { # 與變量 http_cookie 匹配
    set $id $1; 
} 
if ($request_method = POST) { # 與變量 request_method 匹配，獲取請求方法
    return 405; 
} 
if ($slow) { # slow 變量在 map 模塊中自定義，也可以進行匹配
    limit_rate 10k; 
} 
if ($invalid_referer) { 
    return 403; 
}

find_config 階段

當經過 rewrite 模塊，匹配到 URL 之後，就會進入 find_config 階段，開始尋找 URL 對應的 location 配置。

location 指令

指令語法

還是老規矩，咱們先來看一下 location 指令的語法：

Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
        location @name { ... }
Default: —
Context: server, location

Syntax: merge_slashes on | off;
Default: merge_slashes on; 
Context: http, server

這裏面有一個 merge_slashes 指令，這個指令的作用是，加入 URL 中有兩個重複的 /，那麼會合併爲一個，這個指令默認是打開的，只有當對 URL 進行 base64 之類的編碼時才需要關閉。

匹配規則

location 的匹配規則是僅匹配 URI，忽略參數，有下面三種大的情況：

  • 前綴字符串

    • 常規匹配
    • =：精確匹配
    • ^~：匹配上後則不再進行正則表達式匹配

  • 正則表達式

    • ~：大小寫敏感的正則匹配
    • ~*：大小寫不敏感

  • 用戶內部跳轉的命名 location

    • @

對於這些規則剛看上去肯定是很懵的，完全不知道在說什麼，下面來實戰看幾個例子。

實戰

先看一下 Nginx 的配置文件：

server {
    listen 80;
    server_name location.ziyang.com;
    error_log  logs/error.log  debug;
    #root html/;
    default_type text/plain;
    merge_slashes off;
    
    location ~ /Test1/$ {
        return 200 'first regular expressions match!\n';
    }
    location ~* /Test1/(\w+)$ {
        return 200 'longest regular expressions match!\n';
    }
    location ^~ /Test1/ {
        return 200 'stop regular expressions match!\n';
    }
    location /Test1/Test2 {
        return 200 'longest prefix string match!\n';
    }
    location /Test1 {
        return 200 'prefix string match!\n';
    }
    location = /Test1 {
        return 200 'exact match!\n';
    }
}

問題就來了，訪問下面幾個 URL 會分別返回什麼內容呢？

/Test1
/Test1/
/Test1/Test2
/Test1/Test2/
/test1/Test2

例如訪問 /Test1 時，會有幾個部分都匹配上：

  1. 常規前綴匹配：location /Test1
  2. 精確匹配：location = /Test1

訪問 /Test1/ 時，也會有幾個部分匹配上：

  1. location ~ /Test1/$
  2. location ^~ /Test1/

那麼究竟會匹配哪一個呢？Nginx 其實是遵循一套規則的，如下圖所示：

全部的前綴字符串是放置在一棵二叉樹中的，Nginx 會分爲兩部分進行匹配：

  1. 先遍歷所有的前綴字符串，選取最長的一個前綴字符串，如果這個字符串是 = 的精確匹配或 ^~ 的前綴匹配，會直接使用
  2. 如果第一步中沒有匹配上 = 或 ^~，那麼會先記住最長匹配的前綴字符串 location
  3. 按照 nginx.conf 文件中的配置依次匹配正則表達式
  4. 如果所有的正則表達式都沒有匹配上，那麼會使用最長匹配的前綴字符串

下面看下實際的響應是怎麼樣的：

➜  test_nginx curl location.ziyang.com/Test1
exact match!
➜  test_nginx curl location.ziyang.com/Test1/
stop regular expressions match!
➜  test_nginx curl location.ziyang.com/Test1/Test2
longest regular expressions match!
➜  test_nginx curl location.ziyang.com/Test1/Test2/
longest prefix string match!
➜  test_nginx curl location.ziyang.com/Test1/Test3
stop regular expressions match!
  • /Test1 匹配 location = /Test1
  • /Test1/ 匹配 location ^~ /Test1/
  • /Test1/Test2 匹配 location ~* /Test1/(w+)$
  • /Test1/Test2/ 匹配 location /Test1/Test2
  • /Test1/Test3 匹配 location ^~ /Test1/

這裏面重點解釋一下 /Test1/Test3 的匹配過程：

  1. 遍歷所有可以匹配上的前綴字符串，總共有兩個

    • ^~ /Test1/
    • /Test1
  2. 選取最長的前綴字符串 /Test1/，由於前面有 ^~ 禁止正則表達式匹配，因此直接使用 location ^~ /Test1/ 的規則
  3. 返回 stop regular expressions match!

preaccess 階段

下面就來到了 preaccess 階段。我們經常會遇到一個問題，就是如何限制每個客戶端的併發連接數？如何限制訪問頻率？這些就是在 preaccess 階段處理完成的，顧名思義，preaccess 就是在連接之前。先來看下 limit_conn 模塊。

limit_conn 模塊

這裏面涉及到的模塊是 ngx_http_limit_conn_module，它的基本特性如下：

  • 生效階段：NGX_HTTP_PREACCESS_PHASE 階段
  • 模塊：http_limit_conn_module
  • 默認編譯進 Nginx，通過 --without-http_limit_conn_module 禁用

  • 生效範圍

    • 全部 worker 進程（基於共享內存）
    • 進入 preaccess 階段前不生效
    • 限制的有效性取決於 key 的設計：依賴 postread 階段的 realip 模塊取到真實 IP

這裏面有一點需要注意，就是 limit_conn key 的設計，所謂的 key 指的就是對哪個變量進行限制，通常我們取的都是用戶的真實 IP。

說完了 limit_conn 的模塊，再來說一下指令語法。

指令語法

  • 定義共享內存（包括大小），以及 key 關鍵字
Syntax: limit_conn_zone key zone=name:size;
Default: —
Context: http
  • 限制併發連接數
Syntax: limit_conn zone number;
Default: —
Context: http, server, location
  • 限制發生時的日誌級別
Syntax: limit_conn_log_level info | notice | warn | error;
Default: limit_conn_log_level error; 
Context: http, server, location
  • 限制發生時向客戶端返回的錯誤碼
Syntax: limit_conn_status code;
Default: limit_conn_status 503; 
Context: http, server, location

實戰

下面又到了實戰的環節了，通過一個實際的例子來看一下以上的幾個指令是怎麼起作用的。

老規矩，先上配置文件：

limit_conn_zone $binary_remote_addr zone=addr:10m;
#limit_req_zone $binary_remote_addr zone=one:10m rate=2r/m;

server {
    listen 80;
    server_name limit.ziyang.com;
    root html/;
    error_log logs/myerror.log info;
    location /{
        limit_conn_status 500;
        limit_conn_log_level  warn;
        limit_rate 50;
        limit_conn addr 1;
        #limit_req zone=one burst=3 nodelay;
        #limit_req zone=one;
    }
}
  • 在本地的 hosts 文件中添加 limit.ziyang.com 爲本機 IP

在這個配置文件中，做了兩條限制，一個是 limit_rate 限制爲 50 個字節，併發連接數 limit_conn 限制爲 1。

➜ test_nginx curl limit.ziyang.com

這時候訪問 limit.ziyang.com 這個站點，會發現速度非常慢，因爲每秒鐘只有 50 個字節。

如果再同時訪問這個站點的話，則會返回 500。

我在另一個終端裏面同時訪問：

➜  ~ curl limit.ziyang.com
<html>
<head><title>500 Internal Server Error</title></head>
<body>
<center><h1>500 Internal Server Error</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>

可以看到，Nginx 直接返回了 500。

limit_req 模塊

在本節開頭我們就提出了兩個問題：

  • 如何限制每個客戶端的併發連接數？
  • 如何限制訪問頻率？

第一個問題限制併發連接數的問題已經解決了，下面來看第二個問題。

這裏面生效的模塊是 ngx_http_limit_req_module，它的基本特性如下：

  • 生效階段：NGX_HTTP_PREACCESS_PHASE 階段
  • 模塊：http_limit_req_module
  • 默認編譯進 Nginx，通過 --without-http_limit_req_module 禁用
  • 生效算法：leaky bucket 算法

  • 生效範圍

    • 全部 worker 進程（基於共享內存）
    • 進入 preaccess 階段前不生效

leaky bucket 算法

leaky bucket 叫漏桶算法，其他用來限制請求速率的還有令牌環算法等，這裏面不展開講。

漏桶算法的原理是，先定義一個桶的大小，所有進入桶內的請求都會以恆定的速率被處理，如果請求太多超出了桶的容量，那麼就會立刻返回錯誤。用一張圖解釋一下。

這張圖裏面，水龍頭在不停地滴水，就像用戶發來的請求，所有的水滴都會以恆定的速率流出去，也就是被處理。漏桶算法對於突發流量有很好的限制作用，會將所有的請求平滑的處理掉。

指令語法

  • 定義共享內存（包括大小），以及 key 關鍵字和限制速率
Syntax: limit_req_zone key zone=name:size rate=rate ;
Default: —
Context: http
rate 單位爲 r/s 或者 r/m（每分鐘或者每秒處理多少個請求）
  • 限制併發連接數
Syntax: limit_req zone=name [burst=number] [nodelay];
Default: —
Context: http, server, location
  • burst 默認爲 0
  • nodelay，如果設置了這個參數，那麼對於漏桶中的請求也會立刻返回錯誤
  • 限制發生時的日誌級別
Syntax: limit_req_log_level info | notice | warn | error;
Default: limit_req_log_level error; 
Context: http, server, location
  • 限制發生時向客戶端返回的錯誤碼
Syntax: limit_req_status code;
Default: limit_req_status 503; 
Context: http, server, location

實戰

在實際驗證之前呢，需要注意兩個問題：

  • limit_req 與 limit_conn 配置同時生效時，哪個優先級高？
  • nodelay 添加與否，有什麼不同？

添加配置文件，這個配置文件與上一節的配置文件其實是相同的只不過需要註釋一下：

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_req_zone $binary_remote_addr zone=one:10m rate=2r/m;

server {
    listen 80;
    server_name limit.ziyang.com;
    root html/;
    error_log logs/myerror.log info;
    
    location /{
        limit_conn_status 500;
        limit_conn_log_level  warn;
        #limit_rate 50;
        #limit_conn addr 1;
        #limit_req zone=one burst=3 nodelay;
        limit_req zone=one;
    }
}

結論：在 limit_req zone=one 指令下，超出每分鐘處理的請求數後就會立刻返回 503。

➜  test_nginx curl limit.ziyang.com
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>

改變一下注釋的指令：

limit_req zone=one burst=3;
#limit_req zone=one;

在沒有添加 burst 參數時，會立刻返回錯誤，而加上之後，不會返回錯誤，而是等待請求限制解除，直到可以處理請求時再返回。

再來看一下 nodelay 參數：

limit_req zone=one burst=3 nodelay;

添加了 nodelay 之後，請求在沒有達到 burst 限制之前都可以立刻被處理並返回，超出了 burst 限制之後，纔會返回 503。

現在可以回答一下剛開始提出的兩個問題：

  • limit_req 與 limit_conn 配置同時生效時，哪個優先級高？

    • limit_req 在 limit_conn 處理之前，因此是 limit_req 會生效

  • nodelay 添加與否，有什麼不同？

    • 不添加 nodelay，請求會等待，直到能夠處理請求；添加 nodelay，在不超出 burst 的限制的情況下會立刻處理並返回，超出限制則會返回 503。

access 階段

經過 preaccess 階段對用戶的限流之後，就到了 access 階段。

access 模塊

這裏面涉及到的模塊是 ngx_http_access_module，它的基本特性如下：

  • 生效階段：NGX_HTTP_ACCESS_PHASE 階段
  • 模塊：http_access_module
  • 默認編譯進 Nginx，通過 --without-http_access_module 禁用

  • 生效範圍

    • 進入 access 階段前不生效

指令語法

Syntax: allow address | CIDR | unix: | all;
Default: —
Context: http, server, location, limit_except

Syntax: deny address | CIDR | unix: | all;
Default: —
Context: http, server, location, limit_except

access 模塊提供了兩條指令 allow 和 deny，來看幾個例子：

location / { 
    deny 192.168.1.1; 
    allow 192.168.1.0/24; 
    allow 10.1.1.0/16; 
    allow 2001:0db8::/32; 
    deny all; 
}

對於用戶訪問來說，這些指令是順序執行的，當滿足了一條之後，就不會再向下執行。這個模塊比較簡單，我們這裏不做實戰演練了。

auth_basic 模塊

auth_basic 模塊是用作用戶認證的，當開啓了這個模塊之後，我們通過瀏覽器訪問網站時，就會返回一個 401 Unauthorized，當然這個 401 用戶不會看見，瀏覽器會彈出一個對話框要求輸入用戶名和密碼。這個模塊使用的是 RFC2617 中的定義。

指令語法

  • 基於 HTTP Basic Authutication 協議進行用戶密碼的認證

  • 默認編譯進 Nginx

    • --without-http_auth_basic_module
    • disable ngx_http_auth_basic_module
Syntax: auth_basic string | off;
Default: auth_basic off; 
Context: http, server, location, limit_except

Syntax: auth_basic_user_file file;
Default: —
Context: http, server, location, limit_except

這裏面我們會用到一個工具叫 htpasswd，這個工具可以用來生成密碼文件，而 auth_basic_user_file 就依賴這個密碼文件。

htpasswd 依賴安裝包 httpd-tools

生成密碼的命令爲：

htpasswd –c file –b user pass

生成的密碼文件的格式爲：

# comment 
name1:password1 
name2:password2:comment 
name3:password3

實戰

  • 在 example 目錄下生成密碼文件 auth.pass
htpasswd -bc auth.pass ziyang 123456
  • 添加配置文件
server {
    server_name access.ziyang.com;
    listen 80;
    error_log  logs/error.log  debug;
    default_type text/plain;
    location /auth_basic {
        satisfy any;
        auth_basic "test auth_basic";
        auth_basic_user_file example/auth.pass;
        deny all;
    }
}
  • 重載 Nginx 配置文件
  • 在 /etc/hosts 文件中添加 access.ziyang.com

這時候訪問 access.ziyang.com 就會彈出對話框，提示輸入密碼：

auth_request 模塊

  • 功能：向上遊的服務轉發請求，若上游服務返回的響應碼是 2xx，則繼續執行，若上游服務返回的響應碼是 2xx，則繼續執行，若上游服務返回的是 401 或者 403，則將響應返回給客戶端
  • 原理：收到請求後，生成子請求，通過反向代理技術把請求傳遞給上游服務
  • 默認未編譯進 Nginx，需要通過 --with-http_auth_request_module 編譯進去

指令語法

Syntax: auth_request uri | off;
Default: auth_request off; 
Context: http, server, location

Syntax: auth_request_set $variable value;
Default: —
Context: http, server, location

實戰

  • 在上一個配置文件中添加以下內容
server {
    server_name access.ziyang.com;
    listen 80;
    error_log  logs/error.log  debug;
    #root html/;
    default_type text/plain;
    location /auth_basic {
        satisfy any;
        auth_basic "test auth_basic";
        auth_basic_user_file example/auth.pass;
        deny all;
    }
    location / {
        auth_request /test_auth;
    }
    location = /test_auth {
        proxy_pass http://127.0.0.1:8090/auth_upstream;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }
}
  • 這個配置文件中，/ 路徑下會將請求轉發到另外一個服務中去，可以用 nginx 再搭建一個服務
  • 如果這個服務返回 2xx，那麼鑑權成功，如果返回 401 或 403 則鑑權失敗

限制所有 access 階段模塊的 satisfy 指令

指令語法

Syntax: satisfy all | any;
Default: satisfy all; 
Context: http, server, location

satisfy 指令有兩個值一個是 all，一個是 any，這個模塊對 acces 階段的三個模塊都生效：

  • access 模塊
  • auth_basic 模塊
  • auth_request 模塊
  • 其他模塊

如果 satisfy 指令的值是 all 的話，就表示必須所有 access 階段的模塊都要執行，都通過了纔會放行；值是 any 的話，表示有任意一個模塊得到執行即可。

下面有幾個問題可以加深一下理解：

  1. 如果有 return 指令，access 階段會生效嗎？

    return 指令屬於 rewrite 階段，在 access 階段之前，因此不會生效。

  2. 多個 access 模塊的順序有影響嗎？

    ngx_http_auth_request_module,
ngx_http_auth_basic_module,
ngx_http_access_module,

    有影響

  3. 輸對密碼，下面可以訪問到文件嗎？

    location /{
    satisfy any;
    auth_basic "test auth_basic";
    auth_basic_user_file examples/auth.pass;
    deny all;
}

    可以訪問到，因爲 satisfy 的值是 any，因此只要有模塊滿足，即可放行。

  4. 如果把 deny all 提到 auth_basic 之前呢？

    依然可以，因爲各個模塊執行順序和指令的順序無關。

  5. 如果改爲 allow all，有機會輸入密碼嗎？

    沒有機會，因爲 allow all 是 access 模塊，先於 auth_basic 模塊執行。

precontent 階段

講到了這裏，我們再來回顧一下 Nginx 處理 HTTP 請求的 11 個階段：

現在我們已經來到了 precontent 階段，這個階段只有 try_files 這一個指令。

try_files 模塊

指令語法

Syntax: try_files file ... uri;
        try_files file ... =code;
Default: —
Context: server, location
  • 模塊：ngx_http_try_files_module 模塊
  • 依次試圖訪問多個 URL 對應的文件（由 root 或者 alias 指令指定），當文件存在時，直接返回文件內容，如果所有文件都不存在，則按照最後一個 URL 結果或者 code 返回

實戰

下面我們實際看一個例子：

server {
    server_name tryfiles.ziyang.com;
    listen 80;
    error_log  logs/myerror.log  info;
    root html/;
    default_type text/plain;
    location /first {
        try_files /system/maintenance.html
            $uri $uri/index.html $uri.html
            @lasturl;
    }
    location @lasturl {
        return 200 'lasturl!\n';
    }
    location /second {
        try_files $uri $uri/index.html $uri.html =404;
    }
}

結果如下：

  • 訪問 /first 實際上到了 lasturl，然後返回 200
  • 訪問 /second 則返回了 404

這兩個結果都與配置文件是一致的。

➜  test_nginx curl tryfiles.ziyang.com/second
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>
➜  test_nginx curl tryfiles.ziyang.com/first 
lasturl!

mirror 模塊

mirror 模塊可以實時拷貝流量，這對於需要同時訪問多個環境的請求是非常有用的。

指令語法

  • 模塊：ngx_http_mirror_module 模塊，默認編譯進 Nginx

    • 通過 --without-http_mirror_module 移除模塊
  • 功能：處理請求時，生成子請求訪問其他服務，對子請求的返回值不做處理
Syntax: mirror uri | off;
Default: mirror off; 
Context: http, server, location

Syntax: mirror_request_body on | off;
Default: mirror_request_body on; 
Context: http, server, location

實戰

  • 配置文件如下所示，需要再開啓另外一個 Nginx 來接收請求
server {
    server_name mirror.ziyang.com;
    listen 8001;
    error_log logs/error_log debug;
    location / {
        mirror /mirror;
        mirror_request_body off;
    }
    location = /mirror {
        internal;
        proxy_pass http://127.0.0.1:10020$request_uri;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }
}
  • 在 access.log 文件中可以看到有請求記錄日誌

content 階段

下面開始就到了 content 階段，先來看 content 階段的 static 模塊，雖然這是位於 content 階段的最後一個處理模塊，但是這裏先來介紹它。

static 模塊

root 和 alias 指令

先來一下 root 和 alias 這兩個指令，這兩個指令都是用來映射文件路徑的。

Syntax: alias path;
Default: —
Context: location
Syntax: root path;
Default: root html; 
Context: http, server, location, if in location
  • 功能：將 URL 映射爲文件路徑，以返回靜態文件內容
  • 差別：root 會將完整 URL 映射進文件路徑中，alias 只會將 location 後的 URL 映射到文件路徑

實戰

下面來看一個問題：

現在有一個文件路徑：

html/first/
└── 1.txt

配置文件如下所示：

server {
    server_name static.ziyang.com;
    listen 80;
    error_log  logs/myerror.log  info;
    location /root {
        root html;
    }
    location /alias {
        alias html;
    }
    location ~ /root/(\w+\.txt) {
        root html/first/$1;
    }
    location ~ /alias/(\w+\.txt) {
        alias html/first/$1;
    }
    location  /RealPath/ {
        alias html/realpath/;
        return 200 '$request_filename:$document_root:$realpath_root\n';
    }
}

那麼訪問以下 URL 會得到什麼響應呢？

/root
/alias
/root/1.txt
/alias/1.txt
➜  test_nginx curl static.ziyang.com/alias/1.txt
test1%
➜  test_nginx curl static.ziyang.com/alias/     
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
➜  test_nginx curl static.ziyang.com/root/      
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>
➜  test_nginx curl static.ziyang.com/root/1.txt
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>

訪問這四個路徑分別得到的結果是：

  • /root：404
  • /alias：200
  • /root/1.txt：404
  • /alias/1.txt：200

這是爲什麼呢？是因爲，root 在映射 URL 時，會把 location 中的路徑也加進去，也就是：

  • static.ziyang.com/root/ 實際訪問的是 html/root/
  • static.ziyang.com/root/1.txt 實際是 html/first/1.txt/root/1.txt
  • static.ziyang.com/alias/ 實際上是正確訪問到了 html 文件夾，由於後面有 / 的存在，因此實際訪問的是 html/index.html
  • static.ziyang.com/alias/1.txt 實際訪問的是 html/first/1.txt，文件存在

三個相關變量

還是上面的配置文件：

location  /RealPath/ {
    alias html/realpath/;
    return 200 '$request_filename:$document_root:$realpath_root\n';
}

這裏有一個問題，在訪問 /RealPath/1.txt 時，這三個變量的值各爲多少？

爲了解答這個問題，我們先來解釋三個變量：

  • request_filename：待訪問文件的完整路徑
  • document_root：由 URI 和 root/alias 指令生成的文件夾路徑（可能包含軟鏈接的路徑）
  • realpath_root：將 document_root 中的軟鏈接替換成真實路徑

爲了驗證這三個變量，在 html 目錄下建立一個軟鏈接指向 first 文件夾：

ln -s first realpath
➜  html curl static.ziyang.com/realpath/1.txt
/Users/mtdp/myproject/nginx/test_nginx/html/realpath/1.txt:/Users/mtdp/myproject/nginx/test_nginx/html/realpath/:/Users/mtdp/myproject/nginx/test_nginx/html/first

可以看出來，三個路徑分別是：

  • /Users/mtdp/myproject/nginx/test_nginx/html/realpath/1.txt
  • /Users/mtdp/myproject/nginx/test_nginx/html/realpath/
  • /Users/mtdp/myproject/nginx/test_nginx/html/first

還有其他的一些配置指令，例如：

靜態文件返回時的 Content-Type

Syntax: types { ... }
Default: types { text/html html; image/gif gif; image/jpeg jpg; } 
Context: http, server, location

Syntax: default_type mime-type;
Default: default_type text/plain; 
Context: http, server, location

Syntax: types_hash_bucket_size size;
Default: types_hash_bucket_size 64; 
Context: http, server, location

Syntax: types_hash_max_size size;
Default: types_hash_max_size 1024; 
Context: http, server, location

未找到文件時的錯誤日誌

Syntax: log_not_found on | off;
Default: log_not_found on; 
Context: http, server, location

在生產環境中，經常可能會有找不到文件的情況，錯誤日誌中就會打印出來：

[error] 10156#0: *10723 open() "/html/first/2.txt/root/2.txt" failed (2: No such file or directory)

如果不想記錄日誌，可以關掉。

重定向跳轉的域名

現在有另外一個問題，當我們訪問目錄時最後沒有帶 /，static 模塊會返回 301 重定向，那麼這個規則是怎麼定義的呢，看下面三個指令：

# 該指令決定重定向時的域名，可以決定返回哪個域名
Syntax: server_name_in_redirect on | off;
Default: server_name_in_redirect off; 
Context: http, server, location
# 該指令決定重定向時的端口
Syntax: port_in_redirect on | off;
Default: port_in_redirect on; 
Context: http, server, location
# 該指令決定是否填域名，默認是打開的，也就是返回絕對路徑
Syntax: absolute_redirect on | off;
Default: absolute_redirect on; 
Context: http, server, location

這三個指令的實際用法來實戰演示一下，先來看配置文件：

server {
    server_name return.ziyang.com dir.ziyang.com;
    server_name_in_redirect on;
    listen 8088;
    port_in_redirect on;
    absolute_redirect off;

    root html/;
}

absolute_redirect 默認是打開的，我們把它關閉了，看下是怎麼返回的：

➜  test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.17.8
Date: Tue, 12 May 2020 00:31:36 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: /first/

這個時候看到返回的頭部 Location 中沒有加上域名。

下面再把 absolute_redirect 打開（默認是打開的，因此註釋掉就行了），看下返回什麼：

  • absolute_redirect on
  • server_name_in_redirect on
  • port_in_redirect on
➜  test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.17.8
Date: Tue, 12 May 2020 00:35:49 GMT
Content-Type: text/html
Content-Length: 169
Location: http://return.ziyang.com:8088/first/
Connection: keep-alive

可以看到，這時候就返回了域名，而且返回的是我們配置的主域名加端口號，這是因爲，server_name_in_redirect 和 port_in_redirect 這兩個指令打開了，如果關閉掉這兩個指令，看下返回什麼：

  • absolute_redirect on
  • server_name_in_redirect off
  • port_in_redirect off
➜  test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.17.8
Date: Tue, 12 May 2020 00:39:31 GMT
Content-Type: text/html
Content-Length: 169
Location: http://localhost/first/
Connection: keep-alive

這兩個指令都設置爲 off 之後，會發現返回的不再是主域名加端口號，而是我們請求的域名和端口號，如果在請求頭中加上 Host，那麼就會用 Host 請求頭中的域名。

index 模塊

  • 模塊：ngx_http_index_module
  • 功能：指定 / 結尾的目錄訪問時，返回 index 文件內容

  • 語法：

    Syntax: index file ...;
Default: index index.html; 
Context: http, server, location
  • 先於 autoindex 模塊執行

這個模塊，當我們訪問以 / 結尾的目錄時，會去找 root 或 alias 指令的文件夾下的 index.html，如果有這個文件，就會把文件內容返回，也可以指定其他文件。

autoindex 模塊

  • 模塊：ngx_http_autoindex_module，默認編譯進 Nginx，使用 --without-http_autoindex_module 取消
  • 功能：當 URL 以 / 結尾時，嘗試以 html/xml/json/jsonp 等格式返回 root/alias 中指向目錄的目錄結構

  • 語法：

    # 開啓或關閉
Syntax: autoindex on | off;
Default: autoindex off; 
Context: http, server, location
# 當以 HTML 格式輸出時，控制是否轉換爲 KB/MB/GB
Syntax: autoindex_exact_size on | off;
Default: autoindex_exact_size on; 
Context: http, server, location
# 控制以哪種格式輸出
Syntax: autoindex_format html | xml | json | jsonp;
Default: autoindex_format html; 
Context: http, server, location
# 控制是否以本地時間格式顯示還是 UTC 格式
Syntax: autoindex_localtime on | off;
Default: autoindex_localtime off; 
Context: http, server, location

實戰

  • 配置文件如下：
server {
    server_name autoindex.ziyang.com;
    listen 8080;
    location / {
        alias html/;
        autoindex on;
        #index b.html;
        autoindex_exact_size on;
        autoindex_format html;
        autoindex_localtime on;
    }
}

這裏我把 index b.html 這條指令給註釋掉了，而 index 模塊是默認編譯進 Nginx 的，且默認指令是 index index.html，因此，會去找是否有 index.html 這個文件。

  • 打開瀏覽器，訪問 autoindex.ziyang.com:8080，html 目錄下默認是有 index.html 文件的，因此顯示結果爲：

  • 打開 index b.html 指令註釋。由於 html 文件夾下並不存在 b.html 這個文件，所以請求會走到 autoindex 模塊，顯示目錄：

後面的文件大小顯示格式就是由 autoindex_exact_size on; 這條指令決定的。

concat模塊

下面介紹一個可以提升小文件性能的模塊，這個模塊是由阿里巴巴開發的，在淘寶網中有廣泛應用。

  • 模塊：ngx_http_concat_module
  • 模塊開發者：Tengine(https://github.com/alibaba/ng... --add-module=../nginx-http-concat/
  • 功能：合併多個小文件請求，可以明顯提升 HTTP 請求的性能

  • 指令：

    #在 URI 後面加上 ??，通過 ”,“ 分割文件，如果還有參數，則在最後通過 ? 添加參數
concat on | off
default concat off
Context http, server, location

concat_types MIME types
Default concat_types: text/css application/x-javascript
Context http, server, location

concat_unique on | off
Default concat_unique on
Context http, server, location

concat_max_files numberp
Default concat_max_files 10
Context http, server, location

concat_delimiter string
Default NONE
Context http, server, locatione
concat_ignore_file_error on | off
Default off
Context http, server, location

打開淘寶主頁，會發現小文件都是通過這個模塊來提高性能的：

這裏就不做實戰了，感興趣的同學可以自己去編譯一下這個模塊，做一下實驗，我把配置文件放在這裏：

server {
    server_name concat.ziyang.com;
    error_log logs/myerror.log debug;
    concat on;
    root html;
    location /concat {
        concat_max_files 20;
        concat_types text/plain;
        concat_unique on;
        concat_delimiter ':::';
        concat_ignore_file_error on;
    }
}

log 階段

下面終於來到了 11 個階段的最後一個階段，記錄請求訪問日誌的 log 模塊。

  • 功能：將 HTTP 請求相關信息記錄到日誌
  • 模塊：ngx_http_log_module，無法禁用

access 日誌格式

Syntax: log_format name [escape=default|json|none] string ...;
Default: log_format combined "..."; 
Context: http

默認的 combined 日誌格式：

log_format combined '$remote_addr - $remote_user [$time_local] ' 
'"$request" $status $body_bytes_sent ' '"$http_referer" 
"$http_user_agent"';

配置日誌文件路徑

Syntax: access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
        access_log off;
Default: access_log logs/access.log combined; 
Context: http, server, location, if in location, limit_except
  • path 路徑可以包含變量：不打開 cache 時每記錄一條日誌都需要打開、關閉日誌文件
  • if 通過變量值控制請求日誌是否記錄

  • 日誌緩存

    • 功能：批量將內存中的日誌寫入磁盤
    • 寫入磁盤的條件：

      所有待寫入磁盤的日誌大小超出緩存大小；

      達到 flush 指定的過期時間；

      worker 進程執行 reopen 命令，或者正在關閉。

  • 日誌壓縮

    • 功能：批量壓縮內存中的日誌，再寫入磁盤
    • buffer 大小默認爲 64KB
    • 壓縮級別默認爲 1（1最快壓縮率最低，9最慢壓縮率最高）
    • 打開日誌壓縮時，默認打開日誌緩存功能

對日誌文件名包含變量時的優化

Syntax: open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
        open_log_file_cache off;
Default: open_log_file_cache off; 
Context: http, server, location
  • max：緩存內的最大文件句柄數，超出後用 LRU 算法淘汰
  • inactive：文件訪問完後在這段時間內不會被關閉。默認 10 秒
  • min_uses：在 inactive 時間內使用次數超過 min_uses 纔會繼續存在內存中。默認 1
  • valid：超出 valid 時間後，將對緩存的日誌文件檢查是否存在。默認 60 秒
  • off：關閉緩存功能

日誌模塊沒有實戰。

到了這裏，我們已經將 Nginx 處理 HTTP 請求的 11 個階段全部梳理了一遍，每個階段基本都有對應的模塊。相信對於這樣一個全流程的解析，大家都能夠看懂 Nginx 的配置了，在此之上，還能夠按照需求靈活配置出自己想要的配置，這樣就真正的掌握了 11 個階段。

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

一些可用於研究的GIS數據資源

國內的情況就不用說了，基本上是很難找到可以用於研究的GIS數據資源的。要麼就是收費，免費的即使能找到，能否合法合規的進行使用也是一個問題。地理信息數據還是國外比較開放一些，相當多的政府組織或者公益機構對公衆開放了下載渠道，大家可以適度獲取並

harlee44 2024-05-07 14:31:18

如何在低代碼平臺中引用 JavaScript ？

引言 在當今快速發展的數字化時代，企業對業務應用的需求日益複雜且多元。低代碼開發平臺作爲一個創新的解決方案，以直觀易用的設計理念，打破了傳統的編程壁壘，讓非技術人員也能輕鬆構建功能完備的Web應用程序，無需深入編碼。這一特性極大地簡化了應用

葡萄城技術團隊 2024-05-07 14:30:48

如何使用 JavaScript 獲取當前頁面幀率 FPS

可以通過計算每秒 window.requestAnimationFrame 的調用頻率來做爲 FPS 值。它接收一個回調函數，該回調函數會在瀏覽器下一次重繪之前執行。所以只要我們循環調用並記錄單位時間內的調用次數就能計算當前頁面的幀率了。

劉漢貴 2024-05-07 14:26:58

Dash 2.17版本新特性介紹

本文示例代碼已上傳至我的Github倉庫https://github.com/CNFeffery/dash-master 　　大家好我是費老師，不久前Dash發佈了其2.17.0版本，執行下面的命令進行最新版本Dash的安裝： pip

費弗裏 2024-05-07 14:21:37

人大金倉數據庫使（cai）用（keng）記錄

最近一直在用人大金倉做項目，相關的文檔相比其它流行的所謂“主流”數據庫來說還是少了點，記錄一些開發過程中遇到的問題。 數據庫的模式（database_mode）在實例創建後就確定好了的，不可更改。想要改變模式只能重新init一個實例。

M_mxy 2024-05-07 14:17:06

《最新出爐》系列入門篇-Python+Playwright自動化測試-43-分頁測試

1.簡介 分頁測試，這種一般都是公共的方法系統中都寫好了，這種一般出現是數據展示比較多的時候，會採取分頁的方法，而且比較固定，一般是沒有問題的，因此它非常適合自動化測試，但是如何使用playwright來進行分頁自動化測試了，宏哥今天就講解

北京-宏哥 2024-05-07 14:14:46

Ubuntu18 安裝NoMachine遠程桌面（解決遠程桌面延遲）

# 問題：Ubuntu 18 使用自帶的共享桌面、VNC遠程桌面延遲、降低分辨率也無效。 # 方案：最後找到安裝 NoMachine的遠程桌面，解決遠程卡頓問題 根據自己操作系統 選擇NoMachine for Linux進行下載官網：ht

iucx 2024-05-07 14:11:26

gdb調試FAQ

“malloc.c: No such file or directory.” 參考：https://www.cnblogs.com/gatsby123/p/11755320.html 安裝依賴 sudo apt-get install li

ffl 2024-05-07 14:08:35

大數據面試SQL每日一題系列：最高峯同時在線主播人數。字節，快手等大廠高頻面試題

大數據面試SQL每日一題系列：最高峯同時在線主播人數。字節，快手等大廠高頻面試題 之後會不定期更新每日一題sql系列。 SQL面試題每日一題系列內容均來自於網絡以及實際使用情況收集，如有雷同，純屬巧合。 1.題目 問題1：如下爲某直播平臺各

魯邊 2024-05-07 14:06:45

工程款拖欠，農民工怎麼了？就得一直忍着委屈求全嗎？

事件背景 我以前只是在新聞看到過拖欠農民工工資這樣的事，但這次是發生在自己身上了！ 今天晚上下班後，看見父母面露愁色，並認真的聽着父母的對話。 大概意思是就是爸爸跟着工程隊包天活已經完事有一段時間了，但是包天的工資一直不給，而且聽爸爸說那意

久曲健 2024-05-07 14:06:15

Canvas簡歷編輯器-我的剪貼板裏究竟有什麼數據

Canvas圖形編輯器-我的剪貼板裏究竟有什麼數據 在這裏我們先來聊聊我們究竟應該如何操作剪貼板，也就是我們在瀏覽器的複製粘貼事件，並且在此基礎上聊聊我們在Canvas圖形編輯器中應該如何控制焦點以及如何實現複製粘貼行爲。 在線編輯: h

WindrunnerMax 2024-05-07 14:05:25

HarmonyOS 實現下拉刷新，上拉加載更多

組件介紹 PullToRefreshList允許用戶通過下拉動作來刷新列表內容，以及通過上拉動作來加載更多的數據。組件內部封裝了滾動監聽、狀態管理和動畫效果，使得開發者可以輕鬆集成到自己的項目中。 1. 實現思路 封裝成可複用的公共控件：

西北野狼 2024-05-07 14:05:15

【轉】在 Linux 里布署 Docker

來自：百度 Docker 可以佈署在 Linux 系統上，也可以佈署在你自己的電腦上。 在 Linux 系統上佈署 Docker： 安裝 Docker： curl -fsSL https://get.docker.com -o get-d

z5337 2024-05-07 14:05:05

使用.NET源生成器(SG)實現一個自動注入的生成器

DI依賴注入對我們後端程序員來說肯定是基礎中的基礎了,我們經常會使用下面的代碼注入相關的service services.AddScoped<Biwen.AutoClassGen.TestConsole.Services.TestServi

萬雅虎 2024-05-07 14:04:44

mysql索引使用基礎

1.創建&刪除 MySQL可以通過CREATE、ALTER、DDL三種方式創建一個索引。 在MySQL中，使用CREATE INDEX語句可以創建索引。具體語法如下： CREATE INDEX indexName ON tableNam

楚景然 2024-05-07 14:01:04