connection
Nginx 中 connection 是對 tcp 連接的封裝，包括連接的 socket，讀、寫事件等。利用 Nginx 封裝的 connection可以很方便的使用 Nginx 來處理與連接相關的事情，如建立連接，發送與接受數據等。Nginx 中的 http 請求的處理就是建立在 connection之上的，所以 Nginx 不僅可以作爲一個web服務器，也可作爲郵件服務器。利用 Nginx 提供的 connection，可以與任何後端服務打交道。
問題一：發送請求，佔用了 woker 的幾個連接數？
答案：2 或者 4 個
問題二：nginx 有一個 master，有四個 woker，每個 woker 支持最大的連接數 1024，支持的最大併發數是多少？
- 普通的靜態訪問最大併發數是： worker_connections * worker_processes /2，
- HTTP 作 爲反向代理來說，最大併發數量應該是 worker_connections * worker_processes/4。
結合一個 tcp 連接的生命週期，我們看看 Nginx 是如何處理一個連接的。首先，Nginx 在啓動時，會解析配置文件，得到需要監聽的端口與 ip 地址，然後在 Nginx 的 master 進程裏面，先初始化好這個監控的 socket(創建 socket，設置 addrreuse 等選項，綁定到指定的 ip 地址端口，再 listen)，然後再 fork 出多個子進程出來，然後子進程會競爭 accept 新的連接。此時，客戶端就可以向 Nginx 發起連接了。當客戶端與服務端通過三次握手建立好一個連接後，Nginx 的某一個子進程會 accept 成功，得到這個建立好的連接的 socket，然後創建 Nginx 對連接的封裝，即 ngx_connection_t 結構體。接着，設置讀寫事件處理函數並添加讀寫事件來與客戶端進行數據的交換。最後，Nginx 或客戶端來主動關掉連接，到此，一個連接就壽終正寢了。
當然，Nginx 也是可以作爲客戶端來請求其它 server 的數據的（如 upstream 模塊），此時，與其它 server 創建的連接，也封裝在 ngx_connection_t 中。作爲客戶端，Nginx 先獲取一個 ngx_connection_t 結構體，然後創建 socket，並設置 socket 的屬性（ 比如非阻塞）。然後再通過添加讀寫事件，調用 connect/read/write 來調用連接，最後關掉連接，並釋放 ngx_connection_t。
在 Nginx 中，每個進程會有一個連接數的最大上限，這個上限與系統對 fd 的限制不一樣。在操作系統中，通過 ulimit -n，我們可以得到一個進程所能夠打開的 fd 的最大數，即 nofile，因爲每個 socket 連接會佔用掉一個 fd，所以這也會限制我們進程的最大連接數，當然也會直接影響到我們程序所能支持的最大併發數，當 fd 用完後，再創建 socket 時，就會失敗。Nginx 通過設置 worker_connectons 來設置每個進程支持的最大連接數。若該值大於 nofile，則實際的最大連接數是 nofile，Nginx 會有警告。Nginx 在實現時，是通過一個連接池來管理的，每個 worker 進程都有一個獨立的連接池，連接池的大小是 worker_connections。這裏的連接池裏面保存的其實不是真實的連接，它只是一個 worker_connections 大小的一個 ngx_connection_t 結構的數組。並且，Nginx 會通過一個鏈表 free_connections 來保存所有的空閒 ngx_connection_t，每次獲取一個連接時，就從空閒連接鏈表中獲取一個，用完後，再放回空閒連接鏈表裏面。
worker_connections 參數表示每個 worker 進程所能建立連接的最大值，所以一個 Nginx 能建立的最大連接數，應該是worker_connections * worker_processes。這裏說的是最大連接數，對於 HTTP 請求本地資源來說，能夠支持的最大併發數量是worker_connections * worker_processes，而如果是 HTTP 作爲反向代理來說，最大併發數量應該是worker_connections * worker_processes/2。因爲作爲反向代理服務器，每個併發會建立與客戶端的連接和與後端服務的連接，會佔用兩個連接。
那麼，我們前面有說過一個客戶端連接過來後，多個空閒的進程，會競爭這個連接，很容易看到，這種競爭會導致不公平，如果某個進程得到 accept 的機會比較多，它的空閒連接很快就用完了，如果不提前做一些控制，當 accept 到一個新的 tcp 連接後，因爲無法得到空閒連接，而且無法將此連接轉交給其它進程，最終會導致此 tcp 連接得不到處理，就中止掉了。很顯然，這是不公平的，有的進程有空餘連接，卻沒有處理機會，有的進程因爲沒有空餘連接，卻人爲地丟棄連接。那麼，如何解決這個問題呢？首先，Nginx 的處理得先打開 accept_mutex 選項，此時，只有獲得了 accept_mutex 的進程纔會去添加accept事件，也就是說，Nginx會控制進程是否添加 accept 事件。Nginx 使用一個叫 ngx_accept_disabled 的變量來控制是否去競爭 accept_mutex 鎖。在第一段代碼中，計算 ngx_accept_disabled 的值，這個值是 Nginx 單進程的所有連接總數的八分之一，減去剩下的空閒連接數量，得到的這個 ngx_accept_disabled 有一個規律，當剩餘連接數小於總連接數的八分之一時，其值才大於 0，而且剩餘的連接數越小，這個值越大。再看第二段代碼，當 ngx_accept_disabled 大於 0 時，不會去嘗試獲取 accept_mutex 鎖，並且將 ngx_accept_disabled 減 1，於是，每次執行到此處時，都會去減 1，直到小於 0。不去獲取 accept_mutex 鎖，就是等於讓出獲取連接的機會，很顯然可以看出，當空餘連接越少時，ngx_accept_disable 越大，於是讓出的機會就越多，這樣其它進程獲取鎖的機會也就越大。不去 accept，自己的連接就控制下來了，其它進程的連接池就會得到利用，這樣，Nginx 就控制了多進程間連接的平衡了。
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 中，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 實際的做法之後，在應用場景，我們就需要根據實際的需求來調整這些參數，來優化我們的程序了。
keepalive
在 Nginx 中，對於 http1.0 與 http1.1 也是支持長連接的。什麼是長連接呢？http 請求是基於 TCP 協議之上的，那麼，當客戶端在發起請求前，需要先與服務端建立 TCP 連接，而每一次的 TCP 連接是需要三次握手來確定的，如果客戶端與服務端之間網絡差一點，這三次交互消費的時間會比較多，而且三次交互也會帶來網絡流量。當然，當連接斷開後，也會有四次的交互，當然對用戶體驗來說就不重要了。而 http 請求是請求應答式的，如果我們能知道每個請求頭與響應體的長度，那麼我們是可以在一個連接上面執行多個請求的，這就是所謂的長連接，但前提條件是我們先得確定請求頭與響應體的長度。對於請求來說，如果當前請求需要有body，如 POST 請求，那麼 Nginx 就需要客戶端在請求頭中指定 content-length 來表明 body 的大小，否則返回 400 錯誤。也就是說，請求體的長度是確定的，那麼響應體的長度呢？先來看看 http 協議中關於響應 body 長度的確定：
-
對於 http1.0 協議來說，如果響應頭中有 content-length 頭，則以 content-length 的長度就可以知道 body 的長度了，客戶端在接收 body 時，就可以依照這個長度來接收數據，接收完後，就表示這個請求完成了。而如果沒有 content-length 頭，則客戶端會一直接收數據，直到服務端主動斷開連接，才表示 body 接收完了。
- 而對於 http1.1 協議來說，如果響應頭中的 Transfer-encoding 爲 chunked 傳輸，則表示 body 是流式輸出，body 會被分成多個塊，每塊的開始會標識出當前塊的長度，此時，body 不需要通過長度來指定。如果是非 chunked 傳輸，而且有 content-length，則按照 content-length 來接收數據。否則，如果是非 chunked，並且沒有 content-length，則客戶端接收數據，直到服務端主動斷開連接。
從上面，我們可以看到，除了 http1.0 不帶 content-length 以及 http1.1 非 chunked 不帶 content-length 外，body 的長度是可知的。此時，當服務端在輸出完 body 之後，會可以考慮使用長連接。能否使用長連接，也是有條件限制的。如果客戶端的請求頭中的 connection爲close，則表示客戶端需要關掉長連接，如果爲 keep-alive，則客戶端需要打開長連接，如果客戶端的請求中沒有 connection 這個頭，那麼根據協議，如果是 http1.0，則默認爲 close，如果是 http1.1，則默認爲 keep-alive。如果結果爲 keepalive，那麼，Nginx 在輸出完響應體後，會設置當前連接的 keepalive 屬性，然後等待客戶端下一次請求。當然，Nginx 不可能一直等待下去，如果客戶端一直不發數據過來，豈不是一直佔用這個連接？所以當 Nginx 設置了 keepalive 等待下一次的請求時，同時也會設置一個最大等待時間，這個時間是通過選項 keepalive_timeout 來配置的，如果配置爲 0，則表示關掉 keepalive，此時，http 版本無論是 1.1 還是 1.0，客戶端的 connection 不管是 close 還是 keepalive，都會強制爲 close。
如果服務端最後的決定是 keepalive 打開，那麼在響應的 http 頭裏面，也會包含有 connection 頭域，其值是"Keep-Alive"，否則就是"Close"。如果 connection 值爲 close，在 Nginx 響應完數據後，會主動關掉連接。所對於請求量比較大的 Nginx 來說，關掉 keepalive 最後會產生比較多的 time-wait 狀態的 socket。一般來說，當客戶端的一次訪問，需要多次訪問同一個 server 時，打開 keepalive 的優勢非常大，比如圖片服務器，通常一個網頁會包含很多個圖片。打開 keepalive 也會大量減少 time-wait 的數量。
pipe（pipeline）
http1.1引入一種新特性即 pipeline。pipeline 其實就是流水線作業，它可以看作爲 keepalive 的一種昇華，因爲 pipeline 也是基於長連接的，目的就是利用一個連接做多次請求。如客戶端要提交多個請求，對於keepalive來說，那第二個請求必須要等到第一個請求的響應接收完全後才能發起，這和 TCP 的停止等待協議是一樣的，得到兩個響應的時間至少爲2*RTT（RTT即往返延時）。而對 pipeline 來說，客戶端不必等到第一個請求處理完後，就可以馬上發起第二個請求。得到兩個響應的時間可能能夠達到1*RTT。Nginx 是直接支持 pipeline 的，但是，Nginx 對 pipeline 中的多個請求的處理卻不是並行的，依然是一個請求接一個請求的處理，只是在處理第一個請求的時候，客戶端就可以發起第二個請求。這樣，Nginx 利用 pipeline 減少了處理完一個請求後，等待第二個請求的請求頭數據的時間。其實 Nginx 的做法很簡單，前面說到，Nginx 在讀取數據時，會將讀取的數據放到一個 buffer 裏面，所以，如果 Nginx 在處理完前一個請求後，如果發現 buffer 裏面還有數據，就認爲剩下的數據是下一個請求的開始，然後就接下來處理下一個請求，否則就設置 keepalive。
lingering_close
lingering_close字面意思就是延遲關閉，也就是說，當 Nginx 要關閉連接時，並非立即關閉連接，而是先關閉 tcp 連接的寫，再等待一段時間後再關掉連接的讀。爲什麼這樣呢？Nginx 在接收客戶端的請求時可能由於客戶端或服務端出錯了，要立即響應錯誤信息給客戶端，而 Nginx 在響應錯誤信息後大分部情況下是需要關閉當前連接。Nginx 執行完 write()系統調用把錯誤信息發送給客戶端，write()系統調用返回成功並不表示數據已經發送到客戶端，有可能還在 tcp 連接的 write buffer 裏。接着如果直接執行 close()系統調用關閉 tcp 連接，內核會首先檢查 tcp 的 read buffer 裏有沒有客戶端發送過來的數據留在內核態沒有被用戶態進程讀取，若有則發送給客戶端 RST 報文來關閉 tcp 連接丟棄 write buffer 裏的數據，若沒有則等待 write buffer 裏的數據發送完畢，然後再經過正常的 4 次分手報文斷開連接。所以當在某些場景下出現 tcp write buffer 裏的數據在 write()系統調用之後到 close()系統調用執行之前沒有發送完畢，且 tcp read buffer 裏面還有數據沒有讀，close()系統調用會導致客戶端收到 RST 報文且不會拿到服務端發送過來的錯誤信息數據。
在上面這個場景中，關鍵點是服務端給客戶端發送了 RST 包，導致自己發送的數據在客戶端忽略掉了。所以，解決問題的重點是，讓服務端別發 RST 包。再想想，我們發送 RST 是因爲我們關掉了連接，關掉連接是因爲我們不想再處理此連接了，也不會有任何數據產生了。對於全雙工的 TCP 連接來說，我們只需要關掉寫就行了，讀可以繼續進行，我們只需要丟掉讀到的任何數據就行了，這樣的話，當我們關掉連接後，客戶端再發過來的數據，就不會再收到 RST 了。當然最終我們還是需要關掉這個讀端的，所以我們會設置一個超時時間，在這個時間過後，就關掉讀，客戶端再發送數據來就不管了，作爲服務端我會認爲，都這麼長時間了，發給你的錯誤信息也應該讀到了，再慢就不關我事了，要怪就怪你 RP 不好了。當然，正常的客戶端，在讀取到數據後，會關掉連接，此時服務端就會在超時時間內關掉讀端。這些正是 lingering_close 所做的事情。協議棧提供 SO_LINGER 這個選項，它的一種配置情況就是來處理 lingering_close 的情況的，不過 Nginx 是自己實現的 lingering_close。lingering_close 存在的意義就是來讀取剩下的客戶端發來的數據，所以 Nginx 會有一個讀超時時間，通過 lingering_timeout 選項來設置，如果在 lingering_timeout 時間內還沒有收到數據，則直接關掉連接。Nginx 還支持設置一個總的讀取時間，通過 lingering_time 來設置，這個時間也就是 Nginx 在關閉寫之後，保留 socket 的時間，客戶端需要在這個時間內發送完所有的數據，否則 Nginx 在這個時間過後，會直接關掉連接。當然，Nginx 是支持配置是否打開 lingering_close 選項的，通過 lingering_close 選項來配置。
那麼，我們在實際應用中，是否應該打開 lingering_close 呢？這個就沒有固定的推薦值了，如 Maxim Dounin所說，lingering_close 的主要作用是保持更好的客戶端兼容性，但是卻需要消耗更多的額外資源（比如連接會一直佔着）。