http://www.vants.org/?post=36

Ø  為什麼TCP存在重傳

TCP是一種可靠的協議，在網路互動的過程中，由於TCP報文是封裝在IP協議中的，IP協議的無連線特性導致其可能在互動的過程中丟失，在這種情況下，TCP協議如何保障其傳輸的可靠性呢？

T C P通過在傳送資料報文時設定一個超時定時器來解決這種問題，如果在定時器溢位時還沒有收到來自對端對傳送報文的確認，它就重傳該資料報文。

Ø  導致重傳的常見狀況

1 資料報傳輸中途丟失

傳送端的資料報文在網路傳輸的過程中，被中間鏈路或中間裝置丟棄，這個過程如下圖所示：

2 接收端的ACK確認報文在傳輸中途丟失

傳送端傳送的資料報文到達了接受端，接受端也針對接收到的報文傳送了相應的ACK確認報文，但是，這個ACK確認報文被中間鏈路或中間裝置丟棄了，該過程如下圖所示：

3 接收端異常未響應ACK或被接收端丟棄

傳送端傳送的資料報文到達了接收端，但是，接收端由於種種原因，直接忽略該資料報文，或者接收到報文但並沒有傳送針對該報文的ACK確認報文，這個過程如下圖所示：

Ø  TCP重傳間隔時間和TCP重傳次數

一般TCP報文的重傳超時時間

TCP重傳時間間隔有著多種不同的演算法，最常見的就是《TCP/IP詳解卷1》中關於超時重傳的演算法。具體演算法不再贅述，請大家參考《TCP/IP詳解卷1》第21章《TCP的超時與重傳》。

SYN報文重傳間隔時間

在實際情況下，由於SYN報文是TCP連線的第一個報文，如果該報文在傳輸的過程中丟棄了，那麼傳送方則無法測量RTT，也就無法根據RTT來計算RTO。因此，SYN重傳的演算法就要簡單一些，SYN重傳時間間隔一般根據系統實現的不同稍有差別，windows系統一般將第一次重傳超時設為3秒，以後每次超時重傳時間為上一次的2倍，如下圖所示：

報文重傳的次數

TCP報文重傳的次數也根據系統設定的不同而有區分，有些系統，一個報文只會被重傳3次，如果重傳三次後還未收到該報文的確認，那麼就不再嘗試重傳，直接reset重置該TCP連線，但有些要求很高的業務應用系統，則會不斷的重傳被丟棄的報文，以盡最大可能保證業務資料的正常互動。

Ø  重傳對業務應用的影響

1 保障了業務的可靠性

TCP的重傳存在原因就是為了保障TCP的可靠性，正是由於TCP存在重傳的機制，那些基於TCP的業務應用在網路互動的過程中，不再擔心由於丟包、包損壞等導致的一系列應用問題了。

2  反映網路通訊的狀況

由於IP協議的不可靠性和網路系統的複雜性，少量的報文丟失和TCP重傳是正常的，但是如果業務互動過程中，存在大量的TCP重傳，會嚴重影響業務系統互動的效率，導致業務系統出現緩慢甚至無響應的情況發生。

一般而言，出現大量TCP重傳說明網路通訊的狀況非常糟糕，需要站在網路層的角度分析丟包和重傳的原因。

Ø  在實際的分析過程中，我們如何確認一個TCP報文是重傳報文

在實際的資料互動過程中，重傳報文一般具有以下兩個特徵：一是TCP互動序列號突然下降，二是其在TCP報頭中的序列號、資料長度、應用資料等引數跟前面某TCP報文一致。

1 序列號突然下降（一般是TCP重傳）

在TCP報文傳輸的過程中，因為其需要不斷的互動應用資料，因此，TCP報文的序列號會不斷的變大。正常情況下，TCP序列號不會出現下降的情況，出現序列號下降，一般都是TCP的重傳報文導致的。如下圖所示：

在上圖中，伺服器端互動的TCP報文序列號從24481開始一直處於不斷上升的趨勢，但是伺服器的第六個TCP報文序列號卻突然下降為20161，這個情形，基本上可以肯定這第六個TCP報文是前面某個報文的重傳報文。

2 根據序列號、長度甚至應用資料等確認是哪一個報文的重傳。

在資料互動過程中，一般情況下，TCP重傳的報文跟傳輸中被丟棄的報文在序列號、資料長度、應用欄位值上都是一樣的，我們可以利用這個特徵來確定某個具體的TCP報文是否是前面某個報文的重傳。下圖是一個客戶端存在重傳的資料流圖：

在上圖中，我們看到客戶端第三個報文和第四個報文的序列號（Seq）、下一個序列號（Next Seq）以及載荷長度都是一樣的，那麼我們可以肯定客戶端的第四個報文是客戶端第三個報文的重傳。

現在很多的網路分析工具的專家診斷系統基本上都可以針對TCP重傳直接告警，我們不需要在去深入分析這個過程了，為我們節省了大量的分析時間。