轉(zhuǎn)自：http://blog.csdn.net/shootyou/article/details/6622226

昨天解決了一個(gè)HttpClient調(diào)用錯(cuò)誤導(dǎo)致的服務(wù)器異常，具體過(guò)程如下：
http://blog.csdn.net/shootyou/article/details/6615051
里頭的分析過(guò)程有提到，通過(guò)查看服務(wù)器網(wǎng)絡(luò)狀態(tài)檢測(cè)到服務(wù)器有大量的CLOSE_WAIT的狀態(tài)。

在服務(wù)器的日常維護(hù)過(guò)程中，會(huì)經(jīng)常用到下面的命令：

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

它會(huì)顯示例如下面的信息：
TIME_WAIT 814CLOSE_WAIT 1FIN_WAIT1 1ESTABLISHED 634SYN_RECV 2LAST_ACK 1
常用的三個(gè)狀態(tài)是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動(dòng)關(guān)閉，CLOSE_WAIT 表示被動(dòng)關(guān)閉。

具體每種狀態(tài)什么意思，其實(shí)無(wú)需多說(shuō)，看看下面這種圖就明白了，注意這里提到的服務(wù)器應(yīng)該是業(yè)務(wù)請(qǐng)求接受處理的一方：

1.服務(wù)器保持了大量TIME_WAIT狀態(tài)
這種情況比較常見，一些爬蟲服務(wù)器或者WEB服務(wù)器（如果網(wǎng)管在安裝的時(shí)候沒有做內(nèi)核參數(shù)優(yōu)化的話）上經(jīng)常會(huì)遇到這個(gè)問(wèn)題，這個(gè)問(wèn)題是怎么產(chǎn)生的呢？
從上面的示意圖可以看得出來(lái)，TIME_WAIT是主動(dòng)關(guān)閉連接的一方保持的狀態(tài)，對(duì)于爬蟲服務(wù)器來(lái)說(shuō)他本身就是“客戶端”，在完成一個(gè)爬取任務(wù)之后，他就會(huì)發(fā)起主動(dòng)關(guān)閉連接，從而進(jìn)入TIME_WAIT的狀態(tài)，然后在保持這個(gè)狀態(tài)2MSL（max segment lifetime）時(shí)間之后，徹底關(guān)閉回收資源。為什么要這么做？明明就已經(jīng)主動(dòng)關(guān)閉連接了為啥還要保持資源一段時(shí)間呢？這個(gè)是TCP/IP的設(shè)計(jì)者規(guī)定的，主要出于以下兩個(gè)方面的考慮：
1.防止上一次連接中的包，迷路后重新出現(xiàn)，影響新連接（經(jīng)過(guò)2MSL，上一次連接中所有的重復(fù)包都會(huì)消失）2.可靠的關(guān)閉TCP連接。在主動(dòng)關(guān)閉方發(fā)送的最后一個(gè) ack(fin) ，有可能丟失，這時(shí)被動(dòng)方會(huì)重新發(fā)fin, 如果這時(shí)主動(dòng)方處于 CLOSED 狀態(tài) ，就會(huì)響應(yīng) rst 而不是 ack。所以主動(dòng)方要處于 TIME_WAIT 狀態(tài)，而不能是 CLOSED 。另外這么設(shè)計(jì)TIME_WAIT 會(huì)定時(shí)的回收資源，并不會(huì)占用很大資源的，除非短時(shí)間內(nèi)接受大量請(qǐng)求或者受到攻擊。
關(guān)于MSL引用下面一段話：

MSL 為一個(gè) TCP Segment (某一塊 TCP 網(wǎng)路封包) 從來(lái)源送到目的之間可續(xù)存的時(shí)間 (也就是一個(gè)網(wǎng)路封包在網(wǎng)路上傳輸時(shí)能存活的時(shí)間)，由於 RFC 793 TCP 傳輸協(xié)定是在 1981 年定義的，當(dāng)時(shí)的網(wǎng)路速度不像現(xiàn)在的網(wǎng)際網(wǎng)路那樣發(fā)達(dá)，你可以想像你從瀏覽器輸入網(wǎng)址等到第一個(gè) byte 出現(xiàn)要等 4 分鐘嗎？在現(xiàn)在的網(wǎng)路環(huán)境下幾乎不可能有這種事情發(fā)生，因此我們大可將 TIME_WAIT 狀態(tài)的續(xù)存時(shí)間大幅調(diào)低，好讓 連線埠 (Ports) 能更快空出來(lái)給其他連線使用。

