linux TIME_WAIT 相關引數:

net.ipv4.tcp_tw_reuse = 0    表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉
net.ipv4.tcp_tw_recycle = 0  表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉
net.ipv4.tcp_fin_timeout = 60  表示如果套接字由本端要求關閉，這個引數決定了它保持在FIN-WAIT-2狀態的時間（可改為30，一般來說FIN-WAIT-2的連線也極少）

注意：

- 不像Windows 可以修改登錄檔修改2MSL 的值，linux 是沒有辦法修改MSL的，tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2狀態。

- tcp_tw_reuse 和SO_REUSEADDR 是兩個完全不同的東西。

1. tw_reuse，tw_recycle 必須在客戶端和服務端timestamps 開啟時才管用（預設開啟）

2. tw_reuse 只對客戶端起作用，開啟後客戶端在1s內回收

3. tw_recycle 對客戶端和伺服器同時起作用，開啟後在 3.5*RTO 內回收，RTO 200ms~ 120s 具體時間視網路狀況。

　　內網狀況比tw_reuse 稍快，公網尤其行動網路大多要比tw_reuse 慢，優點就是能夠回收服務端的TIME_WAIT數量

對於客戶端

1. 作為客戶端因為有埠65535問題，TIME_OUT過多直接影響處理能力，開啟tw_reuse 即可解決，不建議同時開啟tw_recycle，幫助不大。

2. tw_reuse 幫助客戶端1s完成連接回收，基本可實現單機6w/s請求，需要再高就增加IP數量吧。

3. 如果內網壓測場景，且客戶端不需要接收連線，同時tw_recycle 會有一點點好處。

4. 業務上也可以設計由服務端主動關閉連線

對於服務端

1. 開啟tw_reuse無效

2. 線上環境 tw_recycle 不要開啟

   伺服器處於NAT 負載後，或者客戶端處於NAT後（這是一定的事情，基本公司家庭網路都走NAT）；

　公網服務開啟就可能造成部分連線失敗，內網的話倒是可以視情況開啟；

   像我所在公司對外服務都放在NAT負載後面，負載會把timestamp 都給清空，好吧，就算你開啟也不起作用。

3. 伺服器TIME_WAIT 高怎麼辦

   不像客戶端有埠限制，處理大量TIME_WAIT Linux已經優化很好了，每個處於TIME_WAIT 狀態下連線記憶體消耗很少，

而且也能通過tcp_max_tw_buckets = 262144 配置最大上限，現代機器一般也不缺這點記憶體。

    下面像我們一臺每秒峰值1w請求的http 短連線服務，長期處於tw_buckets 溢位狀態，

tw_socket_TCP 佔用70M, 因為業務簡單服務佔用CPU 200% 執行很穩定。

slabtop

262230 251461  95%    0.25K  17482       15     69928K tw_sock_TCP

 ss -s
Total: 259 (kernel 494)
TCP:   262419 (estab 113, closed 262143, orphaned 156, synrecv 0, timewait 262143/0), ports 80

Transport Total     IP        IPv6
*         494       -         -        
RAW       1         1         0        
UDP       0         0         0        
TCP       276       276       0        
INET      277       277       0        
FRAG      0         0         0    

唯一不爽的就是：

系統日誌中overflow 錯誤一直在刷屏，也許該把buckets 調大一下了

TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow

5. 業務上也可以設計由客戶端主動關閉連線

原理分析

 1. MSL 由來

　　發起連線關閉方回覆最後一個fin 的ack，為避免對方ack 收不到、重發的或還在中間路由上的fin 把新連線給幹掉了，等個2MSL，4min。

　　也就是連線有誰關閉的那一方有time_wait問題，被關那方無此問題。

2. reuse、recycle

     通過timestamp的遞增性來區分是否新連線，新連線的timestamp更大，那麼小的timestamp的fin 就不會fin掉新連線。

3. reuse

     通過timestamp 遞增性，客戶端、伺服器能夠處理outofbind fin包

4. recycle

    對於服務端，同一個src ip，可能會是NAT後很多機器，這些機器timestamp遞增性無可保證，伺服器會拒絕非遞增請求連線。

 細節之處還得好好閱讀tcp 協議棧原始碼了

建議閱讀以下參考：