http://www.1398.net/blog/user1/cloudy/archives/2007/682.html
TIME_WAIT和CLOSE_WAIT
1.服務(wù)器保持了大量TIME_WAIT狀態(tài)
這種情況比較常見，一些爬蟲服務(wù)器或者WEB服務(wù)器（如果網(wǎng)管在安裝的時候沒有做內(nèi)核參數(shù)優(yōu)化的話）上經(jīng)常會遇到這個問題，這個問題是怎么產(chǎn)生的呢？
從上面的示意圖可以看得出來，TIME_WAIT是主動關(guān)閉連接的一方保持的狀態(tài)，對于爬蟲服務(wù)器來說他本身就是“客戶端”，在完成一個爬取任務(wù)之后，他就會發(fā)起主動關(guān)閉連接，從而進(jìn)入TIME_WAIT的狀態(tài)，然后在保持這個狀態(tài)2MSL（max segment lifetime）時間之后，徹底關(guān)閉回收資源。為什么要這么做？明明就已經(jīng)主動關(guān)閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設(shè)計者規(guī)定的，主要出于以下兩個方面的考慮：
1.防止上一次連接中的包，迷路后重新出現(xiàn)，影響新連接（經(jīng)過2MSL，上一次連接中所有的重復(fù)包都會消失）
2.可靠的關(guān)閉TCP連接。在主動關(guān)閉方發(fā)送的最后一個 ack(fin) ，有可能丟失，這時被動方會重新發(fā)fin, 如果這時主動方處于 CLOSED 狀態(tài) ，就會響應(yīng) rst 而不是 ack。所以主動方要處于 TIME_WAIT 狀態(tài)，而不能是 CLOSED 。另外這么設(shè)計TIME_WAIT 會定時的回收資源，并不會占用很大資源的，除非短時間內(nèi)接受大量請求或者受到攻擊。
2.服務(wù)器保持了大量CLOSE_WAIT狀態(tài)
設(shè)計CLOSE_WAIT的原因是看是否還有數(shù)據(jù)發(fā)送給對方
產(chǎn)生CLOSE_WAIT的原因是對方主動關(guān)閉之后自己沒有ACK 或者沒有FIN之類的
TIME_WAIT狀態(tài)可以通過優(yōu)化服務(wù)器參數(shù)得到解決，因為發(fā)生TIME_WAIT的情況是服務(wù)器自己可控的，要么就是對方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯誤導(dǎo)致的。
但是CLOSE_WAIT就不一樣了，從上面的圖可以看出來，如果一直保持在CLOSE_WAIT狀態(tài)，那么只有一種情況，就是在對方關(guān)閉連接之后服務(wù)器程序自己沒有進(jìn)一步發(fā)出ack信號。換句話說，就是在對方連接關(guān)閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關(guān)閉連接，于是這個資源就一直被程序占著。個人覺得這種情況，通過服務(wù)器內(nèi)核參數(shù)也沒辦法解決，服務(wù)器對于程序搶占的資源沒有主動回收的權(quán)利，除非終止程序運行。
ref. http://blog.csdn.net/sunvince/article/details/6622796