Linux服務器 大量的CLOSE_WAIT、TIME_WAIT解決辦法
系統上線之后，通過如下語句查看服務器時，發現有不少TIME_WAIT和CLOSE_WAIT。
netstat -an | awk ‘{print KaTeX parse error: Expected 'EOF', got '}' at position 2: 6}?' | sort | uniq…NF]} END {for(a in S) print a, S[a]}’

打印顯示如下：
TIME_WAIT 297
ESTABLISHED 53
CLOSE_WAIT 5

 TIME_WAIT：表示主動關閉，通過優化系統內核參數可容易解決。CLOSE_WAIT：表示被動關閉，需要從程序本身出發。ESTABLISHED：表示正在通信通過上網了解，總結如下：

一、TIME_WAIT（通過優化系統內核參數可容易解決）
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 會定時的回收資源，并不會占用很大資源的，除非短時間內接受大量請求或者受到攻擊。
解決方案很簡單，通過修改/etc/sysctl.conf文件，服務器能夠快速回收和重用那些TIME_WAIT的資源

服務器反應慢及解決辦法。#表示開啟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
#表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間
net.ipv4.tcp_fin_timeout=30

    生效，如下命令        

/sbin/sysctl -p

二、CLOSE_WAIT（需要從程序本身出發）
TCP狀態轉移要點
TCP協議規定，對于已經建立的連接，網絡雙方要進行四次握手才能成功斷開連接，如果缺少了其中某個步驟，將會使連接處于假死狀態，連接本身占用的資源不會被釋放。網絡服務器程序要同時管理大量連接，所以很有必要保證無用連接完全斷開，否則大量僵死的連接會浪費許多服務器資源.
客戶端TCP狀態遷移：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

     服務器TCP狀態遷移：      

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
當客戶端開始連接時，服務器還處于LISTENING，客戶端發一個SYN包后，他就處于SYN_SENT狀態,服務器就處于SYS收到狀態,然后互相確認進入連接狀態ESTABLISHED。

   TIME_WAIT狀態可以通過優化服務器參數得到解決，因為發生TIME_WAIT的情況是服務器自己可控的，要么就是對方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯誤導致的。但是CLOSE_WAIT就不一樣了，如果一直保持在CLOSE_WAIT狀態，那么只有一種情況，就是在對方關閉連接之后服務器程序自己沒有進一步發出ack信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，于是這個資源就一直被程序占著。個人覺得這種情況，通過服務器內核參數也沒辦法解決，服務器對于程序搶占的資源沒有主動回收的權利，除非終止程序運行。什么情況下，連接處于CLOSE_WAIT狀態呢？答案一：在被動關閉連接情況下，在已經接收到FIN，但是還沒有發送自己的FIN的時刻，連接處于CLOSE_WAIT狀態。通常來講，CLOSE_WAIT狀態的持續時間應該很短，正如SYN_RCVD狀態。但是在一些特殊情況下，就會出現連接長時間處于CLOSE_WAIT狀態的情況。答案二：出現大量close_wait的現象，主要原因是某種情況下對方關閉了socket鏈接，但是我方忙與讀或者寫，沒有關閉連接。代碼需要判斷socket，一旦讀到0，斷開連接，read返回負，檢查一下errno，如果不是AGAIN，就斷開連接。

---

tcp close_wait狀態。http://www.cnblogs.com/sunxucool/p/3449068.html
http://my.oschina.net/foxidea/blog/91431?fromerr=KjV5Lqr3
發現存在大量TIME_WAIT狀態的連接
tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT

通過調整內核參數解決
vi /etc/sysctl.conf

編輯文件，加入以下內容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

然后執行/sbin/sysctl -p讓參數生效。

shell wait命令。net.ipv4.tcp_syncookies = 1表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉；

net.ipv4.tcp_tw_reuse = 1表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉；

net.ipv4.tcp_tw_recycle = 1表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。

net.ipv4.tcp_fin_timeout修改系統默認的TIMEOUT時間

國外服務器界面卡解決方案，修改之后，再用命令查看TIME_WAIT連接數
netstat -ae|grep “TIME_WAIT” |wc –l

發現大量的TIME_WAIT 已不存在，mysql進程的占用率很快就降下來的，網站訪問正常。
不過很多時候，出現大量的TIME_WAIT狀態的連接，往往是因為網站程序代碼中沒有使用mysql.colse()，才導致大量的mysql TIME_WAIT.

如果你的服務器是Windows平臺，可以修改下面的注冊表鍵值：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“TcpTimedWaitDelay”=dword:0000001e

此值是TIME_WAIT狀態的最長時間。缺省為240秒，最低為30秒，最高為300秒。建議為30秒。

