這節我們講request，在nginx中我們指的是http請求，具體到nginx中的資料結構是ngx_http_request_t。 ngx_http_request_t是對一個http請求的封裝。 我們知道，一個http請求，包含請求行、請求頭、請求體、回應行、回應頭、回應體。
http請求是典型的請求-回應類型的網路協議，而http是文件協議，所以我們在分析請求行與請求頭，以及輸出回應行與回應頭，往往是一行一行的進行處理。如果我們自己來寫一個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 ，保存所有的請求頭。而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，例如配置4 8k，就是表示有四個8k大小的buffer可以用。注意，為了保存請求行或請求頭的完整性，一個完整的請求行或請求頭，需要放在一個連續的記憶體裡面，所以，一個完整的請求行或請求頭，只會保存在一個buffer裡面。這樣，如果請求行大於一個buffer的大小，就會回傳414錯誤，如果一個請求頭大小大於一個buffer大小，就會回傳400錯誤。在了解了這些參數的值，以及nginx實際的做法之後，在應用場景，我們就需要根據實際的需求來調整這些參數，來優化我們的程式了。
處理流程圖：
以上這些，就是nginx中一個http請求的生命週期了。我們再看看與請求相關的一些概念。
以上就介紹了nginx中的request，包括了方面的內容，希望對PHP教程有興趣的朋友有所幫助。
