TCP Retransmission 鏈接超時

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的請求的時間戳要求遞增，不是遞增的話服務器不予響應。