裡頭的分析過程有提到，通過檢視伺服器網路狀態檢測到伺服器有大量的CLOSE_WAIT的狀態。

在伺服器的日常維護過程中，會經常用到下面的命令：

1. 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引用下面一段話：

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

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

1. 值得一說的是，對於基於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不會太費時間，但是有這麼多狀態要維護總是不好。  
2. HTTP協議1.1版規定default行為是Keep-Alive，也就是會重用TCP連線傳輸多個 request/response，一個主要原因就是發現了這個問題。  

1. #對於一個新建連線，核心要傳送多少個 SYN 連線請求才決定放棄,不應該大於255，預設值是5，對應於180秒左右時間   
2. net.ipv4.tcp_syn_retries=2  
3. #net.ipv4.tcp_synack_retries=2  
4. #表示當keepalive起用的時候，TCP傳送keepalive訊息的頻度。預設是2小時，改為300秒  
5. net.ipv4.tcp_keepalive_time=1200  
6. net.ipv4.tcp_orphan_retries=3  
7. #表示如果套接字由本端要求關閉，這個引數決定了它保持在FIN-WAIT-2狀態的時間  
8. net.ipv4.tcp_fin_timeout=30    
9. #表示SYN佇列的長度，預設為1024，加大佇列長度為8192，可以容納更多等待連線的網路連線數。  
10. net.ipv4.tcp_max_syn_backlog = 4096  
11. #表示開啟SYN Cookies。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊，預設為0，表示關閉  
12. net.ipv4.tcp_syncookies = 1  
13. #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉  
14. net.ipv4.tcp_tw_reuse = 1  
15. #表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉  
16. net.ipv4.tcp_tw_recycle = 1  
17. ##減少超時前的探測次數   
18. net.ipv4.tcp_keepalive_probes=5   
19. ##優化網路裝置接收佇列   
20. net.core.netdev_max_backlog=3000