[轉]網絡基本功10-細說TCP確認機制
❝本文由Zhang_Jiawen發表於Dell Technology"網絡基本功"
如有侵犯版權,還請這位頭像萌萌的大姐姐前輩聯繫我商討刪帖,道歉,賠償,下跪等事宜.
❞
在TCP確認機制中，無法有效處理非連續TCP片段。確認號表明所有低於該編號的sequence number已經被髮送該編號的設備接收。如果我們收到的字節數落在兩個非連續的範圍內，則無法只通過一個編號來確認。這可能導致潛在嚴重的性能問題，特別是高速或可靠性較差的網絡。
還是以下圖爲例，服務器發送了4個片段並收到1條回覆，確認號爲201。因此，片段1和片段2被當成已確認。它們從重傳隊列中移出，同時允許服務器發送窗口向右移動200字節，從而發送數據增加200個字節。
然而，再次假設片段3，從sequence number201開始，在發送過程中丟失了。由於客戶端從沒有收到這一片段，所以它也無法發送確認號高於201的確認信息，從而導致滑動窗口停滯。服務器可以繼續發送其他片段直到填滿客戶端的接收窗口，但是直到客戶端發送另一條確認信息，服務器的發送窗口都不會滑動。
另一個問題是如果片段3丟失了，客戶端將無法告知服務器是否收到後續的片段。在客戶端接收窗口填滿之前，很有可能客戶端已經接收到片段4以及之後的片段。但是客戶端無法發送值爲501的確認信息以表明接收到片段4，「因爲這意味着片段3也接收到了」。
這裏我們看到了TCP單編號，累積確認機制的缺點。我們可以想象一個最差的情況，服務器被告知它有一個10，000字節窗口，20個片段每個片段500字節。第一個片段丟失了，其他19個被接收到了。但是由於第一個片段從沒有接收到，其他19個也無法確認。
未確認片段處理策略
我們怎樣處理丟失片段之後的片段呢？
本例中，當服務器片段3重傳超時，它必須決定怎樣處理片段4，它不知道客戶端是否已經接收到。在上述最差情況下，第一個片段丟失後，其餘19個可能或可能無法被客戶端接收到。 處理這種情況有兩種可能的方式：
**僅重傳超時片段：**這是一種更加保守的方式，僅重傳超時的片段，希望其他片段都能夠成功接收。如果該片段之後的其他片段實際上接收到了，這一方式是最佳的，如果沒接收到，就無法正常執行。後者的情況每一個片段需要單獨計時並重傳。假設上述最壞情況下，所有20個500字節片段都丟失了。我們需要等片段1超時並重傳。這一片段也許會得到確認，但之後我們需要等待片段2超時並重傳。這一過程會重複多次。
**重傳所有片段：**這是一種更激進或者說更悲觀的方式。無論何時一個片段超時了，不僅重傳該片段，還有所有其他尚未確認的片段。這一方式確保了任何時間都有一個等待確認的停頓時間，在所有未確認片段丟失的情況下，會刷新全部未確認片段，以使對端設備多一次接收機會。在所有20個片段都丟失的情況下，相對於第一種方式節省了大量時間。這種方式的問題在於可能這些重傳是不必要的。如果第一個片段丟失而其他19個實際上接收到了，也得重傳那9500字節數據。
由於TCP不知道其他片段是否接收到，所以它也無法確認哪種方法更好，但只能選擇一種方式。上圖示例了保守的方式，而下圖顯示的是激進的方式：
問題的關鍵在於無法確認非連續片段。解決方式是對TCP滑動窗口算法進行擴展，添加允許設備分別確認非連續片段的功能。這一功能稱爲選擇確認（selective acknowledgment, SACK）。
選擇確認
通過SACK，連接的兩方設備必須同時支持這一功能，通過連接時使用的SYN片段來協商是否允許SACK。這一過程完成之後，任一設備都可以在常規TCP片段中使用SACK選項。這一選項包含一個關於已接收但未確認片段數據sequence number範圍的列表，由於它們是非連續的。 各設備對重傳隊列進行修改，如果該片段已被選擇確認過，則該片段中的SACK比特位置爲1。該設備使用圖2中激進方式的改進版本，一個片段重傳之後，之後所有片段也會重傳，除非SACK比特位爲1。
例如，在4個片段的情況下，如果客戶端接收到片段4而沒有接收到片段3，當它發回確認號爲201（片段1和片段2）的確認信息，其中包含一個SACK選項指明：“已接收到字節361至500，但尚未確認”。如果片段4在片段1和2之後到達，上述信息也可以通過第二個確認片段來完成。服務器確認片段4的字節範圍，併爲片段4打開SACK位。當片段3重傳時，服務器看到片段4的SACK位爲1，就不會對其重傳。如下圖所示。
在片段3重傳之後，片段4的SACK位被清除。這是爲了防止客戶端出於某種原因改變片段4已接收的想法。客戶端應當發送確認號爲501或更高的確認信息，正式確認片段3和4接收到。如果這一情況沒有發生，服務器必須接收到片段4的另一條選擇確認信息才能將它的SACK位打開，否則，在片段3重傳時或計時器超時的情況下會對其自動重傳。
