理解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關閉的危害：1、  網絡情況不好時，如果主動方無TIME_WAIT等待，關閉前個連接后，主動方與被動方又建立起新的TCP連接，這時被動方重傳或延時過來的FIN包過來后會直接影響新的TCP連接；

2、  同樣網絡情況不好并且無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)，新的博文會在網咖社更新，歡迎瀏覽。