今天我們講 request，在 nginx 中我們指的是 http 請求，具體到 Nginx 中的數據結構是ngx_http_request_t。ngx_http_request_t 是對一個 http 請求的封裝。 我們知道，一個 http 請求，包含請求行、請求頭、請求體、響應行、響應頭、響應體。
http 請求是典型的請求-響應類型的的網絡協議，而 http 是文本協議，所以我們在分析請求行與請求頭，以及輸出響應行與響應頭，往往是一行一行的進行處理。 ? ? ? ( 推薦學習：nginx使用?)
如果我們自己來寫一個 http 服務器，通常在一個連接建立好后，客戶端會發送請求過來。然后我們讀取一行數據，分析出請求行中包含的 method、uri、http_version 信息。
然后再一行一行處理請求頭，并根據請求 method 與請求頭的信息來決定是否有請求體以及請求體的長度，然后再去讀取請求體。
得到請求后，我們處理請求產生需要輸出的數據，然后再生成響應行，響應頭以及響應體。
在將響應發送給客戶端之后，一個完整的請求就處理完了。當然這是最簡單的 webserver 的處理方式，其實 Nginx 也是這樣做的，只是有一些小小的區別，比如，當請求頭讀取完成后，就開始進行請求的處理了。Nginx 通過 ngx_http_request_t 來保存解析請求與輸出響應相關的數據。
那接下來，簡要講講 Nginx 是如何處理一個完整的請求的。對于 Nginx 來說，一個請求是從ngx_http_init_request 開始的，在這個函數中，會設置讀事件為 ngx_http_process_request_line，也就是說，接下來的網絡事件，會由 ngx_http_process_request_line 來執行。
從ngx_http_process_request_line 的函數名，我們可以看到，這就是來處理請求行的，正好與之前講的，處理請求的第一件事就是處理請求行是一致的。
通過 ngx_http_read_request_header 來讀取請求數據。然后調用 ngx_http_parse_request_line 函數來解析請求行。Nginx 為提高效率，采用狀態機來解析請求行，而且在進行 method 的比較時，沒有直接使用字符串比較，而是將四個字符轉換成一個整型，然后一次比較以減少 cpu 的指令數，這個前面有說過。
很多人可能很清楚一個請求行包含請求的方法，uri，版本，卻不知道其實在請求行中，也是可以包含有 host 的。比如一個請求 GET http://www.taobao.com/uri HTTP/1.0 這樣一個請求行也是合法的，而且 host 是 www.taobao.com，這個時候，Nginx 會忽略請求頭中的 host 域，而以請求行中的這個為準來查找虛擬主機。
另外，對于對于 http0.9 版來說，是不支持請求頭的，所以這里也是要特別的處理。所以，在后面解析請求頭時，協議版本都是 1.0 或 1.1。整個請求行解析到的參數，會保存到 ngx_http_request_t 結構當中。
在解析完請求行后，Nginx 會設置讀事件的 handler 為 ngx_http_process_request_headers，然后后續的請求就在 ngx_http_process_request_headers 中進行讀取與解析。
ngx_http_process_request_headers 函數用來讀取請求頭，跟請求行一樣，還是調用 ngx_http_read_request_header 來讀取請求頭，調用 ngx_http_parse_header_line 來解析一行請求頭，解析到的請求頭會保存到 ngx_http_request_t 的域 headers_in 中，headers_in 是一個鏈表結構，保存所有的請求頭。
而 HTTP 中有些請求是需要特別處理的，這些請求頭與請求處理函數存放在一個映射表里面，即 ngx_http_headers_in，在初始化時，會生成一個 hash 表，當每解析到一個請求頭后，就會先在這個 hash 表中查找，如果有找到，則調用相應的處理函數來處理這個請求頭。比如:Host 頭的處理函數是 ngx_http_process_host。
當 Nginx 解析到兩個回車換行符時，就表示請求頭的結束，此時就會調用 ngx_http_process_request 來處理請求了。
ngx_http_process_request 會設置當前的連接的讀寫事件處理函數為 ngx_http_request_handler，然后再調用 ngx_http_handler 來真正開始處理一個完整的http請求。
這里可能比較奇怪，讀寫事件處理函數都是ngx_http_request_handler，其實在這個函數中，會根據當前事件是讀事件還是寫事件，分別調用 ngx_http_request_t 中的 read_event_handler 或者是 write_event_handler。
由于此時，我們的請求頭已經讀取完成了，之前有說過，Nginx 的做法是先不讀取請求 body，所以這里面我們設置 read_event_handler 為 ngx_http_block_reading，即不讀取數據了。
剛才說到，真正開始處理數據，是在 ngx_http_handler 這個函數里面，這個函數會設置 write_event_handler 為 ngx_http_core_run_phases，并執行 ngx_http_core_run_phases 函數。
ngx_http_core_run_phases 這個函數將執行多階段請求處理，Nginx 將一個 http 請求的處理分為多個階段，那么這個函數就是執行這些階段來產生數據。
因為 ngx_http_core_run_phases 最后會產生數據，所以我們就很容易理解，為什么設置寫事件的處理函數為 ngx_http_core_run_phases 了。
在這里，我簡要說明了一下函數的調用邏輯，我們需要明白最終是調用 ngx_http_core_run_phases 來處理請求，產生的響應頭會放在 ngx_http_request_t 的 headers_out 中，這一部分內容，我會放在請求處理流程里面去講。Nginx 的各種階段會對請求進行處理，最后會調用 Filter 來過濾數據，對數據進行加工，如 truncked 傳輸、gzip 壓縮等。
這里的 filter 包括 header filter 與 body filter，即對響應頭或響應體進行處理。filter 是一個鏈表結構，分別有 header filter 與 body filter，先執行 header filter 中的所有 filter，然后再執行 body filter 中的所有 filter。
在 header filter 中的最后一個 filter，即 ngx_http_header_filter，這個 filter 將會遍歷所有的響應頭，最后需要輸出的響應頭在一個連續的內存，然后調用 ngx_http_write_filter 進行輸出。
ngx_http_write_filter 是 body filter 中的最后一個，所以 Nginx 首先的 body 信息，在經過一系列的 body filter 之后，最后也會調用 ngx_http_write_filter 來進行輸出(有圖來說明)。
這里要注意的是，Nginx 會將整個請求頭都放在一個 buffer 里面，這個 buffer 的大小通過配置項 client_header_buffer_size 來設置，如果用戶的請求頭太大，這個 buffer 裝不下，那 Nginx 就會重新分配一個新的更大的 buffer 來裝請求頭，這個大 buffer 可以通過 large_client_header_buffers 來設置，這個 large_buffer 這一組 buffer，比如配置 48k，就是表示有四個 8k 大小的 buffer 可以用。
注意，為了保存請求行或請求頭的完整性，一個完整的請求行或請求頭，需要放在一個連續的內存里面，所以，一個完整的請求行或請求頭，只會保存在一個 buffer 里面。
這樣，如果請求行大于一個 buffer 的大小，就會返回 414 錯誤，如果一個請求頭大小大于一個 buffer 大小，就會返回 400 錯誤。在了解了這些參數的值，以及 Nginx 實際的做法之后，在應用場景，我們就需要根據實際的需求來調整這些參數，來優化我們的程序了。
處理流程圖：
以上這些，就是 Nginx 中一個 http 請求的生命周期了。
