[轉]網絡基本功09-細說TCP重傳
❝本文由Zhang_Jiawen發表於Dell Technology"網絡基本功"
如有侵犯版權,還請這位頭像萌萌的大姐姐前輩聯繫我商討刪帖,道歉,賠償,下跪等事宜.
❞
TCP的主要任務是很簡單：「打包和發送數據」。TCP與其他協議的不同之處在於使用滑動窗口來管理基本數據收發過程，同時確保數據流的有效及可靠傳輸，從而不致發送速率明顯快於接收速率。本文將描述TCP是如何確保設備可靠、有效地進行傳輸的。首先闡述TCP檢測丟失片段以及重傳的基本方法，之後介紹TCP如何判斷一個片段爲丟失片段。
TCP片段重傳計時器以及重傳隊列
檢測丟失片段並對之重傳的方法概念上是很簡單的。每一次發送一個片段，就開啓一個重傳計時器。計時器有一個初始值並隨時間遞減。如果在片段接收到確認之前計時器超時，就重傳片段。TCP使用了這一基本技術，但實現方式稍有不同。原因在於爲了提高效率需要一次處理多個未被確認的片段，以保證每一個在恰當的時間重傳。TCP按照以下特定順序工作：
「放置於重傳隊列中，計時器開始」 包含數據的片段一經發送，片段的一份複製就放在名爲重傳隊列的數據結構中，此時啓動重傳計時器。因此，在某些時間點，每一個片段都會放在隊列裏。隊列按照重傳計時器的剩餘時間來排列，因此TCP軟件可追蹤那幾個計時器在最短時間內超時。 「確認處理」 如果在計時器超時之前收到了確認信息，則該片段從重傳隊列中移除。 「重傳超時」 如果在計時器超時之前沒有收到確認信息，則發生重傳超時，片段自動重傳。當然，相比於原片段，對於重傳片段並沒有更多的保障機制。因此，重傳之後該片段還是保留在重傳隊列裏。重傳計時器被重啓，重新開始倒計時。如果重傳之後沒有收到確認，則片段會再次重傳並重復這一過程。在某些情況下重傳也會失敗。我們不想要TCP永遠重傳下去，因此TCP只會重傳一定數量的次數，並判斷出現故障終止連接。
但是我們怎樣知道一個片段被完全確認呢？重傳是基於片段的，而TCP確認信息是基於序列號累積的。每次當設備A發送片段給設備B，設備B查看該片段的確認號字段。所有低於該字段的序列號都已經被設備A接收了。因此，當片段中所發送的所有字節的序列號都比設備A到設備B的最後一個確認號小的時候，一個從設備B發到設備A的片段被認爲是確認了。這是通過計算片段中最後一個序列號結合片段的數據字段來實現的。
讓我們以下圖爲例來說明一下確認和重傳是怎樣工作的。假設連接中的服務器發出了四個連續片段（號碼從1開始）
「片段1」 序列號字段是1片段長度80。所以片段1中最後一個序列號是80。
「片段2」 序列號是81片段長度是120。片段2中最後一個序列號是200。
「片段3」 序列號是201片段長度是160。片段3中最後一個序列號是360。
「片段4」 序列號是361片段長度是140。片段3中最後一個序列號是500。
這些片段是一個接一個發送的，而無需等待前一個發送得到確認。這是TCP滑動窗口的一個主要優勢（細說TCP滑動窗口）。
假設客戶端接收到前兩個傳輸，它會發回一條確認消息確認號爲201。從而告知服務器前兩個片段已經被客戶端成功接收了，它們從重傳隊列中移除（並且服務器發送窗口右移200字節）。在接收到確認號361或更高的片段之前，片段3會保留在重傳隊列中；片段4需要確認號501或更高。
現在，讓我們進一步假設傳輸過程中片段3丟失了，但片段4被接收到了。客戶端將片段4保存在接收buffer中，但是不需要確認，因爲TCP是累積確認機制——確認片段4表示片段3也接收到了，但實際上並沒有。因此，客戶端需要等待片段3。實際上，服務器端片段3的重傳計時器會超時，服務器之後重傳片段3。之後客戶端收到，然後發送片段3和4的確認信息給服務器。
還有一個重要的問題，服務器將如何處理片段4呢？雖然客戶端在等待片段3，服務器沒有收到反饋，所以它並不知道片段3丟失了，同樣它也不知道片段4發生了什麼（以及接下來傳輸的數據）。很有可能客戶端已經接收到了片段4但是不能確認，也有可能片段4也丟失了。一些實現中會選擇僅僅重傳片段3，也有些會把3和4都重傳。
最後一個問題是重傳隊列中所使用片段重傳計時器的值。如果設置過低，會發生過量重傳，如果設置過高，重傳丟失片段會減弱性能。必須通過一個稱爲自適應重傳的過程來動態調整這個值，接下來的章節會講到。
本文使用 mdnice 排版