上篇筆記中，我們主要討論了可靠資料傳輸協議的作用，以及如何從零開始一步一步構建乙個可靠的資料傳輸協議，在最後，我們構建出了 rdt 3.0 協議，它可以很好的在現實世界的底層通道上面工作。但問題是它是乙個停等協議，傳送端必須確認接收端已經接收到了正確的分組資料後才能傳送下乙個分組資料，這在現實生活中是不可忍受的。下面首先來分析一下 rdt 3.0 的效能，然後看如何改進 rdt 3.0，達到可靠與效率雙豐收。
文章目錄 [隱藏]
5 可靠資料傳輸過程中的分組重新排序問題
假設有兩台主機，分別位於美國西海岸和東海岸，它們之間的往返傳播實驗 rtt 大約為 30ms，假定它們通過一條速率 r 為 1gbps 的通道相連。包括首部欄位和資料的分組長 l 為 1000 bytes(8000 bits)，所以傳送乙個分組進入 1gbps 鏈路實際所需時間是：
t_trans = l / r = (8000 bit/pkt) / (10^9 bit/s) = 8 μs/pkt
所以，如果傳送端在 t = 0 時刻開始傳送分組，則在 8μs 後，該分組全部進入了傳送端通道。接著該分組經過 15ms 的旅途到達接收端，即該分組的最後 1 bit 在時刻 t = rtt/2 + l/r = 15.008ms 時到達接收端。假設 ack 分組很小，可以忽略其傳送時間，且接收端一旦收到乙個資料分組的最後 1bit 後立刻傳送 ack，則 ack 在時刻 t = rtt + l/r = 30.008ms 時回送到傳送端。也就是說，經過 30.008ms 後傳送端才可以傳送下乙個分組。
設利用率為：傳送端實際忙於將傳送位元送進通道的那部分時間與傳送時間之比。則
u_sender = (l/r) / (rtt + l/r) = 0.008 / 30.008 = 0.00027
可以看到，利用率極其低下，這是不可容忍的，所以我們需要改進效能。
流水線技術是解決這種特殊效能問題的乙個非常簡單的方法：不使用停等方式執行，允許傳送端傳送多個分組而無需等待確認。
雖然流水線可以直線提公升 rdt 3.0 協議的效能，但是也會帶來如下的影響：
解決流水線的差錯恢復有兩種基本方法，分別為回退 n 步（go-back-n, gbn）和選擇重傳（selective repeat, sr）。
在 gbn 協議中，允許傳送方傳送多個分組（當有多個分組可用時）而不需等待確認，但它也受限於在流水線中未確認的分組數不能超過某個最大允許數 n。
上圖顯示了傳送方看到的 gbn 協議的序號範圍。如果我們將基序號（base）定義為最早的未確認分組的序號，將下乙個序號（nextseqnum）定義為最小的未使用序號（即下乙個待發分組的序號），則可將序號範圍分割成 4 段。在 [0, base-1] 段內的序號對應於已經傳送並確認的分組。[base, nextseqnum-1] 段對應已經傳送但未被確認的分組。[nextseqnum, base+n-1] 段內的序號能用於那些要立即傳送的分組，如果有資料來自於上層的話。最後，大於或等於 base+n 的序號是不能使用的，直到當前流水線中未確認的分組（特別是序號為 base 的分組）已得到確認為止。
在上圖中，我們可以把 [base, base+n-1] 看做乙個長度為 n 的視窗。隨著協議的執行，該視窗在序號空間向前滑動。因此，n 常被稱為視窗長度（window size），gbn 協議也常被稱為滑動視窗協議（sliding-window protocol）。至於為什麼需要限制 n 的範圍，是因為這是流量控制的方法之一。
在實踐中，乙個分組的序號承載在分組首部的乙個固定長度的字段中。如果分組序號欄位的位元數是 k，則該序號範圍是 [0, 2^k - 1]。在乙個有限的序號範圍內，所有涉及序號的運算必須使用模 2^k 運算。
下圖是gbn 協議傳送方擴充套件 fsm 描述：
如上描述，gbn 協議傳送方必須響應三種型別的事件：
下圖是 gbn 協議接收方擴充套件 fsm 描述：
如果乙個序號為 n 的分組被正確接收到，並且按序（即上次交付給上層的資料是序號為 n - 1 的分組），則接收方為分組 n 傳送乙個 ack，並將該分組中的資料部分交付到上層。
在所有其他情況下，接收方將丟棄該分組，並為最近按序接收的分組重新傳送 ack。
注意到因為一次交付給上層乙個分組，如果分組 k 為已接受並交付，則所有序號比 k 小的分組也已經交付。因此，使用累積確認是 gbn 的乙個自然的選擇。
雖然 gbn 協議看起來很浪費，因為它會丟棄乙個正確接收（但失序）的分組。但這樣做是有道理的。因為接收方必須將資料按序交付給上層，假設現在期望接收分組 n，而分組 n + 1 卻到了，因為資料必須按序交付，所以接收方可能快取分組 n + 1，然後，在它收到並交付分組 n 後，再將該分組交付到上層。但是，如果分組 n 丟失，則該分組及分組 n + 1 最終將在傳送方根據 gbn 重傳規則而被重傳，所以，接收方只需要直接丟棄分組 n + 1 即可。
可以看到，gbn 協議本身相對於 rdt 3.0 協議有了長足進步，但是仍然有它自己的效能問題，尤其是當視窗長度和頻寬時延都很大的時，流水線中有很多分組更是如此。任何單個分組的差錯就能引起 gbn 協議重傳大量分組，事實上是很多分組根本沒必要重傳，所以，有了乙個更加優化的協議，就是下面要說的選擇重傳（sr）協議。
sr 協議在 gbn 協議的基礎上進行了改進，它通過讓傳送方僅重傳哪些它懷疑在接收方出錯（即丟失或受損）的分組而避免了不必要的重傳。
下圖描述了傳送方與接收方的序號空間：
下面描述一下 sr 協議傳送方的事件與動作：
然後是 sr 協議接收方的事件與動作：
注意上面的第二步，接收方需要重新確認（而不是忽略）已收到過的那些序號小於當前視窗基序號的分組。為什麼要返回 ack？加入按照上圖中所示的傳送方和接收方的序號空間，如果分組 send_base 的 ack 沒有從接收方傳播回傳送方，則傳送方最終將重傳分組 send_base，即使顯然接收方已經收了該分組。如果接收方不確認該分組，則傳送方視窗將永遠不能向前滑動。
上面的例子說明了對於 sr 協議（和很多其他協議一樣） 對於哪些分組已經被正確接收，哪些沒有，傳送方和接收方並不總能看到相同的結果。也就是說，傳送方和接收方的視窗並不總是一致。
下面這個例子說明了，如果視窗長度與序號空間大小選擇不當，將會產生嚴重的後果。
在這個例子中，有四個分組序號 0、1、2、3 且視窗長度為 3。假定傳送了分組 0 至 2，並且接收方被正確接收且確認了。此時，接收方視窗落在 4、5、6 個分組上，其序號分別為 3、0、1.現在考慮兩種情況。
在第一種情況下，如上圖中的 a 圖所示，對前 3 個分組的 ack 丟失，因此傳送方重傳這些分組。因此，接收方下一步要接收序號為 0 的分組，即第乙個傳送分組的副本。
在第二種情況下，如上圖中的 b 圖所示，對前 3 個分組的 ack 都被正確交付。因此傳送方向前移動視窗並傳送第 4、5、6 個分組，其序號分別為 3、0、1.序號為 3 的分組丟失，但序號為 0 的分組到達（乙個包含新資料的分組）。
顯然，接收方並不知道傳送方那邊出現了什麼問題，對於接收方自己來說，上面兩種情況是等價的。沒有辦法區分是第乙個分組的重傳還是第 5 個分組的初次傳輸。所以，視窗長度比序號空間小 1 時協議無法正常工作。但視窗應該有多小呢？
答案是：視窗長度必須小於或等於序號空間大小的一半。
在前面的所有假設中，我們都是假定分組在傳送方與接收方之間的通道中不能被重新排序。但是當連線兩端的通道是乙個網路時，分組重新排序是可能會發生的。
分組重新排序的乙個表現就是乙個具有序號或確認號 x 的分組的舊副本可能會出現，即使傳送方或接收方的視窗中都包含 x。
對於分組重新排序，通道可被看成基本上是在快取分組，並在將來任意時刻自然地釋放出這些分組。由於序號可以被重新使用，那麼必須小心，以免出現這樣的冗餘分組。
實際應用中採用的方法是：**確保乙個序號不被重新使用，直到傳送方「確信」任何先前傳送的序號為 x 的分組都不再在網路中為止。通過假定乙個分組在網路中的「存活」時間不會超過某個固定最大時間量來做到這一點。在高速網路的 tcp 擴充套件中，最長的分組壽命被假定為大於 3 分鐘 [rfc 1323]。
可靠資料傳輸原理
概述 可靠資料傳輸原理 tcp的可靠資料傳輸 tcp可靠資料傳輸的滑動視窗既不是純粹的gbn，也不是純粹的sr，在這兩個協議之外又引入了新的東西。資料傳輸發生錯誤怎麼辦？傳送方的有限狀態機 圓圈代表當前所處的狀態，帶箭頭的線代表狀態的轉換，橫線上方指示引起狀態變遷的事件，橫線下方指示狀態轉換中採取的...
可靠資料傳輸的原理 位元差錯
讀完 計算機網路自頂向下設計方法 第三章可靠資料傳輸的原理，有些明白為什麼tcp報文要這樣設計。第一種情況 僅考慮通訊通道上不會丟包，只會有位元差錯產生。通過校驗和機制 checksum 和重傳機制，在雙方保證資料報可靠性。傳送方 接收方狀態機如下所示。資料報傳送後，傳送方等待接收方的nak 否定 ...
TCP中的可靠資料傳輸
前面我們講到了可靠資料傳輸的實現，而tcp就是一種可靠資料傳輸，因此我們有必要了解一下tcp中的可靠資料傳輸跟前面的回退n步和選擇重傳有什麼區別 首先，我們明確乙個概念，累積確認 累計確認跟前面的ack不太一樣，在tcp報文段中有乙個確認號字段，該欄位表示接收方希望接收到的下乙個報文段的序號，而tc...