TCP Retransmission 連接超時
kame 2019/3/17 33 TCP
記一次TCP 連接超時
背景
用戶反饋 >> 有出現支付超時、頁面問題 （部分情況會出現）
分析
檢查最近是否有上線導致 (並沒有上線) 排除
對接第三方平台 API接口是否有上線 (沒有) 排除
是否網絡延遲導致 （從前端 到后端 內網檢測沒問題ICMP包）,檢查從外網到第三方接口（ICMP沒有問題） 排除網絡問題導致
沒有辦法只能上tcpdump 抓包 (抓取雙方服務器 網絡通訊數據包) 發現 ICMP，http協議均無問題，只有TCP 出現問題,如圖所示：
難道是TCP連接跑滿了？
檢查本機機房並沒有，檢查對方服務器也沒有。
我擦 一頭霧水 怎么搞。。。。。。
冷靜分析一波。。。。。。。抽個煙想想。。。
從TCP 抓包上看吧 問題描述：TCP Retransmission
SYN重傳，第三次握手被重傳了，沒有收到服務器放的ACK確認 在服務器上抓包能捕獲SYN的請求，那就說明服務器端接收到了請求但是沒有回應ACK包，於是想起了以前nat環境下tw_recyle``的坑，當多個客戶端使用同一個外網IP通過NAT訪問內網服務器的時候，服務器如果在內核參數中打開了net.ipv4.tcp_tw_recycle = 1`
就有可能導致服務器收到SYN但是不會向客戶端發送SYN+ACK包。因為打開recyle參數后會識別這些包的時間戳（net.ipv4.tcp_timestamps = 1），但是nat過來的數據包又因為時間戳有可能不是順序的，導致服務器認為包不可信而丟棄。
故當我們在使用阿里雲的VPC虛擬專網的時候，使用彈性IP接入，一定要注意NAT的問題，在服務器參數上關閉net.ipv4.tcp_tw_recycle。 否則從一個ip來的不同客戶端請求很有可能導致大量請求失敗
原文鏈接
測試驗證是否是這問題。
修改 linux /etc/sysctl.conf
sysctl -p
1
2
驗證一波，然並卵的感覺
Timestamp value 成功的值都比較小
改/etc/sysctl.conf文件里面得
net.ipv4.tcp_timestamps=0
1
2
再次 抓包測試 TCP 連接沒有再出現 超時
搞定收工
timestamp擴展：
同時開啟timestamp（時間戳）和tw_recycle（快速回收）,會導致在一個MSL時間內只響應timestamp遞增的請求，對於時間戳較小的請求都拋棄了（不響應ack）
MSL擴展： RFC793中規定MSL為2分鍾，也就是說2分鍾內同一個ip的請求的時間戳要求遞增，不是遞增的話服務器不予響應。