作者：Zhang_Jiawen ； 來自：Dell技術(shù)社區(qū)

TCP 的主要任務(wù)是很簡單：打包和發(fā)送數(shù)據(jù)。TCP 與其他協(xié)議的不同之處在于使用滑動窗口來管理基本數(shù)據(jù)收發(fā)過程，同時確保數(shù)據(jù)流的有效及可靠傳輸，從而不致發(fā)送速率明顯快于接收速率。

本文將描述 TCP是如何確保設(shè)備可靠、有效地進行傳輸?shù)摹Ｊ紫汝U述 TCP檢測丟失片段以及重傳的基本方法，之后介紹 TCP如何判斷一個片段為丟失片段。

一、TCP 片段重傳計時器以及重傳隊列:

檢測丟失片段并對之重傳的方法概念上是很簡單的。每一次發(fā)送一個片段，就開啟一個重傳計時器。計時器有一個初始值并隨時間遞減。

如果在片段接收到確認(rèn)之前計時器超時，就重傳片段。TCP 使用了這一基本技術(shù)，但實現(xiàn)方式稍有不同。原因在于為了提高效率需要一次處理多個未被確認(rèn)的片段，以保證每一個在恰當(dāng)?shù)臅r間重傳。

二、TCP 按照以下特定順序工作：

放置于重傳隊列中，計時器開始 包含數(shù)據(jù)的片段一經(jīng)發(fā)送，片段的一份復(fù)制就放在名為重傳隊列的數(shù)據(jù)結(jié)構(gòu)中，此時啟動重傳計時器。

因此，在某些時間點，每一個片段都會放在隊列里。隊列按照重傳計時器的剩余時間來排列，因此 TCP 軟件可追蹤那幾個計時器在最短時間內(nèi)超時。

確認(rèn)處理 如果在計時器超時之前收到了確認(rèn)信息，則該片段從重傳隊列中移除。

重傳超時 如果在計時器超時之前沒有收到確認(rèn)信息，則發(fā)生重傳超時，片段自動重傳。當(dāng)然，相比于原片段，對于重傳片段并沒有更多的保障機制。

因此，重傳之后該片段還是保留在重傳隊列里。重傳計時器被重啟，重新開始倒計時。如果重傳之后沒有收到確認(rèn)，則片段會再次重傳并重復(fù)這一過程。

在某些情況下重傳也會失敗。我們不想要 TCP永遠重傳下去，因此 TCP只會重傳一定數(shù)量的次數(shù)，并判斷出現(xiàn)故障終止連接。

但是我們怎樣知道一個片段被完全確認(rèn)呢？重傳是基于片段的，而 TCP確認(rèn)信息是基于序列號累積的。每次當(dāng)設(shè)備A發(fā)送片段給設(shè)備B，設(shè)備 B查看該片段的確認(rèn)號字段。

所有低于該字段的序列號都已經(jīng)被設(shè)備 A接收了。因此，當(dāng)片段中所發(fā)送的所有字節(jié)的序列號都比設(shè)備A到設(shè)備B的最后一個確認(rèn)號小的時候，一個從設(shè)備 B發(fā)到設(shè)備 A的片段被認(rèn)為是確認(rèn)了。這是通過計算片段中最后一個序列號結(jié)合片段的數(shù)據(jù)字段來實現(xiàn)的。

讓我們以下圖為例來說明一下確認(rèn)和重傳是怎樣工作的。假設(shè)連接中的服務(wù)器發(fā)出了四個連續(xù)片段(號碼從1開始)

• 片段1 序列號字段是1片段長度80。所以片段1中最后一個序列號是80。
• 片段2 序列號是81片段長度是120。片段2中最后一個序列號是200。
• 片段3 序列號是201片段長度是160。片段3中最后一個序列號是360。
• 片段4 序列號是361片段長度是140。片段3中最后一個序列號是500。

這些片段是一個接一個發(fā)送的，而無需等待前一個發(fā)送得到確認(rèn)。這是 TCP滑動窗口的一個主要優(yōu)勢(細(xì)說 TCP滑動窗口)。

假設(shè)客戶端接收到前兩個傳輸，它會發(fā)回一條確認(rèn)消息確認(rèn)號為201。從而告知服務(wù)器前兩個片段已經(jīng)被客戶端成功接收了，它們從重傳隊列中移除(并且服務(wù)器發(fā)送窗口右移200字節(jié))。

在接收到確認(rèn)號361或更高的片段之前，片段3會保留在重傳隊列中；片段4需要確認(rèn)號501或更高。

現(xiàn)在，讓我們進一步假設(shè)傳輸過程中片段3丟失了，但片段4被接收到了。客戶端將片段4保存在接收buffer中，但是不需要確認(rèn)，因為TCP是累積確認(rèn)機制——確認(rèn)片段4表示片段3也接收到了，但實際上并沒有。

因此，客戶端需要等待片段3。實際上，服務(wù)器端片段3的重傳計時器會超時，服務(wù)器之后重傳片段3。之后客戶端收到，然后發(fā)送片段3和4的確認(rèn)信息給服務(wù)器。

還有一個重要的問題，服務(wù)器將如何處理片段4呢？

雖然客戶端在等待片段3，服務(wù)器沒有收到反饋，所以它并不知道片段3丟失了，同樣它也不知道片段4發(fā)生了什么(以及接下來傳輸?shù)臄?shù)據(jù))。

很有可能客戶端已經(jīng)接收到了片段4但是不能確認(rèn)，也有可能片段4也丟失了。一些實現(xiàn)中會選擇僅僅重傳片段3，也有些會把3和4都重傳。

最后一個問題是重傳隊列中所使用片段重傳計時器的值。如果設(shè)置過低，會發(fā)生過量重傳，如果設(shè)置過高，重傳丟失片段會減弱性能。必須通過一個稱為自適應(yīng)重傳的過程來動態(tài)調(diào)整這個值，接下來的章節(jié)會講到。

總結(jié)

以上是生活随笔為你收集整理的tcp分包传图片 如何还原_技术控丨超详细解析TCP重传机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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