一次http請求，誰會先斷開TCP連接配接？

我們有2台内部http服務（nginx）：

201：這台伺服器部署的服務是account.api.91160.com，這個服務是供前端頁面調用；

202：這台伺服器部署的服務是hdbs.api.91160.com，    這個服務是供前端頁面調用；

近期發現，這2台伺服器的網絡連接配接中，TIME_WAIT 數量差别很大，201的TIME_WAIT大概20000+，202的TIME_WAIT大概1000 ，差距20倍；2台的請求量差不多，都是以上内部調用的連接配接，且服務模式也沒有什麼差異，為什麼連接配接數會差這麼大？

後找原因：是因為這2個子產品的調用程式由不同團隊寫的，調用方式不一樣，導緻一個是調用方（用戶端，PHP程式）主動斷開連接配接，一個是被調用方（服務端 201、202）主動斷開連接配接；因TIME_WAIT 産生在主動斷開連接配接的一方，是以導緻一台伺服器TIME_WAIT 數高，一台TIME_WAIT 數低；

這就有個細節，一次http請求，誰會先斷開TCP連接配接？什麼情況下用戶端先斷，什麼情況下服務端先斷？

百度後，找到原因，主要有http1.0和http1.1之間保持連接配接的差異以及http頭中connection、content-length、Transfer-encoding等參數有關；

 以下内容轉載：（http://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長度的确定：

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的數量。

轉載于:https://blog.51cto.com/biketiger/1716962