在nginx中，對於http1.0與http1.1是支援長連線的

我們知道，http請求是基於TCP協議之上的，那麼，當客戶端在發起請求前，需要先與服務端建立TCP連線，而每一次的TCP連線是需要三次握手來確定的，如果客戶端與服務端之間網路差一點，這三次互動消費的時間會比較多，而且三次互動也會帶來網路流量。當然，當連線斷開後，也會有四次的互動，當然對使用者體驗來說就不重要了。而http請求是請求應答式的，如果我們能知道每個請求頭與響應體的長度，那麼我們是可以在一個連線上面執行多個請求的，這就是所謂的長連線，但前提條件是我們先得確定請求頭與響應體的長度。對於請求來說，如果當前請求需要有body，如POST請求，那麼nginx就需要客戶端在請求頭中指定content-length來表明body的大小，否則返回400錯誤。也就是說，請求體的長度是確定的，那麼響應體的長度呢？先來看看http協議中關於響應body長度的確定：

1. 對於http1.0協議來說，如果響應頭中有content-length頭，則以content-length的長度就可以知道body的長度了，客戶端在接收body時，就可以依照這個長度來接收資料，接收完後，就表示這個請求完成了。而如果沒有content-length頭，則客戶端會一直接收資料，直到服務端主動斷開連線，才表示body接收完了。
2. 而對於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的數量。