tcp_tw_recycle

問題背景

服務經過F5使用lb的方式對外提供服務，client鏈接某LB VIP的時候，發現client發送了syn，server直接回了rst斷了鏈接。
上網查詢相關信息，發現不少的狀況是由於打開了tcp_tw_recycle致使的(特別是在NAT的狀況下)，那麼tw_recycle和tw_reuse有什麼聯繫和關聯，又是如何觸發問題的呢。

tw_recyle

客戶端開啓了選項後，tw的socket不會等待2msl的時間，rto時間後就會被釋放，對於server端來講，可能某個時刻會有大量的tw連接。打開tw_recycle的話，會打開協議棧的Per-host PAWS機制。致使server看到timestamp小於當前值的話，會rst掉報文，這在nat的狀況下會帶來必定的問題，由於sip,dip,dport都是固定，鏈接數量到必定程度的話，必定會有sport的重複，然而各個client的timestamp又不能保證時序，會帶來問題。
http://perthcharles.github.io...
那tw_recycle的機制又是如何實現的呢，開啓了msl，它將會在超時重發（RTO）間隔後移除（底層會根據當前鏈接的延遲情況根據RTT來計算RTO值)。可是4.1內核版本以後，此內核參數已經廢棄

1. timestamp參數是如何生效的。
2. 打開tw_recycle，爲什麼會致使PAWS。

開啓了tw_recycle後，tw socket會當即回收。這時若是ack報文丟失，那麼client會重傳fin報文，此時server可能已經使用此socket創建新的鏈接了，而且有報文的交互，在這種狀況下，server須要rst掉此連接。那麼如何區分是以前的連接，仍是新建的連接，協議棧用timestamp來區分，timestamp小於當前的，認定是以前的連接，統一rst。
爲何tw_reuse不會有這樣的問題，由於tw_reuse是影響主動發出的連接，tw_reuse的socket發出syn,被對端ack（因爲number不一致），本端會迴應rst，並重傳syn包，不影響鏈接的創建。
可是tw_recycle會rst掉對端的syn，此時直接影響到鏈接的創建。換句話說，若是tw_recycle的socket，被複用主動發起syn的話，效果和tw_reuse應該一致。

因此主要區別是
tw_reuse被適用於主動發起的連接，若是五元組匹配
tw_recycle直接釋放tw_socket, 影響主動發起和接收的連接。接收的連接會被rst

tw_reuse

tw_reuse只針對出向的鏈接有效。舉例
服務器的某個socket鏈接如今正處在time_wait的狀態。按照正常的邏輯來講，在這個TW socket被回收以前，都不能使用這個ip和port創建新的tcp鏈接。可是在開啓了tw_reuse的狀況下，則能夠複用這個socket，發出syn包，創建新的鏈接。

RTT&RTO

RTO: Retransmission TimeOut
RTT: Round Trip Time(往返時間：鏈路傳輸時間+路由器排隊/處理時間+末端處理時間)

https://juejin.im/post/5c0642...