再引用網(wǎng)絡(luò)資源的一段話：
值得一說(shuō)的是，對(duì)于基于TCP的HTTP協(xié)議，關(guān)閉TCP連接的是Server端，這樣，Server端會(huì)進(jìn)入TIME_WAIT狀態(tài)，可 想而知，對(duì)于訪問(wèn)量大的Web Server，會(huì)存在大量的TIME_WAIT狀態(tài)，假如server一秒鐘接收1000個(gè)請(qǐng)求，那么就會(huì)積壓240*1000=240，000個(gè) TIME_WAIT的記錄，維護(hù)這些狀態(tài)給Server帶來(lái)負(fù)擔(dān)。當(dāng)然現(xiàn)代操作系統(tǒng)都會(huì)用快速的查找算法來(lái)管理這些TIME_WAIT，所以對(duì)于新的 TCP連接請(qǐng)求，判斷是否hit中一個(gè)TIME_WAIT不會(huì)太費(fèi)時(shí)間，但是有這么多狀態(tài)要維護(hù)總是不好。
HTTP協(xié)議1.1版規(guī)定default行為是Keep-Alive，也就是會(huì)重用TCP連接傳輸多個(gè) request/response，一個(gè)主要原因就是發(fā)現(xiàn)了這個(gè)問(wèn)題。

也就是說(shuō)HTTP的交互跟上面畫的那個(gè)圖是不一樣的，關(guān)閉連接的不是客戶端，而是服務(wù)器，所以web服務(wù)器也是會(huì)出現(xiàn)大量的TIME_WAIT的情況的。

現(xiàn)在來(lái)說(shuō)如何來(lái)解決這個(gè)問(wèn)題。

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

下面來(lái)看一下我們網(wǎng)管對(duì)/etc/sysctl.conf文件的修改：

對(duì)于一個(gè)新建連接，內(nèi)核要發(fā)送多少個(gè) SYN 連接請(qǐng)求才決定放棄,不應(yīng)該大于255，默認(rèn)值是5，對(duì)應(yīng)于180秒左右時(shí)間

net.ipv4.tcp_syn_retries=2

net.ipv4.tcp_synack_retries=2

表示當(dāng)keepalive起用的時(shí)候，TCP發(fā)送keepalive消息的頻度。缺省是2小時(shí)，改為300秒

net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3

表示如果套接字由本端要求關(guān)閉，這個(gè)參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時(shí)間

net.ipv4.tcp_fin_timeout=30

表示SYN隊(duì)列的長(zhǎng)度，默認(rèn)為1024，加大隊(duì)列長(zhǎng)度為8192，可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)。

net.ipv4.tcp_max_syn_backlog = 4096

表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時(shí)，啟用cookies來(lái)處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉

net.ipv4.tcp_syncookies = 1

表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉

net.ipv4.tcp_tw_reuse = 1

表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉

net.ipv4.tcp_tw_recycle = 1

減少超時(shí)前的探測(cè)次數(shù)

net.ipv4.tcp_keepalive_probes=5

優(yōu)化網(wǎng)絡(luò)設(shè)備接收隊(duì)列

net.core.netdev_max_backlog=3000

修改完之后執(zhí)行/sbin/sysctl -p讓參數(shù)生效。

這里頭主要注意到的是net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle net.ipv4.tcp_fin_timeout net.ipv4.tcp_keepalive_*
這幾個(gè)參數(shù)。

