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

導讀	本文總結自己工作過程中遇到的TCP重傳問題的解決過程 ，側重於大致的解決問題的思路與具體的實踐，理論知識偏少，大家有興趣的可以多查閱相關文章以便深入瞭解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的工作機制。

原文來自：