理解TIME_WAIT，完全弄清解決TCP: time wait bucket table overflow

    一直對這個問題知其然而不知其因此然，這些日子再次碰到，看了不少的資料，完全解決一下，呵呵，先上個圖，全部理解圍繞着此圖來看，此圖描述了四次揮手的整個過程：

經過此圖先說明幾個概念：

TIME_WAIT的產生條件：主動關閉方在發送四次揮手的最後一個ACK會變爲TIME_WAIT狀態，保留次狀態的時間爲兩個MSL（linux裏一個MSL爲30s，是不可配置的）

TIME_WAIT兩個MSL的做用：可靠安全的關閉TCP鏈接。好比網絡擁塞，主動方最後一個ACK被動方沒收到，這時被動方會對FIN開啓TCP重傳，發送多個FIN包，在這時還沒有關閉的TIME_WAIT就會把這些尾巴問題處理掉，不至於對新鏈接及其它服務產生影響。

TIME_WAIT佔用的資源：少許內存（查資料大概4K）和一個fd。

TIME_WAIT關閉的危害：一、  網絡狀況很差時，若是主動方無TIME_WAIT等待，關閉前個鏈接後，主動方與被動方又創建起新的TCP鏈接，這時被動方重傳或延時過來的FIN包過來後會直接影響新的TCP鏈接；

二、  一樣網絡狀況很差而且無TIME_WAIT等待，關閉鏈接後無新鏈接，當接收到被動方重傳或延遲的FIN包後，會給被動方回一個RST包，可能會影響被動方其它的服務鏈接。

TCP: time wait bucket table overflow產生緣由及影響：緣由是超過了linux系統tw數量的閥值。危害是超過閥值後﹐系統會把多餘的time-wait socket 刪除掉，而且顯示警告信息，若是是NAT網絡環境又存在大量訪問，會產生各類鏈接不穩定斷開的狀況。

 

 

相關參數優化調整（固然得根據服務器的實際狀況配置，這裏着重講參數意義）：

    既然知道了TIME_WAIT的用意了，儘可能按照TCP的協議規定來調整，對於tw的reuse、recycle實際上是違反TCP協議規定的，服務器資源容許、負載不大的條件下，儘可能不要打開，當出現TCP: time wait bucket table overflow，儘可能調大下面參數：

tcp_max_tw_buckets = 256000 

調整次參數的同時，要調整TIME_WAIT_2到TIME_WAIT的超時時間，默認是60s，優化到30s：

net.ipv4.tcp_fin_timeout = 30

其它TCP自己的配合參數相似與synack重傳次數、syn重傳次數等之後介紹，優化後也是有所益處的。

 

     下面再說一下linux裏TIME_WAIT專有的優化參數reuse、recycle，默認也都是關閉的，這兩個參數必須在timestamps打開的前提下才能生效使用：

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_tw_reuse = 1

機器做爲客戶端時起做用，開啓後time_wait在一秒內回收

net.ipv4.tcp_tw_recycle = 0 （不要開啓，如今互聯網NAT結構不少，可能直接沒法三次握手）

開啓後在3.5*RTO(RTO時間是根據RTT時間計算而來)內回收TIME_WAIT，並60s內同一源ip主機的socket connect請求中的timestamp必須是遞增的，對於服務端，同一個源ip可能會是NAT後不少機器，這些機器timestamp遞增性無可保證，服務器會拒絕非遞增請求鏈接，直接致使不能三次握手。

自建我的原創站運維網咖社(www.net-add.com)，新的博文會在網咖社更新，歡迎瀏覽。