Tcp鏈接出現大量ESTABLISHED鏈接解決方法

TCP狀態轉移要點
TCP協議規定，對於已經創建的鏈接，網絡雙方要進行四次握手才能成功斷開鏈接，若是缺乏了其中某個步驟，將會使鏈接處於假死狀態，鏈接自己佔用的資源不 會被釋放。網絡服務器程序要同時管理大量鏈接，因此頗有必要保證無用鏈接徹底斷開，不然大量僵死的鏈接會浪費許多服務器資源。在衆多TCP狀態中，最值得 注意的狀態有兩個：CLOSE_WAIT和TIME_WAIT。  

一、LISTENING狀態
FTP服務啓動後首先處於偵聽（LISTENING）狀態。

二、ESTABLISHED狀態
ESTABLISHED的意思是創建鏈接。表示兩臺機器正在通訊。

三、CLOSE_WAIT

    對方主動關閉鏈接或者網絡異常致使鏈接中斷，這時我方的狀態會變成CLOSE_WAIT 此時我方要調用close()來使得鏈接正確關閉

四、TIME_WAIT

    我方主動調用close()斷開鏈接，收到對方確認後狀態變爲TIME_WAIT。TCP協議規定TIME_WAIT狀態會一直持續2MSL(即兩倍的分 段最大生存期)，以此來確保舊的鏈接狀態不會對新鏈接產生影響。處於TIME_WAIT狀態的鏈接佔用的資源不會被內核釋放，因此做爲服務器，在可能的情 況下，儘可能不要主動斷開鏈接，以減小TIME_WAIT狀態形成的資源浪費。

    目前有一種避免TIME_WAIT資源浪費的方法，就是關閉socket的LINGER選項。但這種作法是TCP協議不推薦使用的，在某些狀況下這個操做可能會帶來錯誤。

五、SYN_SENT狀態

　 　SYN_SENT狀態表示請求鏈接，當你要訪問其它的計算機的服務時首先要發個同步信號給該端口，此時狀態爲SYN_SENT，若是鏈接成功了就變爲 ESTABLISHED，此時SYN_SENT狀態很是短暫。但若是發現SYN_SENT很是多且在向不一樣的機器發出，那你的機器可能中了衝擊波或震盪波 之類的病毒了。這類病毒爲了感染別的計算機，它就要掃描別的計算機，在掃描的過程當中對每一個要掃描的計算機都要發出了同步請求，這也是出現許多 SYN_SENT的緣由。

根據TCP協議定義的3次握手斷開鏈接規定,發起socket主動關閉的一方 socket將進入TIME_WAIT狀態,TIME_WAIT狀態將持續2個MSL(Max Segment Lifetime),在Windows下默認爲4分鐘,即240秒,TIME_WAIT狀態下的socket不能被回收使用. 具體現象是對於一個處理大量短鏈接的服務器,若是是由服務器主動關閉客戶端的鏈接,將致使服務器端存在大量的處於TIME_WAIT狀態的socket, 甚至比處於Established狀態下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,中止服務. TIME_WAIT是TCP協議用以保證被從新分配的socket不會受到以前殘留的延遲重發報文影響的機制,是必要的邏輯保證.

TCP協議中有TIME_WAIT這個狀態
主要有兩個緣由
1。防止上一次鏈接中的包，迷路後從新出現，影響新鏈接（通過2MSL，上一次鏈接中全部的重複包都會消失）
2。可靠的關閉TCP鏈接。在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會從新發
fin, 若是這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。因此主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。

查看系統TCP鏈接資源命令

查看網絡鏈接數：

# netstat -an |grep xx |wc -l        查看某個/特定ip的鏈接數
# netstat -an |grep TIME_WAIT|wc -l    查看鏈接數等待time_wait狀態鏈接數
# netstat -an |grep ESTABLISHED |wc -l    查看創建穩定鏈接數量

查看不一樣狀態的鏈接數數量

# netstat -an | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'
  LISTEN 8
  ESTABLISHED 2400
  FIN_WAIT1 2
  TIME_WAIT 6000

通常狀況下，系統的socket資源默認5000個。（非官方）

狀態：描述
CLOSED：無鏈接是活動的或正在進行
LISTEN：服務器在等待進入呼叫
SYN_RECV：一個鏈接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個鏈接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另外一邊已贊成釋放
ITMED_WAIT：等待全部分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT表示處理完畢，等待超時結束的請求數。
LAST_ACK：等待全部分組死掉

查看每一個ip跟服務器創建的鏈接數

# netstat -nat|grep "tcp"|awk ' {print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn
    444 10.71.177.123
    102 100.11.71.123
    101 49.14.55.132
（PS：正則解析：顯示第5列，-F : 以：分割，顯示列，sort 排序，uniq -c統計排序過程當中的重複行，sort -rn 按純數字進行逆序排序）

 

查看每一個ip創建的ESTABLISHED/TIME_OUT狀態的鏈接數

# netstat -nat|grep ESTABLISHED|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn
    24 103.56.195.17
    19 45.116.147.186
    18 103.56.195.18
    17 45.116.147.178

問題1：怎麼解決大量Time_Wait

經過調整內核參數：

vim /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 讓參數生效。

配置說明：

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=30修改系統默認的 TIMEOUT 時間。

若是以上配置調優後性能還不理想，可繼續修改一下配置：

vi /etc/sysctl.conf

net.ipv4.tcp_keepalive_time = 1200 
#表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改成20分鐘。

net.ipv4.ip_local_port_range = 1024 65000 
#表示用於向外鏈接的端口範圍。缺省狀況下很小：32768到61000，改成1024到65000。

net.ipv4.tcp_max_syn_backlog = 8192 
#表示SYN隊列的長度，默認爲1024，加大隊列長度爲8192，能夠容納更多等待鏈接的網絡鏈接數。

net.ipv4.tcp_max_tw_buckets = 5000 
#表示系統同時保持TIME_WAIT套接字的最大數量，若是超過這個數字，TIME_WAIT套接字將馬上被清除並打印警告信息。
默認爲180000，改成5000。對於Apache、Nginx等服務器，上幾行的參數能夠很好地減小TIME_WAIT套接字數量。
可是對於 Squid，效果卻不大。此項參數能夠控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死。

調優完畢，再壓一下看看效果吧。

# netstat -an | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'

問題2：怎麼解決請求結束後依然存在大量ESTABLISHED沒有被釋放

初步推斷是tomcat服務器回收session時出了問題，這個通常都跟服務器的Timeout設置有聯繫。

查看tomcat的配置文件 server.xml

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />
*****

檢查配置得出20000毫秒的時候acceptCount=」100」 ，明顯不合理，最大鏈接數也過小了吧。

因此進一步優化：

connectionTimeout="20000" 改成 connectionTimeout="100"

acceptCount="100"改成acceptCount="5000"

優化完畢，繼續壓測...

系統響應能力節節攀升，以前LoadRunner報錯問題直到壓倒***併發也再也沒有出現。

Action.c(380): 錯誤 -26608: 對於「http://www.cnlogs.com/javame」，HTTP 狀態代碼=504 (Gateway Time-out)