服務器TIME_WAIT和CLOSE_WAIT詳解和解決辦法

 

來自：http://blog.csdn.net/shootyou/article/details/6622226

 

昨天解決了一個HttpClient調用錯誤致使的服務器異常，具體過程以下：

http://blog.csdn.net/shootyou/article/details/6615051

裏頭的分析過程有提到，經過查看服務器網絡狀態檢測到服務器有大量的CLOSE_WAIT的狀態。

 

在服務器的平常維護過程當中，會常常用到下面的命令：

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狀態

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

由於linux分配給一個用戶的文件句柄是有限的（能夠參考：http://blog.csdn.net/shootyou/article/details/6579139），而TIME_WAIT和CLOSE_WAIT兩種狀態若是一直被保持，那麼意味着對應數目的通道就一直被佔着，並且是「佔着茅坑不使勁」，一旦達到句柄數上限，新的請求就沒法被處理了，接着就是大量Too Many Open Files異常，tomcat崩潰。。。

下 面來討論下這兩種狀況的處理方法，網上有不少資料把這兩種狀況的處理方法混爲一談，覺得優化系統內核參數就能夠解決問題，實際上是不恰當的，優化系統內核參 數解決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 會定時的回收資源，並不會佔用很大資源的，除非短期內接受大量請求或者受到攻擊。

關於MSL引用下面一段話：

MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由 於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你能夠想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，所以我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好 讓 連線埠 (Ports) 能更快空出來給其餘連線使用。

再引用網絡資源的一段話：

值 得一說的是，對於基於TCP的HTTP協議，關閉TCP鏈接的是Server端，這樣，Server端會進入TIME_WAIT狀態，可 想而知，對於訪 問量大的Web Server，會存在大量的TIME_WAIT狀態，假如server一秒鐘接收1000個請求，那麼就會積壓 240*1000=240，000個 TIME_WAIT的記錄，維護這些狀態給Server帶來負擔。固然現代操做系統都會用快速的查找算法來管理這些 TIME_WAIT，因此對於新的 TCP鏈接請求，判斷是否hit中一個TIME_WAIT不會太費時間，可是有這麼多狀態要維護老是很差。
HTTP協議1.1版規定default行爲是Keep-Alive，也就是會重用TCP鏈接傳輸多個 request/response，一個主要緣由就是發現了這個問題。

也就是說HTTP的交互跟上面畫的那個圖是不同的，關閉鏈接的不是客戶端，而是服務器，因此web服務器也是會出現大量的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
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*

這幾個參數。

 

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_*一系列參數，是用來設置服務器檢測鏈接存活的相關配置。

關於keepalive的用途能夠參考： http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

 

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

休息一下，喘口氣，一開始只是打算說說TIME_WAIT和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的解決辦法總結爲一句話那就是：查代碼。由於問題出在服務器程序裏頭啊。

 

參考資料：

1.windows下的TIME_WAIT的處理能夠參加這位大俠的日誌： http://blog.miniasp.com/post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx

2.WebSphere的服務器優化有必定參考價值： http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunelinux.html

3.各類內核參數的含義： http://haka.sharera.com/blog/BlogTopic/32309.htm

4.linux服務器歷險之sysctl優化linux網絡： http://blog.csdn.net/chinalinuxzend/article/details/1792184