Nginx處理請求的11個階段(agentzh的Nginx 教程學習記錄)

振宇要低調發表於2018-07-10
Nginx 處理請求的過程一共劃分為 11 個階段,按照執行順序依次是 post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、try-files、content 以及 log。

1、post-read

最先執行的 post-read 階段在 Nginx 讀取並解析完請求頭(request headers)之後就立即開始執行。例如:使用了 ngx_realip 模組提供的 set_real_ip_from 和 real_ip_header 這兩條配置指令

2、server-rewrite

由於 server-rewrite 階段位於 post-read 階段之後,所以 server 配置塊中的 set 指令也就總是執行在 ngx_realip 模組改寫請求的來源地址之後。

3、find-config

這個階段並不支援 Nginx 模組註冊處理程式,而是由 Nginx 核心來完成當前請求與 location 配置塊之間的配對工作。換句話說,在此階段之前,請求並沒有與任何 location 配置塊相關聯。因此,對於執行在 find-config 階段之前的 post-read 和 server-rewrite 階段來說,只有 server 配置塊以及更外層作用域中的配置指令才會起作用。這就是為什麼只有寫在 server 配置塊中的 ngx_rewrite 模組的指令才會執行在 server-rewrite 階段,這也是為什麼前面所有例子中的 ngx_realip 模組的指令也都特意寫在了 server 配置塊中,以確保其註冊在 post-read 階段的處理程式能夠生效。

4、rewrite

由於 Nginx 已經在 find-config 階段完成了當前請求與 location 的配對,所以從 rewrite 階段開始,location 配置塊中的指令便可以產生作用。當 ngx_rewrite 模組的指令用於 location 塊中時,便是執行在這個 rewrite 階段。

5、post-rewrite

這個階段也像 find-config 階段那樣不接受 Nginx 模組註冊處理程式,而是由 Nginx 核心完成 rewrite 階段所要求的“內部跳轉”操作(如果 rewrite 階段有此要求的話)。例如:通過 rewrite 指令把當前請求的 URI 無條件地改寫為 /bar,同時發起一個“內部跳轉”,最終跳進了 location /bar 中。這裡比較有趣的地方是“內部跳轉”的工作原理。“內部跳轉”本質上其實就是把當前的請求處理階段強行倒退到 find-config 階段,以便重新進行請求 URI 與 location 配置塊的配對。

6、preaccess

該階段在 access 階段之前執行,故名 preaccess.標準模組 ngx_limit_req 和 ngx_limit_zone 就執行在此階段,前者可以控制請求的訪問頻度,而後者可以限制訪問的併發度。

7、access

標準模組 ngx_access、第三方模組 ngx_auth_request 以及第三方模組 ngx_lua 的 access_by_lua 指令就執行在這個階段。

8、 post-access

這個階段也和 post-rewrite 階段類似,並不支援 Nginx 模組註冊處理程式,而是由 Nginx 核心自己完成一些處理工作。post-access 階段主要用於配合 access 階段實現標準 ngx_http_core 模組提供的配置指令 satisfy 的功能。對於多個 Nginx 模組註冊在 access 階段的處理程式, satisfy 配置指令可以用於控制它們彼此之間的協作方式。比如模組 A 和 B 都在 access 階段註冊了與訪問控制相關的處理程式,那就有兩種協作方式,一是模組 A 和模組 B 都得通過驗證才算通過,二是模組 A 和模組 B 只要其中任一個通過驗證就算通過。第一種協作方式稱為 all 方式(或者說“與關係”),第二種方式則被稱為 any 方式(或者說“或關係”)。預設情況下,Nginx 使用的是 all 方式。

9、try-files

這個階段專門用於實現標準配置指令 try_files 的功能,並不支援 Nginx 模組註冊處理程式。try_files 指令接受兩個以上任意數量的引數,每個引數都指定了一個 URI. 這裡假設配置了 N 個引數,則 Nginx 會在 try-files 階段,依次把前 N-1 個引數對映為檔案系統上的物件(檔案或者目錄),然後檢查這些物件是否存在。一旦 Nginx 發現某個檔案系統物件存在,就會在 try-files 階段把當前請求的 URI 改寫為該物件所對應的引數 URI(但不會包含末尾的斜槓字元,也不會發生 “內部跳轉”)。如果前 N-1 個引數所對應的檔案系統物件都不存在,try-files 階段就會立即發起“內部跳轉”到最後一個引數(即第 N 個引數)所指定的 URI.通過 root 配置指令所指定的“文件根目錄”進行對映。例如,當“文件根目錄”是 /var/www/ 的時候,請求 URI /foo/bar 會被對映為檔案 /var/www/foo/bar,而請求 URI /foo/baz/ 則會被對映為目錄 /var/www/foo/baz/. 注意這裡是如何通過 URI 末尾的斜槓字元是否存在來區分“目錄”和“檔案”的。

10、content

Nginx 的 content 階段是所有請求處理階段中最為重要的一個,因為執行在這個階段的配置指令一般都肩負著生成“內容”(content)並輸出 HTTP 響應的使命。正因為其重要性,這個階段的配置指令也異常豐富。echo、 Nginx 變數漫談(二) 中接觸到的 echo_exec 指令, Nginx 變數漫談(三) 中接觸到的 proxy_pass 指令,Nginx 變數漫談(五) 中介紹過的 echo_location 指令,以及 Nginx 變數漫談(七) 中介紹過的 content_by_lua

11、log

log階段處理,比如記錄訪問量/統計平均響應時間。log_by_lua
 

相關文章