TCP資料的傳輸過程

建立連線後，兩台主機就可以相互傳輸資料了。如下圖所示：

上圖給出了主機a分2次（分2個資料報）向主機b傳遞200位元組的過程。首先，主機a通過1個資料報傳送100個位元組的資料，資料報的 seq 號設定為 1200。主機b為了確認這一點，向主機a傳送 ack 包，並將 ack 號設定為 1301。

為了保證資料準確到達，目標機器在收到資料報（包括syn包、fin包、普通資料報等）包後必須立即回傳ack包，這樣傳送方才能確認資料傳輸成功。

此時 ack 號為 1301 而不是 1201，原因在於 ack 號的增量為傳輸的資料位元組數。假設每次 ack 號不加傳輸的位元組數，這樣雖然可以確認資料報的傳輸，但無法明確100位元組全部正確傳遞還是丟失了一部分，比如只傳遞了80位元組。因此按如下的公式確認 ack 號：

ack號 = seq號 + 傳遞的位元組數 + 1

與三次握手協議相同，最後加 1 是為了告訴對方要傳遞的 seq 號。

下面分析傳輸過程中資料報丟失的情況，如下圖所示：

上圖表示通過 seq 1301 資料報向主機b傳遞100位元組的資料，但中間發生了錯誤，主機b未收到。經過一段時間後，主機a仍未收到對於 seq 1301 的ack確認，因此嘗試重傳資料。

為了完成資料報的重傳，tcp套接字每次傳送資料報時都會啟動定時器，如果在一定時間內沒有收到目標機器傳回的 ack 包，那麼定時器超時，資料報會重傳。

上圖演示的是資料報丟失的情況，也會有 ack 包丟失的情況，一樣會重傳。

重傳超時時間（rto, retransmission time out）

這個值太大了會導致不必要的等待，太小會導致不必要的重傳，理論上最好是網路 rtt 時間，但又受制於網路距離與瞬態時延變化，所以實際上使用自適應的動態演算法（例如 jacobson 演算法和 karn 演算法等）來確定超時時間。

往返時間（rtt，round-trip time）表示從傳送端傳送資料開始，到傳送端收到來自接收端的 ack 確認包（接收端收到資料後便立即確認），總共經歷的時延。

重傳次數

tcp資料報重傳次數根據系統設定的不同而有所區別。有些系統，乙個資料報只會被重傳3次，如果重傳3次後還未收到該資料報的 ack 確認，就不再嘗試重傳。但有些要求很高的業務系統，會不斷地重傳丟失的資料報，以盡最大可能保證業務資料的正常互動。

最後需要說明的是，傳送端只有在收到對方的 ack 確認包後，才會清空輸出緩衝區中的資料。