如何使用Nginx處理請求

Nginx 使用一個多進程模型來對外提供服務，其中一個 master 進程，多個 worker 進程。 master 流程​​負責管理 Nginx 本身和其他 worker 流程​​。

所有實際的業務處理邏輯都在 worker 流程​​。 worker 進程中有一個函數，執行無限循環，不斷處理收到的來自客戶端的請求，並進行處理，直到整個 Nginx 服務被停止。          ( 推薦學習：nginx使用 )

worker 進程中，ngx_worker_process_cycle()函數就是這個無限迴圈的處理函數。

在這個函數中，一個請求的簡單處理流程如下：

作業系統提供的機制（例如 epoll, kqueue 等）產生相關的事件。

接收和處理這些事件，如是接受到數據，則產生更高層的 request 物件。

處理 request 的 header 和 body。

產生回應，並發送回客戶端。

完成 request 的處理。

重新初始化定時器及其他事件。

請求的處理流程

為了讓大家更好的了解 Nginx 中請求處理過程，我們以 HTTP Request 為例，來做一下詳細地說明。

從 Nginx 的內部來看，一個 HTTP Request 的處理過程涉及到以下幾個階段。

初始化 HTTP Request（讀取來自客戶端的數據，產生 HTTP Request 對象，該對象含有該請求所有的資訊）。

處理請求頭。

處理請求體。

如果有的話，請呼叫與此請求（URL 或 Location）關聯的 handler。

依序呼叫各 phase handler 進行處理。

在這裡，我們需要了解 phase handler 這個概念。 phase 字面的意思，就是階段。所以 phase handlers 也就好理解了，就是包含若干個處理階段的一些 handler。

在每一個階段，包含有若干個 handler，再處理到某個階段的時候，依序呼叫該階段的 handler 對 HTTP Request 進行處理。

通常情況下，一個 phase handler 會對這個 request 進行處理，並產生一些輸出。通常 phase handler 是與定義在設定檔中的某個 location 相關聯的。

一個 phase handler 通常執行下列幾項任務：

取得 location 設定。

產生適當的回應。

發送 response header。

傳送 response body。

當 Nginx 讀取到一個 HTTP Request 的 header 的時候，Nginx 首先尋找與這個請求關聯的虛擬主機的設定。如果找到了這個虛擬主機的配置，那麼通常情況下，這個HTTP Request 將會經過以下幾個階段的處理（phase handlers）：

NGX_HTTP_POST_READ_PHASE: 讀取請求內容階段

NGX_HTTP_SERVER_REWRITE_PHASE: Server 請求位址重寫階段

NGX_HTTP_FIND_CONFIG_PHASE: 配置查找階段:

NGX_HTTP_REWRITE_PHASE: Location請求位址重寫階段

#NGX_HTTP_REWRITE_PHASE: Location請求位址重寫階段

#NGX_HTTP_REWRITE_PHASE: Location請求位址重寫階段##PH_

#NGX_HTTP_REWRITE_RETP: Location請求位址重寫階段#1_PH_

NGX_HTTP_REWRITE_RETP: Location請求位址重寫階段#1_PH_

NGX_HTTP_REWRITE_RE: Location請求位址重寫階段

NGX_HTTP_PREACCESS_PHASE: 存取權限檢查準備階段

NGX_HTTP_ACCESS_PHASE: 存取權限檢查階段

NGX_HTTP_POST_ACCESS_PHASE: 存取權限檢查提交階段

##NGX_HTTP_POST_ACCESS_PHASE: 存取權限檢查提交階段

NGX_HTTP_POST_ACCESS_PHASE: 存取權限檢查提交階段

##aRY處理階段

NGX_HTTP_CONTENT_PHASE: 內容產生階段

NGX_HTTP_LOG_PHASE: 日誌模組處理階段

在內容產生階段，為了給一個request 產生正確的回應，Nginx 必須把這個request交給一個合適的content handler 去處理。

如果這個request 對應的location 在設定檔中被明確指定了一個content handler，那麼Nginx 就可以透過對location 的匹配，直接找到這個對應的handler，並且把這個request 交給這個content handler去處理。這樣的設定指令包括像，perl，flv，proxy_pass，mp4等。

如果一個request 對應的location 並沒有直接有設定的content handler，那麼Nginx 依序嘗試:

##如果一個location 裡面有設定random_index on，那麼隨機選擇一個文件，發送給客戶端。

如果一個 location 裡面有設定 index 指令，那麼發送 index 指令指明的文件，給客戶端。

如果一個 location 裡面有設定 autoindex on，那麼就傳送請求位址對應的服務端路徑下的檔案清單給客戶端。

###如果這個 request 對應的 location 上有設定 gzip_static on，那麼就查找是否有對應的.gz檔案存在，有的話，就發送這個給客戶端（客戶端支援 gzip 的情況下）。 ######請求的 URI 如果對應一個靜態文件，static module 就會將靜態文件的內容傳送到客戶端。 ######內容產生階段完成以後，產生的輸出會被傳遞到 filter 模組去處理。 ###

filter 模組也是與 location 相關的。所有的 fiter 模組都被組織成一條鏈。輸出會依序穿越所有的 filter，直到有一個 filter 模組的回傳值表示已經處理完成。

這裡列舉幾個常見的 filter 模組，例如：

server-side includes。

XSLT filtering。

影像縮放之類的。

gzip 壓縮。

在所有的 filter 中，有幾個 filter 模組要關註一下。依照呼叫的順序依序說明如下：

write: 寫入輸出到客戶端，實際上是寫到連接對應的 socket 上。

postpone: 這個 filter 是負責 subrequest 的，也就是子請求的。

copy: 將一些需要複製的 buf(檔案或記憶體)重新複製一份然後交給剩餘的 body filter 處理。

以上是如何使用Nginx處理請求的詳細內容。更多資訊請關注PHP中文網其他相關文章！