我們有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的數量。
總結: (不考慮keepalive)
http1.0
帶content-length，body長度可知，客戶端在接收body時，就可以依據這個長度來接受數據。接受完畢后，就表示這個請求完畢了。客戶端主動調用close進入四次揮手。
不帶content-length ，body長度不可知，客戶端一直接受數據，直到服務端主動斷開
http1.1
帶content-length body長度可知 客戶端主動斷開
帶Transfer-encoding：chunked body會被分成多個塊，每塊的開始會標識出當前塊的長度，body就不需要通過content-length來指定了。但依然可以知道body的長度 客戶端主動斷開
不帶Transfer-encoding：chunked且不帶content-length 客戶端接收數據，直到服務端主動斷開連接。
即 ：如果能夠有辦法知道服務器傳來的長度，都是客戶端首先斷開。如果不知道就一直接收數據。知道服務端斷開。