服務端大量time_wait原因，注釋：
（
1，TCP結束的過程如下:

Server Client

-------------- FIN --------------> server: fin_wait_1

<------------- ACK --------------- client: close_wait server:fin_wait_2

<------------- FIN --------------- client發出fin之后就關閉

-------------- ACK -------------> server發出ack后進入time_wait狀態

Time_Wait的默認時間是2倍的MLS，就是240秒鐘。MLS是TCP片在網上的最長存活時間。
TIME_Wait的主要作用是保證關閉的TCP端口不立即被使用。因為當網絡存在延遲時，可能當某個端口被關閉后，網絡中還有一些重傳的TCP片在發向這個端口，如果這個端口立即建立新的TCP連接，則可能會有影響。所以使用2倍的MSL時間來限制這個端口立即被使用。

現在的問題在于，4分鐘的時間有點長。
因此，Time_wait的影響，我想，首先每個TCP連接都各自有個數據結構，叫TCP Control Block.Time_wait的時候這個數據結構沒有被釋放。所以當有太多的TCP連接時，內存可能會被占用很多。

2，To ValorZ：TIME_WAIT狀態也稱為2MSL等待狀態，而不是2MLS，筆誤吧！

每個TCP報文在網絡內的最長時間，就稱為MSL（Maximum Segment Lifetime），它的作用和IP數據包的TTL類似。

RFC793指出，MSL的值是2分鐘，但是在實際的實現中，常用的值有以下三種：30秒，1分鐘，2分鐘。

注意一個問題，進入TIME_WAIT狀態的一般情況下是客戶端，大多數服務器端一般執行被動關閉，不會進入TIME_WAIT狀態，當在服務器端關閉某個服務再重新啟動時，它是會進入TIME_WAIT狀態的。

舉例：
1.客戶端連接服務器的80服務，這時客戶端會啟用一個本地的端口訪問服務器的80，訪問完成后關閉此連接，立刻再次訪問服務器的80，這時客戶端會啟用另一個本地的端口，而不是剛才使用的那個本地端口。原因就是剛才的那個連接還處于TIME_WAIT狀態。
2.客戶端連接服務器的80服務，這時服務器關閉80端口，立即再次重啟80端口的服務，這時可能不會成功啟動，原因也是服務器的連接還處于TIME_WAIT狀態。

windows

TcpTimedWaitDelay和MaxUserPort設置
描述：確定 TCP/IP 可釋放已關閉連接并重用其資源前，必須經過的時間。
關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀態或兩倍最大段生命周期（2MSL）狀態。
此時間期間，重新打開到客戶機和服務器的連接的成本少于建立新連接。
減少此條目的值允許 TCP/IP 更快地釋放已關閉的連接，為新連接提供更多資源。如果運行的應用程序需要快速釋放和創建新連接，而且由于 TIME_WAIT 中存在很多連接，導致低吞吐量，則調整此參數。
如何查看或設置： 使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注冊表子鍵并創建名為 TcpTimedWaitDelay 的新 REG_DWORD 值。
將此值設置為十進制 30，其為十六進制 0x0000001e。
該值將等待時間設置為 30 秒。
停止并重新啟動系統。 缺省值：0xF0，它將等待時間設置為 240 秒（4 分鐘）。
建議值：最小值為 0x1E，它將等待時間設置為 30 秒。
MaxUserPort 描述：確定在應用程序從系統請求可用用戶端口時，TCP/IP 可指定的最高端口號。
如何查看或設置： 使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注冊表子鍵并創建名為 MaxUserPort 的新 REG_DWORD 值。
停止并重新啟動系統。
缺省值：無 建議值：至少十進制 32768。
注：當在 Windows NT 或 Windows 2000 操作系統上調整 WebSphere Application Server 時，同時使用這兩個參數。
希望本站的知識能給您的工作、學習和生活帶來方便和樂趣！

server端tcp連接狀態大量TIME_WAIT解決方法：
在腳步中添加：
/*保證迭代結束后關閉所有的鏈接。相應的函數放于下面兩個函數之間，迭代后都會關閉連接。
web_set_sockets_option(“SHUTDOWN_MODE”,“ABRUPT”);//相當于迭代重置，初始化
…
web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”,“1”); //關閉連接
*/
web_set_sockets_option(“SHUTDOWN_MODE”,“ABRUPT”);
web_set_sockets_option(“SO_REUSE_ADDRESS”,“1”);//端口復用
web_set_sockets_option(“OVERLAPPED_SEND”,“0”);//禁用TTFB細分，問題即可解決，但是TTFB細分圖將不能再使用.