服務器大量TIME_WAIT和CLOSE_WAIT的原因及解決辦法

 Linux服務器下查看網絡連接的狀態

   netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'    

  

它會顯示例如下面的信息：

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

 

常用的三個狀態是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。

 

1.服務器保持了大量TIME_WAIT狀態

 這種情況比較常見，一些爬蟲服務器或者WEB服務器（如果網管在安裝的時候沒有做內核參數優化的話）上經常會遇到這個問題，這個問題是怎么產生的呢？

從 上面的示意圖可以看得出來，TIME_WAIT是主動關閉連接的一方保持的狀態，對於爬蟲服務器來說他本身就是“客戶端”，在完成一個爬取任務之后，他就 會發起主動關閉連接，從而進入TIME_WAIT的狀態，然后在保持這個狀態2MSL（max segment lifetime）時間之后，徹底關閉回收資源。為什么要這么做？明明就已經主動關閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規定 的，主要出於以下兩個方面的考慮：

1.防止上一次連接中的包，迷路后重新出現，影響新連接（經過2MSL，上一次連接中所有的重復包都會消失）
2. 可靠的關閉TCP連接。在主動關閉方發送的最后一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。另外這么設計TIME_WAIT 會定時的回收資源，並不會占用很大資源的，除非短時間內接受大量請求或者受到攻擊。

現在來說如何來解決這個問題。

 

解決思路很簡單，就是讓服務器能夠快速回收和重用那些TIME_WAIT的資源。

 

下面是一篇文章中提到的/etc/sysctl.conf文件的修改

#對於一個新建連接，內核要發送多少個 SYN 連接請求才決定放棄,不應該大於255，默認值是5，對應於180秒左右時間   
net.ipv4.tcp_syn_retries=2  
#net.ipv4.tcp_synack_retries=2  
#表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為300秒  
net.ipv4.tcp_keepalive_time=1200  
net.ipv4.tcp_orphan_retries=3  
#表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間  
net.ipv4.tcp_fin_timeout=30    
#表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數。  
net.ipv4.tcp_max_syn_backlog = 4096  
#表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉  
net.ipv4.tcp_syncookies = 1  
  
#表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉  
net.ipv4.tcp_tw_reuse = 1  
#表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉  
net.ipv4.tcp_tw_recycle = 1  
  
##減少超時前的探測次數   
net.ipv4.tcp_keepalive_probes=5   
##優化網絡設備接收隊列   
net.core.netdev_max_backlog=3000   

　　修改完之后執行/sbin/sysctl -p讓參數生效。

net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的開啟都是為了回收處於TIME_WAIT狀態的資源。

net.ipv4.tcp_fin_timeout這個時間可以減少在異常情況下服務器從FIN-WAIT-2轉到TIME_WAIT的時間。

net.ipv4.tcp_keepalive_*一系列參數，是用來設置服務器檢測連接存活的相關配置。

 

 修改方法：

 

sudo vi /etc/sysctl.conf

 

增加如下：

 

net.ipv4.tcp_tw_reuse = 1 

net.ipv4.tcp_tw_recycle = 1  
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.ip_local_port_range = 10000 65000 
net.ipv4.tcp_max_syn_backlog = 8192 
net.ipv4.tcp_max_tw_buckets = 10000

 

sudo /sbin/sysctl -p

 

實時生效

 2.服務器保持了大量CLOSE_WAIT狀態

TIME_WAIT狀態可以通過優化服務器參數得到解決，因為發生TIME_WAIT的情況是服務器自己可控的，要么就是對方連接的異常，要么就是自己沒有迅速回收資源，總之不是由於自己程序錯誤導致的。

但 是CLOSE_WAIT就不一樣了，從上面的圖可以看出來，如果一直保持在CLOSE_WAIT狀態，那么只有一種情況，就是在對方關閉連接之后服務器程 序自己沒有進一步發出ack信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，於是這個資源就一直 被程序占着。個人覺得這種情況，通過服務器內核參數也沒辦法解決，服務器對於程序搶占的資源沒有主動回收的權利，除非終止程序運行。

 

如果你使用的是HttpClient並且你遇到了大量CLOSE_WAIT的情況，那么這篇日志也許對你有用： http://blog.csdn.net/shootyou/article/details/6615051

在那邊日志里頭我舉了個場景，來說明CLOSE_WAIT和TIME_WAIT的區別，這里重新描述一下：

服 務器A是一台爬蟲服務器，它使用簡單的HttpClient去請求資源服務器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完 資源后，服務器A會主動發出關閉連接的請求，這個時候就是主動關閉連接，服務器A的連接狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢？假設 請求的資源服務器B上並不存在，那么這個時候就會由服務器B發出關閉連接的請求，服務器A就是被動的關閉了連接，如果服務器A被動關閉連接之后程序員忘了 讓HttpClient釋放連接，那就會造成CLOSE_WAIT的狀態了。

 

所以如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是：查代碼。因為問題出在服務器程序里頭啊。  

你的程序有問題！