net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的開啟都是為了回收處于TIME_WAIT狀態(tài)的資源。
net.ipv4.tcp_fin_timeout這個(gè)時(shí)間可以減少在異常情況下服務(wù)器從FIN-WAIT-2轉(zhuǎn)到TIME_WAIT的時(shí)間。
net.ipv4.tcp_keepalive_*一系列參數(shù)，是用來(lái)設(shè)置服務(wù)器檢測(cè)連接存活的相關(guān)配置。
關(guān)于keepalive的用途可以參考：http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

[2015.01.13更新]
注意tcp_tw_recycle開啟的風(fēng)險(xiǎn)：http://blog.csdn.net/wireless_tech/article/details/6405755

2.服務(wù)器保持了大量CLOSE_WAIT狀態(tài)
休息一下，喘口氣，一開始只是打算說(shuō)說(shuō)TIME_WAIT和CLOSE_WAIT的區(qū)別，沒想到越挖越深，這也是寫博客總結(jié)的好處，總可以有意外的收獲。

TIME_WAIT狀態(tài)可以通過(guò)優(yōu)化服務(wù)器參數(shù)得到解決，因?yàn)榘l(fā)生TIME_WAIT的情況是服務(wù)器自己可控的，要么就是對(duì)方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯(cuò)誤導(dǎo)致的。
但是CLOSE_WAIT就不一樣了，從上面的圖可以看出來(lái)，如果一直保持在CLOSE_WAIT狀態(tài)，那么只有一種情況，就是在對(duì)方關(guān)閉連接之后服務(wù)器程序自己沒有進(jìn)一步發(fā)出ack信號(hào)。換句話說(shuō)，就是在對(duì)方連接關(guān)閉之后，程序里沒有檢測(cè)到，或者程序壓根就忘記了這個(gè)時(shí)候需要關(guān)閉連接，于是這個(gè)資源就一直被程序占著。個(gè)人覺得這種情況，通過(guò)服務(wù)器內(nèi)核參數(shù)也沒辦法解決，服務(wù)器對(duì)于程序搶占的資源沒有主動(dòng)回收的權(quán)利，除非終止程序運(yùn)行。

如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情況，那么這篇日志也許對(duì)你有用：http://blog.csdn.net/shootyou/article/details/6615051
在那邊日志里頭我舉了個(gè)場(chǎng)景，來(lái)說(shuō)明CLOSE_WAIT和TIME_WAIT的區(qū)別，這里重新描述一下：
服務(wù)器A是一臺(tái)爬蟲服務(wù)器，它使用簡(jiǎn)單的HttpClient去請(qǐng)求資源服務(wù)器B上面的apache獲取文件資源，正常情況下，如果請(qǐng)求成功，那么在抓取完資源后，服務(wù)器A會(huì)主動(dòng)發(fā)出關(guān)閉連接的請(qǐng)求，這個(gè)時(shí)候就是主動(dòng)關(guān)閉連接，服務(wù)器A的連接狀態(tài)我們可以看到是TIME_WAIT。如果一旦發(fā)生異常呢？假設(shè)請(qǐng)求的資源服務(wù)器B上并不存在，那么這個(gè)時(shí)候就會(huì)由服務(wù)器B發(fā)出關(guān)閉連接的請(qǐng)求，服務(wù)器A就是被動(dòng)的關(guān)閉了連接，如果服務(wù)器A被動(dòng)關(guān)閉連接之后程序員忘了讓HttpClient釋放連接，那就會(huì)造成CLOSE_WAIT的狀態(tài)了。

所以如果將大量CLOSE_WAIT的解決辦法總結(jié)為一句話那就是：查代碼。因?yàn)閱?wèn)題出在服務(wù)器程序里頭啊。

參考資料：
1.windows下的TIME_WAIT的處理可以參加這位大俠的日志：http://blog.miniasp.com/post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx****
2.WebSphere的服務(wù)器優(yōu)化有一定參考價(jià)值：http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunelinux.html
3.各種內(nèi)核參數(shù)的含義：http://haka.sharera.com/blog/BlogTopic/32309.htm
4.linux服務(wù)器歷險(xiǎn)之sysctl優(yōu)化linux網(wǎng)絡(luò)：http://blog.csdn.net/chinalinuxzend/article/details/1792184