內容轉載自https://blog.csdn.net/wangpengqi/article/details/17245349
當然，在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的數量。