下文來自：http://blog.csdn.net/shootyou/article/details/6622226
昨天解決了一個HttpClient調用錯誤導致的服務器異常沦疾，具體過程如下：
http://blog.csdn.net/shootyou/article/details/6615051
里頭的分析過程有提到碍脏，通過查看服務器網絡狀態(tài)檢測到服務器有大量的CLOSE_WAIT的狀態(tài)。
在服務器的日常維護過程中踪旷，會經常用到下面的命令：
[plain] view plaincopyprint?
- 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
常用的三個狀態(tài)是：ESTABLISHED 表示正在通信搀崭，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。
具體每種狀態(tài)什么意思疑故，其實無需多說，看看下面這種圖就明白了弯菊，注意這里提到的服務器應該是業(yè)務請求接受處理的一方：
[圖片上傳失敗...(image-8bfa39-1527787441790)]
這么多狀態(tài)不用都記住纵势，只要了解到我上面提到的最常見的三種狀態(tài)的意義就可以了。一般不到萬不得已的情況也不會去查看網絡狀態(tài)管钳，如果服務器出了異常钦铁，百分之八九十都是下面兩種情況：
1.服務器保持了大量TIME_WAIT狀態(tài)
2.服務器保持了大量CLOSE_WAIT狀態(tài)
因為linux分配給一個用戶的文件句柄是有限的（可以參考：http://blog.csdn.net/shootyou/article/details/6579139），而TIME_WAIT和CLOSE_WAIT兩種狀態(tài)如果一直被保持才漆，那么意味著對應數目的通道就一直被占著牛曹，而且是“占著茅坑不使勁”，一旦達到句柄數上限醇滥，新的請求就無法被處理了黎比，接著就是大量Too Many Open Files異常超营，tomcat崩潰。阅虫。演闭。
下 面來討論下這兩種情況的處理方法，網上有很多資料把這兩種情況的處理方法混為一談颓帝，以為優(yōu)化系統(tǒng)內核參數就可以解決問題米碰，其實是不恰當的，優(yōu)化系統(tǒng)內核參 數解決TIME_WAIT可能很容易购城，但是應對CLOSE_WAIT的情況還是需要從程序本身出發(fā)÷雷現在來分別說說這兩種情況的處理方法：
1.服務器保持了大量TIME_WAIT狀態(tài)
這種情況比較常見蛙奖，一些爬蟲服務器或者WEB服務器（如果網管在安裝的時候沒有做內核參數優(yōu)化的話）上經常會遇到這個問題率碾，這個問題是怎么產生的呢玫芦？
從 上面的示意圖可以看得出來近哟，TIME_WAIT是主動關閉連接的一方保持的狀態(tài)，對于爬蟲服務器來說他本身就是“客戶端”挺峡，在完成一個爬取任務之后，他就 會發(fā)起主動關閉連接，從而進入TIME_WAIT的狀態(tài)魏身，然后在保持這個狀態(tài)2MSL（max segment lifetime）時間之后，徹底關閉回收資源蚪腐。為什么要這么做箭昵？明明就已經主動關閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規(guī)定 的回季，主要出于以下兩個方面的考慮：
1.防止上一次連接中的包家制，迷路后重新出現，影響新連接（經過2MSL泡一，上一次連接中所有的重復包都會消失）
2. 可靠的關閉TCP連接颤殴。在主動關閉方發(fā)送的最后一個 ack(fin) ，有可能丟失鼻忠，這時被動方會重新發(fā)fin, 如果這時主動方處于 CLOSED 狀態(tài) 涵但，就會響應 rst 而不是 ack。所以主動方要處于 TIME_WAIT 狀態(tài)帖蔓，而不能是 CLOSED 矮瘟。另外這么設計TIME_WAIT 會定時的回收資源，并不會占用很大資源的塑娇，除非短時間內接受大量請求或者受到攻擊澈侠。
關于MSL引用下面一段話：
[plain] view plaincopyprint?
- MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續(xù)存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由 於 RFC 793 TCP 傳輸協(xié)定是在 1981 年定義的埋酬，當時的網路速度不像現在的網際網路那樣發(fā)達哨啃，你可以想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎烧栋？在現在的網路環(huán)境下幾乎不可能有這種事情發(fā)生，因此我們大可將 TIME_WAIT 狀態(tài)的續(xù)存時間大幅調低棘催，好 讓 連線埠 (Ports) 能更快空出來給其他連線使用劲弦。
再引用網絡資源的一段話：
[plain] view plaincopyprint?
- 值 得一說的是，對于基于TCP的HTTP協(xié)議醇坝，關閉TCP連接的是Server端邑跪，這樣，Server端會進入TIME_WAIT狀態(tài)呼猪，可 想而知画畅，對于訪 問量大的Web Server，會存在大量的TIME_WAIT狀態(tài)宋距，假如server一秒鐘接收1000個請求轴踱，那么就會積壓 240*1000=240，000個 TIME_WAIT的記錄谚赎，維護這些狀態(tài)給Server帶來負擔淫僻。當然現代操作系統(tǒng)都會用快速的查找算法來管理這些 TIME_WAIT，所以對于新的 TCP連接請求壶唤，判斷是否hit中一個TIME_WAIT不會太費時間雳灵，但是有這么多狀態(tài)要維護總是不好。
- HTTP協(xié)議1.1版規(guī)定default行為是Keep-Alive闸盔，也就是會重用TCP連接傳輸多個 request/response悯辙，一個主要原因就是發(fā)現了這個問題。
也就是說HTTP的交互跟上面畫的那個圖是不一樣的迎吵，關閉連接的不是客戶端躲撰，而是服務器，所以web服務器也是會出現大量的TIME_WAIT的情況的击费。
現在來說如何來解決這個問題拢蛋。
解決思路很簡單，就是讓服務器能夠快速回收和重用那些TIME_WAIT的資源蔫巩。
下面來看一下我們網管對/etc/sysctl.conf文件的修改：
[plain] view plaincopyprint?
-
對于一個新建連接瓤狐，內核要發(fā)送多少個 SYN 連接請求才決定放棄,不應該大于255，默認值是5批幌，對應于180秒左右時間
net.ipv4.tcp_syn_retries=2
-
net.ipv4.tcp_synack_retries=2
-
表示當keepalive起用的時候础锐，TCP發(fā)送keepalive消息的頻度。缺省是2小時荧缘，改為300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3
-
表示如果套接字由本端要求關閉皆警，這個參數決定了它保持在FIN-WAIT-2狀態(tài)的時間
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
-
優(yōu)化網絡設備接收隊列
net.core.netdev_max_backlog=3000
[plain] view plaincopyprint?
修改完之后執(zhí)行/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狀態(tài)的資源。
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狀態(tài)
休息一下愉适，喘口氣犯助，一開始只是打算說說TIME_WAIT和CLOSE_WAIT的區(qū)別，沒想到越挖越深儡毕，這也是寫博客總結的好處也切，總可以有意外的收獲扑媚。
TIME_WAIT狀態(tài)可以通過優(yōu)化服務器參數得到解決腰湾，因為發(fā)生TIME_WAIT的情況是服務器自己可控的，要么就是對方連接的異常疆股，要么就是自己沒有迅速回收資源费坊，總之不是由于自己程序錯誤導致的。
但 是CLOSE_WAIT就不一樣了旬痹，從上面的圖可以看出來附井，如果一直保持在CLOSE_WAIT狀態(tài)，那么只有一種情況两残，就是在對方關閉連接之后服務器程 序自己沒有進一步發(fā)出ack信號永毅。換句話說，就是在對方連接關閉之后人弓，程序里沒有檢測到沼死，或者程序壓根就忘記了這個時候需要關閉連接，于是這個資源就一直 被程序占著崔赌。個人覺得這種情況意蛀，通過服務器內核參數也沒辦法解決耸别，服務器對于程序搶占的資源沒有主動回收的權利，除非終止程序運行县钥。
如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情況秀姐，那么這篇日志也許對你有用：http://blog.csdn.net/shootyou/article/details/6615051
在那邊日志里頭我舉了個場景，來說明CLOSE_WAIT和TIME_WAIT的區(qū)別若贮，這里重新描述一下：
服 務器A是一臺爬蟲服務器省有，它使用簡單的HttpClient去請求資源服務器B上面的apache獲取文件資源，正常情況下兜看，如果請求成功锥咸，那么在抓取完 資源后，服務器A會主動發(fā)出關閉連接的請求细移，這個時候就是主動關閉連接搏予，服務器A的連接狀態(tài)我們可以看到是TIME_WAIT。如果一旦發(fā)生異常呢弧轧？假設 請求的資源服務器B上并不存在雪侥，那么這個時候就會由服務器B發(fā)出關閉連接的請求，服務器A就是被動的關閉了連接精绎，如果服務器A被動關閉連接之后程序員忘了 讓HttpClient釋放連接速缨，那就會造成CLOSE_WAIT的狀態(tài)了。
所以如果將大量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的服務器優(yōu)化有一定參考價值：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優(yōu)化linux網絡：http://blog.csdn.net/chinalinuxzend/article/details/1792184
