與TIME_WAIT相關的幾個內核參數

問題

公司用瀏覽器訪問線上服務一會失敗一會成功，經過ssh鏈接服務器排查時發現ssh也是這樣；

檢查

抓包後發現創建鏈接的請求已經到了服務器，但它沒有響應；

糾結了很久，後來在騰訊雲技術支持及查了相關資料後發現是開啓了net.ipv4.tcp_tw_recycle致使的，將其設爲0便可解決；

緣由

收集了幾個與TIME_WAIT相關的內核參數：

net.ipv4.tcp_timestamps　　　　 默認開啓（1），數據包加時間戳，須要兩端都開啓，能夠防止高速率寬帶時引發的序號迴繞（序號不夠用從新開始了），能夠精確計算出RTT(往返時延）
net.ipv4.tcp_tw_reuse　　　　　　默認關閉（0），容許TIME_WAIT的socket在超過1秒後重用，做用於發起鏈接的client端
net.ipv4.tcp_tw_recycle　　　　　默認關閉（0），容許快速回收處於TIME_WAIT的socket，做用於接受鏈接的server端
net.ipv4.ip_local_port_range　　默認（32768 61000），可用的端口範圍
net.ipv4.tcp_max_tw_buckets　　 默認（180000），容許處於TIME_WAIT狀態socket的最大數量

若TIME_WAIT過多，能夠開啓reuse和recycle來快速回收，值得注意的一點是，reuse和recycle須要timestamps開啓纔會生效，固然timestamps通常都是開啓的；

上面問題的緣由是，當多個client經過nat方式聯網時（一個局域網）它們的源ip相同但發出的時間戳極可能是亂的，而開啓了recycle的server端就會丟棄這些混亂的數據包，因而現象就是有時能連上有時不行；

至於reuse，開啓可能致使端口重用後還會收到上個socket延遲到達的數據，這個通常問題不大，應用程序都會校驗；

雖然reuse在client端配置有效，而recycle在server端，但如今不少機器都是接受鏈接後再去鏈接別人，因此視狀況而定吧。

總結

官方文檔是不建議開啓reuse和recycle的，由於違反了tcp協議，因此臨時開啓來解決異常狀況後應及時關閉；

若TIME_WAIT過多致使系統很慢（Linux對其優化很好，且如今不缺這點內存，因此通常不會），能夠下降tcp_max_tw_buckets，阿里雲和騰訊雲分別默認設置爲了5000、65536；

若端口不足能夠考慮加大 ip_local_port_range，最大不超過：1024  65535；

TIME_WAIT過多長遠的解決方式仍是經過程序開發方面：

1. 代碼中及時正確的調用socket的close；

2. 讓client端主動斷開鏈接，而不是server端；

3. 儘可能使用長鏈接，而不是短鏈接；

 

over