系統上線之后，通過如下語句查看服務器時，發現有不少TIME_WAIT和CLOSE_WAIT。

netstat -n | awk '/^tcp/ {++S[$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，就斷開連接。