linux服務器上tcp有大量time_wait狀態的解決方法和原因解釋

毫無疑問，TCP中有關網絡編程最不容易理解的是它的TIME_WAIT狀態，TIME_WAIT狀態存在于主動關閉socket連接的一方。

TIME_WAIT狀態存在的理由：
TCP/IP協議就是這樣設計的，是不可避免的。主要有兩個原因:
1）可靠地實現TCP全雙工連接的終止
TCP協議在關閉連接的四次握手過程中，最終的ACK是由主動關閉連接的一端（后面統稱A端）發出的，如果這個ACK丟失，對方（后面統稱B端）將重發出最終的FIN，因此A端必須維護狀態信息（TIME_WAIT）允許它重發最終的ACK。如果A端不維持TIME_WAIT狀態，而是處于CLOSED 狀態，那么A端將響應RST分節，B端收到后將此分節解釋成一個錯誤。
因而，要實現TCP全雙工連接的正常終止，必須處理終止過程中四個分節任何一個分節的丟失情況，主動關閉連接的A端必須維持TIME_WAIT狀態 。
2）允許老的重復分節在網絡中消逝
TCP分節可能由于路由器異常而“迷途”，在迷途期間，TCP發送端可能因確認超時而重發這個分節，迷途的分節在路由器修復后也會被送到最終目的地，這個遲到的迷途分節到達時可能會引起問題。在關閉“前一個連接”之后，馬上又重新建立起一個相同的IP和端口之間的“新連接”，“前一個連接”的迷途重復分組在“前一個連接”終止后到達，而被“新連接”收到了。為了避免這個情況，TCP協議不允許處于TIME_WAIT狀態的連接啟動一個新的可用連接，因為TIME_WAIT狀態持續2MSL，就可以保證當成功建立一個新TCP連接的時候，來自舊連接重復分組已經在網絡中消逝。

MSL為最長分節生命期，任何TCP實現都必須為MSL選擇一個值，RFC 1122的建議值是2分鐘，不過Berkeley的實現傳統上改用30秒這個值，這意味著TIME_WAIT狀態的持續時間在1分鐘到4分鐘之間。MSL是任何IP數據報能夠在因特網中存活的最長時間。

在檢查服務器時，發現有很多連接超時情況出現，用netstat命令查看，tcp的time_wait狀態較多，需要進行優化。
1、 看一下現在time_wait的數量 netstat -an | grep TIME_WAIT | wc -l
2、發現系統存在大量TIME_WAIT狀態的連接，通過調整內核參數解決，在 /etc/sysctl.conf中加入
net.ipv4.tcp_tw_recycle = 1 （表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉）
net.ipv4.tcp_fin_timeout=30 （修改系統默認的 TIMEOUT 時間）

 然后執行 /sbin/sysctl -p 讓參數生效。
3、看看系統的tcp參數情況
 sysctl -a|grep tcp
     

修改生效后，time_wait數會明顯下降。
TIME_WAIT狀態存在的理由：
主動關閉的Socket端會進入TIME_WAIT狀態，并且持續2MSL時間長度，MSL就是maximum segment lifetime(最大分節生命期），這是一個IP數據包能在互聯網上生存的最長時間，超過這個時間將在網絡中消失。MSL在RFC 1122上建議是2分鐘，而源自berkeley的TCP實現傳統上使用30秒，因而，TIME_WAIT狀態一般維持在1-4分鐘。
明明就已經主動關閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規定的，主要出于以下兩個方面的考慮：
1、防止上一次連接中的包，迷路后重新出現，影響新連接（經過2MSL，上一次連接中所有的重復包都會消失）
2、可靠的關閉TCP連接。在主動關 閉方發送的最后一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處于 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以主動方要處于 TIME_WAIT 狀態，而不能是 CLOSED 。另外這么設計TIME_WAIT 會定時的回收資源，并不會占用很大資源的，除非短時間內接受大量請求或者受到攻擊。

參考文章： http://blog.csdn.net/shootyou/article/details/6622226

總結

以上是生活随笔為你收集整理的Linux服务器TIME_WAIT进程的解决与原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。