建立連接后，兩臺主機就可以相互傳輸數據了。如下圖所示：

圖1：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 號。

下面分析傳輸過程中數據包丟失的情況，如下圖所示：

圖2：TCP套接字數據傳輸過程中發生錯誤

上圖表示通過 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 確認包后，才會清空輸出緩沖區中的數據。

總結

以上是生活随笔為你收集整理的详细分析TCP数据的传输过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。