TCP資料傳輸過程
阿新 • • 發佈：2019-01-08
建立連線後，兩臺主機就可以相互傳輸資料了。如下圖所示：
圖1：TCP 套接字的資料交換過程
上圖給出了主機A分2次（分2個數據包）向主機B傳遞200位元組的過程。首先，主機A通過1個數據包傳送100個位元組的資料，資料包的 Seq 號設定為 1200。主機B為了確認這一點，向主機A傳送 ACK 包，並將 Ack 號設定為 1301。
下面分析傳輸過程中資料包丟失的情況，如下圖所示：
圖2：TCP套接字資料傳輸過程中發生錯誤
上圖表示通過 Seq 1301 資料包向主機B傳遞100位元組的資料，但中間發生了錯誤，主機B未收到。經過一段時間後，主機A仍未收到對於 Seq 1301 的ACK確認，因此嘗試重傳資料。
為了完成資料包的重傳，TCP套接字每次傳送資料包時都會啟動定時器，如果在一定時間內沒有收到目標機器傳回的 ACK 包，那麼定時器超時，資料包會重傳。
最後需要說明的是，傳送端只有在收到對方的 ACK 確認包後，才會清空輸出緩衝區中的資料。
圖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 確認包後，才會清空輸出緩衝區中的資料。