1.伺服器異常
如果伺服器出了異常，十之**都是以下兩種情況：
1.伺服器保持了大量time_wait狀態
2.伺服器保持了大量close_wait狀態
因為linux分配給乙個使用者的檔案控制代碼是有限的，而time_wait和close_wait兩種狀態如果一直被保持，那麼意味著對應數目的通道就一直被佔著，一旦達到控制代碼數上限，新的請求就無法被處理了，接著應用程式可能返回大量too many open files異常。
2.close_wait引發的問題
close_wait會占用乙個連線，網路可用連線小。數量過多，可能會引起網路效能下降，並占用系統非換頁記憶體。 尤其是在有連線池的情況下(比如httprequest)
會耗盡連線池的網路連線數，導致無法建立網路連線。
3.解決方法
下面來討論下這兩種情況的處理方法，優化系統核心引數解決time_wait可能很容易，可以通過修改/etc/sysctl.conf檔案解決；
但是應對close_wait的情況還是需要從程式本身出發。因為發生time_wait的情況是伺服器自己可控的，要麼就是對方連線的異常，要麼就是自己沒有迅速**資源，總之不是由於自己程式錯誤導致的。
從上面的圖可以看出來，如果一直保持在close_wait狀態，那麼只有一種情況，就是在對方關閉連線之後伺服器程式自己沒有進一步發出fin訊號，一般原因都是tcp連線沒有呼叫關閉方法。換句話說，就是在對方連線關閉之後，程式裡沒有檢測到，或者程式壓根就忘記了這個時候需要關閉連線，於是這個資源就一直被程式佔著。這種情況，通過伺服器核心引數也沒辦法解決，伺服器對於程式搶占的資源沒有主動**的權利，除非終止程式執行，一定程度上，可以使用tcp的keepalive功能，讓作業系統替我們自動清理掉close_wait連線。
tcp連線大量CLOSE WAIT
netstat n awk tcp end last ack 1 syn recv 15 close wait 7729 established 471 fin wait1 3 fin wait2 52 syn sent 1 time wait 725 從結果可以看到有大量的連線處於close wa...
TCP連線大量CLOSE WAIT狀態問題排查
close wait產生原因 close wait是被動關閉連線是形成的，根據tcp狀態機，伺服器端收到客戶端傳送的fin，tcp協議棧會自動傳送ack，鏈結進入close wait狀態。但如果伺服器端不執行socket的close 操作，狀態就不能由close wait遷移到last ack，則系...
tcp中close wait狀態出現的原因
close wait出現的原因 就是某一方在網路連線斷開後，對等方沒有檢測到這個錯誤 對方斷開 而沒有調 用 closesocket，導致了這個狀態的出現.模擬這樣乙個環境 伺服器192.168.1.112 4500在接收到乙個客戶端的連線後，休眠五秒後，伺服器關閉與客戶 端通訊的socket後正常...