詳說TCP重傳問題的排查思路與實踐

TCP有重傳是正常的機制，為了保障數據傳輸可靠性。只是局域網環境，網絡質量有保障，因為網絡問題出現重傳應該極低;互聯網或城域網環境，線路復雜(可以想象下城市地下管網，錯綜復雜的電線桿等)，網絡質量不好保障，重傳出現概率較高。

TCP有重傳，也不一定是網絡層面的問題。也可能是接收端不存在，接收端receive buffer滿了，應用程序有異常鏈接未正常關閉等等等。

排查網絡問題，要掌握TCP/IP原理，真相都在一個一個的數據包里。以下是和TCP重傳比較關鍵的幾個參數。

超時重傳

在請求包發出去的時候，開啟一個計時器，當計時器達到時間之后，沒有收到ACK，則就進行重發請求的操作，一直重發直到達到重發上限次數或者收到ACK。

快速重傳

當接收方收到的數據包是不正常的序列號，那么接收方會重復把應該收到的那一條ACK重復發送，這個時候，如果發送方收到連續3條的同一個序列號的ACK，那么就會啟動快速重傳機制，把這個ACK對應的發送包重新發送一次。具體可以參考：

可能是鏈接的服務器或端口無法訪問

可能是網絡抖動

查看網絡區域埋點，查看網絡設備報警，看是否有區域網絡抖動2區域網絡沒問題的話。可以用常見問題：的方法縮小排查范圍

1、查看主機監控

1 網絡設備端口或光模塊異常等導致包checksum失敗 2 網絡路由收斂抖動 3 主機網絡驅動有bug，網絡設備有bug等

使用tsar -tcp -C 可以監控到tcp的retran屬性也即是重傳次數。

    tsar --tcp -C | sed 's/:/_/g;s/=/ /g' | xargs -n 2

感興趣的朋友可以直接執行以下監控 腳本獲取tcp相關的狀態監控數據，適用于open-falcon。

（1）在遇到丟包重傳的機器上抓包并使用wireshark 分析該包，注意因為重傳不是時刻都有的，所以抓包 命令是要持續執行以便捕捉到重傳的包。使用wireshark打開tcpdump的結果，在搜索框里入手tcp.analysis.retransmission 得到如下結果：

圖1 表明服務端發生了三次重傳動作。

（2）由于包比較多，我們可以使用wireshark的追蹤流功能獲取重傳相關的tcp流。

圖二 追蹤流-->TCP流 可以得到重傳相關的數據包

圖三 可以看出客戶端和服務端的請求與應答。

（3）解析重傳

特別需要說明的是：

NO 67,68 client端由于某些原因沒有收到正確的包數據，向server端發送dup ack，參考基礎知識提到的快速重傳

NO.68和NO.69之間的時間差200ms(關注time那一列，其他都是相差小于1ms)，server等待超時，于是重傳。

NO 73-74是client端發送了一個fin包并主動關閉連接。

這個案例僅僅發生一次，沒有復現，通過抓包解析出來分析沒有得到明確的結論。

本文總結自己工作過程中遇到的TCP重傳問題的解決過程 ，側重于大致的解決問題的思路與具體的實踐，理論知識偏少，大家有興趣的可以多查閱相關文章以便深入了解tcp的工作機制。

原文來自：  https://www.linuxprobe.com/tcp-retransmission.html