❶ 伺服器TIME_WAIT和CLOSE_WAIT詳解和解決辦法
在日常的伺服器維護中，會經常用到如下命令。
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
它會顯示例如下面的信息：
TIME_WAIT 689
CLOSE_WAIT 2
FIN_WAIT1 1
ESTABLISHED 291
SYN_RECV 2
LAST_ACK 1
常用的三個狀態是：ESTABLISHED表示正在通信 、TIME_WAIT表示主動關閉、CLOSE_WAIT表示被動關閉。
如果伺服器出現了異常，很大的可能是出現了以下兩種情況：
我們也都知道Linux系統中分給每個用戶的文件句柄數是有限的，而TIME_WAIT和CLOSE_WAIT這兩種狀態如果一直被保持，那麼意味著對應數目的通道(此處應理解為socket，一般一個socket會佔用伺服器端一個埠，伺服器端的埠最大數是65535)一直被佔用，一旦達到了上限，則新的請求就無法被處理，接著就是大量Too Many Open Files異常，然後tomcat、nginx、apache崩潰。。。
下面來討論這兩種狀態的處理方法，網路上也有很多資料把這兩種情況混為一談，認為優化內核參數就可以解決，其實這是不恰當的。優化內核參數在一定程度上能解決time_wait過多的問題，但是應對close_wait還得從應用程序本身出發。
這種情況比較常見，一般會出現在爬蟲伺服器和web伺服器(如果沒做內核參數優化的話)上，那麼這種問題是怎麼產生的呢？
從上圖可以看出time_wait是主動關閉連接的一方保持的狀態，對於爬蟲伺服器來說它自身就是客戶端，在完成一個爬取任務後就會發起主動關閉連接，從而進入time_wait狀態，然後保持這個狀態2MSL時間之後，徹底關閉回收資源。這里為什麼會保持資源2MSL時間呢？這也是TCP/IP設計者規定的。
TCP要保證在所有可能的情況下使得所有的數據都能夠被正確送達。當你關閉一個socket時，主動關閉一端的socket將進入TIME_WAIT狀 態，而被動關閉一方則轉入CLOSED狀態，這的確能夠保證所有的數據都被傳輸。當一個socket關閉的時候，是通過兩端四次握手完成的，當一端調用 close()時，就說明本端沒有數據要發送了。這好似看來在握手完成以後，socket就都可以處於初始的CLOSED狀態了，其實不然。原因是這樣安 排狀態有兩個問題， 首先，我們沒有任何機制保證最後的一個ACK能夠正常傳輸，第二，網路上仍然有可能有殘余的數據包(wandering plicates)，我們也必須能夠正常處理。
TIMEWAIT就是為了解決這兩個問題而生的。
再引用網路中的一段話：
time_wait問題可以通過調整內核參數和適當的設置web伺服器的keep-Alive值來解決。因為time_wait是自己可控的，要麼就是對方連接的異常，要麼就是自己沒有快速的回收資源，總之不是由於自己程序錯誤引起的。但是close_wait就不一樣了，從上圖中我們可以看到伺服器保持大量的close_wait只有一種情況，那就是對方發送一個FIN後，程序自己這邊沒有進一步發送ACK以確認。換句話說就是在對方關閉連接後，程序里沒有檢測到，或者程序里本身就已經忘了這個時候需要關閉連接，於是這個資源就一直被程序佔用著。這個時候快速的解決方法是：
註：
直到寫這篇文章的時候我才完全弄明白之前工作中遇到的一個問題。程序員寫了爬蟲(php)運行在採集伺服器A上，程序去B伺服器上採集資源，但是A伺服器很快就發現出現了大量的close_wait狀態的連接。後來手動檢查才發現這些處於close_wait狀態的請求結果都是404，那就說明B伺服器上沒有要請求的資源。
下面引用網友分析的結論：
服 務器A是一台爬蟲伺服器，它使用簡單的HttpClient去請求資源伺服器B上面的apache獲取文件資源，正常情況下，如果請求成功，那麼在抓取完 資源後，伺服器A會主動發出關閉連接的請求，這個時候就是主動關閉連接，伺服器A的連接狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢？假設 請求的資源伺服器B上並不存在，那麼這個時候就會由伺服器B發出關閉連接的請求，伺服器A就是被動的關閉了連接，如果伺服器A被動關閉連接之後程序員忘了 讓HttpClient釋放連接，那就會造成CLOSE_WAIT的狀態了。
❷ 伺服器TIME_WAIT和CLOSE_WAIT詳解和解決辦法
伺服器維護過程中，經常遇到TIME_WAIT和CLOSE_WAIT兩種狀態，其中前者是主動關閉連接後保持的狀態，後者是被動關閉後等待對方響應的狀態。這兩種狀態過多可能導致資源佔用，影響新請求處理，引發Too Many Open Files異常。解決方法有所不同：
1. 處理大量TIME_WAIT狀態：常見於爬蟲或未優化的WEB伺服器。TIME_WAIT狀態保持2MSL後會自動回收，但可通過調整系統參數加速。例如，在/etc/sysctl.conf中修改相關參數，如keepalive，以促進資源重用。關於keepalive的詳細說明可參考相關資源。
2. 處理大量CLOSE_WAIT狀態：問題出在伺服器程序，而非系統參數。這種情況通常源於伺服器程序在對方關閉連接後未及時發送ack信號，導致資源佔用。解決方法在於審查代碼，找出程序中忘記關閉連接的邏輯，必要時可能需要終止程序運行。
總結來說，處理TIME_WAIT主要關注系統配置，而CLOSE_WAIT則需要深入代碼檢查，找出並修復程序中的問題。