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

圖1：TCP 套接字的數(shù)據(jù)交換過程

上圖給出了主機A分2次（分2個數(shù)據(jù)包）向主機B傳遞200字節(jié)的過程。首先，主機A通過1個數(shù)據(jù)包發(fā)送100個字節(jié)的數(shù)據(jù)，數(shù)據(jù)包的 Seq 號設(shè)置為 1200。主機B為了確認(rèn)這一點，向主機A發(fā)送 ACK 包，并將 Ack 號設(shè)置為 1301。

為了保證數(shù)據(jù)準(zhǔn)確到達(dá)，目標(biāo)機器在收到數(shù)據(jù)包（包括SYN包、FIN包、普通數(shù)據(jù)包等）包后必須立即回傳ACK包，這樣發(fā)送方才能確認(rèn)數(shù)據(jù)傳輸成功。

此時 Ack 號為 1301 而不是 1201，原因在于 Ack 號的增量為傳輸?shù)臄?shù)據(jù)字節(jié)數(shù)。假設(shè)每次 Ack 號不加傳輸?shù)淖止?jié)數(shù)，這樣雖然可以確認(rèn)數(shù)據(jù)包的傳輸，但無法明確100字節(jié)全部正確傳遞還是丟失了一部分，比如只傳遞了80字節(jié)。因此按如下的公式確認(rèn) Ack 號：

Ack號 = Seq號 + 傳遞的字節(jié)數(shù) + 1

與三次握手協(xié)議相同，最后加 1 是為了告訴對方要傳遞的 Seq 號。

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

圖2：TCP套接字?jǐn)?shù)據(jù)傳輸過程中發(fā)生錯誤

上圖表示通過 Seq 1301 數(shù)據(jù)包向主機B傳遞100字節(jié)的數(shù)據(jù)，但中間發(fā)生了錯誤，主機B未收到。經(jīng)過一段時間后，主機A仍未收到對于 Seq 1301 的ACK確認(rèn)，因此嘗試重傳數(shù)據(jù)。

為了完成數(shù)據(jù)包的重傳，TCP套接字每次發(fā)送數(shù)據(jù)包時都會啟動定時器，如果在一定時間內(nèi)沒有收到目標(biāo)機器傳回的 ACK 包，那么定時器超時，數(shù)據(jù)包會重傳。

上圖演示的是數(shù)據(jù)包丟失的情況，也會有 ACK 包丟失的情況，一樣會重傳。

重傳超時時間（RTO, Retransmission Time Out）

這個值太大了會導(dǎo)致不必要的等待，太小會導(dǎo)致不必要的重傳，理論上最好是網(wǎng)絡(luò) RTT 時間，但又受制于網(wǎng)絡(luò)距離與瞬態(tài)時延變化，所以實際上使用自適應(yīng)的動態(tài)算法（例如 Jacobson 算法和 Karn 算法等）來確定超時時間。

往返時間（RTT，Round-Trip Time）表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的 ACK 確認(rèn)包（接收端收到數(shù)據(jù)后便立即確認(rèn)），總共經(jīng)歷的時延。

重傳次數(shù)

TCP數(shù)據(jù)包重傳次數(shù)根據(jù)系統(tǒng)設(shè)置的不同而有所區(qū)別。有些系統(tǒng)，一個數(shù)據(jù)包只會被重傳3次，如果重傳3次后還未收到該數(shù)據(jù)包的 ACK 確認(rèn)，就不再嘗試重傳。但有些要求很高的業(yè)務(wù)系統(tǒng)，會不斷地重傳丟失的數(shù)據(jù)包，以盡最大可能保證業(yè)務(wù)數(shù)據(jù)的正常交互。

最后需要說明的是，發(fā)送端只有在收到對方的 ACK 確認(rèn)包后，才會清空輸出緩沖區(qū)中的數(shù)據(jù)。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。