滑動窗口協議

如果過多的源同時以很快的速度發送大量的數據包，而此時接收方並沒有如此高的接收數據的能力，因此極易導致網絡的擁塞。所以，為了控制發送方的發送速度，防止發送方並考慮到受發送緩衝區大小的制約等，要求對發送方已發出但尚未經確認的幀的數目加以限制，同時使網絡的傳輸效率得到提高，滑動窗口協議應運而生，它使得發送方可以在未收到確認的情況下，同時發送多個數據分組，由此大大提升了網絡吞吐量。

在任何基於自動重發請求進行錯誤控制的通信協議中，接收方必須確認收到的數據包。 如果發送方在合理的時間內沒有收到確認，則重發數據。沒有聽到確認的發送方不知道接收方是否實際接收到分組（數據可能在傳輸中丟失或損壞）。 如果錯誤檢測顯示損壞，則數據包將被接收方忽略，並且不會發送確認。 因為網絡傳輸的時延，將有大量時間被用於等待確認，導致傳輸效率低下。

傳輸的每個部分被分配唯一的連續序列號，接收方使用數字並以正確的順序放置接收到的數據包，丟棄重複的數據包並識別丟失的數據。

協議中規定，對於窗口內未經確認的分組需要重傳。這種分組的數量最多可以等於發送窗口的大小，即滑動窗口的大小n減去1（因為發送窗口不可能大於（n-1），起碼接收窗口要大於等於1）。

滑動窗口協議必須保證數據包的按序傳輸，發送窗口中的序列號代表已發送但尚未收到確認的數據包，發送窗口可持續地維持一系列未經確認的數據包，因為發送方窗口內的數據包可能在傳輸過程中丟失或損壞，所以發送過程必須把發送窗口中的所有數據包保存起來以備重傳。發送窗口一旦達到最大值，發送過程就必須停止接收新的數據包，直到有空閒緩存區。接收窗口外的數據包都要丟棄，當序列號等於接收窗口下限的數據包到達時，把它提交給應用程序並向發送端發送確認，接收窗口向前移動一位。發送窗口和接收窗口上下限無需相同，大小也無需相同，但接收窗口大小需保持固定，發送窗口大小可隨着數據包而改變。 ^[1] 

通過限制在任何給定時間可以發送或接收的數據包的數量，滑動窗口協議允許使用固定大小的序列號傳送無限數量的數據包。發送方側的術語“窗口”表示接收方尚未確認的分組總數的邏輯邊界。接收方在每個確認包中通知發送器當前的最大接收緩衝區大小（窗口邊界）。 TCP報頭使用16位字段向發送方報告接收窗口大小。因此，可以使用的最大窗口是2^16 = 64千字節。在慢啓動模式下，發送器以低分組計數器開始，並且在從接收方接收到確認分組之後增加每個傳輸中的分組數量。對於接收的每個ACK分組，該窗口通過一個分組（邏輯地）滑動以傳送一個新分組。當達到窗口閾值時，發送器發送一個包，用於接收到的一個ACK分組（確認分組）。如果窗口限制為10個數據包，則在慢啓動模式下，發送器可以開始發送一個數據包，後跟兩個數據包（發送兩個數據包之前必須接收一個數據包），其次是三個數據包等等，直到10個數據包。但是在達到10個分組之後，進一步的傳輸被限制為一個接收到的一個分組發送的分組。在仿真中，看起來好像窗口對於接收到的每個ACK分組移動一個分組距離。在接收方側，窗口也會為接收到的每個數據包移動一個數據包。滑動窗口方法可以確保網絡上的交通擁堵得以避免。應用層仍將提供傳輸到TCP的數據，而不用擔心網絡流量擁塞問題，因為發送方和接收方的TCP實現分組緩衝區的滑動窗口。窗口大小可能根據網絡流量而動態變化。

發送方和接收方分別具有當前序列號n_t和n_r。它們各自還有一個窗口大小w_t和w_r。窗口大小可能會根據網絡流量的變化而有所不同，但是在更簡單的實現中它們是固定的。窗口大小必須大於零才能進行任何操作。

通常情況下，n_t是要發送的下一個分組，即尚未發送的第一分組的序列號。同樣地，n_r尚未收到的第一個分組的序列號。這兩個序列號會隨着時間逐漸增加。

接收方還可以跟蹤未接收到的最高序列號，變量n_s比接收到的最高序列號還多一。對於僅接受數據包（w_r = 1）的簡單接收方，這與n_r相同，但如果w_r＞1，則可以更大。注意區別：已經收到n_r以下的所有數據包，沒有接收到n_s以上的任何數據包，在n_r和n_s之間，已經收到一些數據包。

當接收方接收到一個數據包時，它會適當地更新其變量，並用新的n_r發送確認。發送方跟蹤其收到的最高確認。由於確認信號的傳輸是有延遲的，因此發送方收到的確認序號為n_a，因此知道接收方已經接收到序號小於na的所有分組，但是對於n_a和n_s之間的分組是不確定的,即n_a≤n_r≤n_s（n_r的結果在此時可能還沒有傳回到發送方）

並且序列號總是符合n_a≤n_r≤n_s≤n_t≤n_a+w_t的規則,證明如下：

n_a≤n_r：發送器接收到的最高確認不能高於接收方確認的最高n_r。

n_r≤n_s：完全接收的數據包的範圍不能超出部分接收的數據包的結尾。

n_s≤n_t：接收到的最高報文不能高於發送的最高報文。

n_t≤n_a + w_t：發送的最高數據包同時受到接收到的最高確認和發送窗口大小的限制。

每當發送方具有要發送的數據時，它可以在最新的確認n_a之前傳輸序列號高達w_t數據包。也就是説，只要n_{ta + wt}，它可以傳送分組號n_t。

在沒有通信錯誤的情況下，發送方很快就會收到所有發送的數據包的確認信息，這等於n_t。如果在合理的延遲之後不會發生這種情況，則發送方必須在n_a和n_t之間重傳數據包。

每次接收到一個編號為x的數據包時，接收方檢查它是否落入接收窗口，n_r≤x≤n_r+w_r（最簡單的接收方只需要跟蹤一個值n_r =n_s）。如果它落在窗口內，接收方接受它。如果編號為n_r，則接收序列號增加1，並且如果先前接收和存儲更多的連續分組，則可能更多。如果x＞n_r，則存儲數據包直到接收到所有先前的數據包為止。如果x≥n_s，後者更新為n_s = x + 1。

如果數據包的序列號不在接收窗口內，則接收方將丟棄該數據包，並且不修改n_r或n_s。無論數據包是否被接受，接收方發送包含當前n_r的確認。 （確認還可以包括關於n_r或n_s之間接收的附加數據包的信息，但這隻能幫助效率。）

請注意，沒有必要讓接收窗口w_r大於發送窗口w_t，因為不需要擔心接收到永遠不會發送的數據包;有用範圍為1≤w_r≤w_t。

滑動窗口協議以基於分組的數據傳輸協議為特徵。因此該協議適用於對按順序傳送分組的可靠性要求較高的環境，例如在數據鏈路層（OSI模型）以及傳輸控制協議（TCP）中。 ^[2] 

增強應答的鏈路層重傳，在長線傳輸中，因軟故障造成的消息傳輸錯誤佔據了絕大部分，對於這些問題的解決可以是系統的可靠性大大提高。這種機制，向通過實現簡單、檢突發錯誤能力高的CRC碼的校驗進行錯誤檢查，再由相應的滑動窗口協議實現重傳恢復。 ^[3] 

這時接受方的窗口和發送方的窗口大小都是1，1個比特就夠表示了，所以也叫1比特滑動窗口協議。發送方這時自然發送每次只能發送一個，並且必須等待這個數據包的ACK，才能發送下一個。雖然在效率上比較低，帶寬利用率明顯較低，不過在網絡環境較差，或是帶寬本身很低的情況下，還是適用的。

存在的問題是，當發送方交替發送標記為“奇數”和“偶數”的數據包。 發送的確認同樣為“奇數”和“偶數”。 假設已經發送了奇數分組的發送方沒有收到奇數確認，而是立即發送下一個偶數分組，在此之後它可能會收到一個確認，為“下一個奇數包”。這將使發送方出現不確定因素：接收方有可能接收到這兩個數據包，或者兩者都沒接收到。

由於停止等待協議效率太低，因此有了回退n-步協議，這也是滑動窗口協議真正的用處，這裏發送的窗口大小為n，接受方的窗口仍然為1。具體看下面的圖，這裏假設n=10： 首先發送方一口氣發送9個數據幀，前面兩個幀正確返回了，數據幀2出現了錯誤，這時發送方被迫重新發送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。 後退n協議的好處無疑是提高了效率，但是一旦網絡情況糟糕，則會導致大量數據重發，反而不如上面的停等協議。

存在的問題在於，假設我們使用3位序列號，這是HDLC的典型值。 這使得N =

= 8。 由於w_r = 1，我們必須限制w_t≤7。 這是因為在發送7個數據包之後，有8個可能的結果：0到7個數據包都可能被成功地接收。 這有8種可能性，發送方在確認中需要足夠的信息來區分它們。如果發送方發送8個數據包而不等待確認，則可能會發現自己存在和停止等待協議一樣的問題：這意味着所有8個數據包都可能被成功接收，亦或是一個都沒有被成功接收。

後退n協議的另外一個問題是，當有錯誤幀出現後，總是要重發該幀之後的所有幀，毫無疑問在網絡不是很好的情況下會進一步惡化網絡狀況。

重傳協議便是用來解決這個問題。原理也很簡單，接收端總會緩存所有收到的幀，當某個幀出現錯誤時，只會要求重傳這一個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的緩存。

存在的問題在於：最為普遍的HDLC協議使用3位序列號，並具有選擇性重複的可選條件。但是，如果使用選擇性重複，則必須保持n_t +n_r≤8的要求;如果w_r增加到2，則w_t必須降低到6。假設w_r = 2，但是與w_t = 7一起使用未修改的發射機。進一步假設接收器以n_r = n_s = 0開始。

假設接收器看到以下一系列數據包（均為模8）：

0 1 2 3 4 5 6（暫停）0

由於w_r = 2，接收方將接受並存儲最終的數據包0（在系列中認為它是數據包8），同時請求重發數據包7。.然而，發送方也不可能接收到任何確認，並且在後一種情況下，接收機將接收錯誤的分組作為分組8。解決方案是發送方限制w_t≤6。通過這種限制，接收方在接收到分組6後知道發送方的n_a≥1，並且因此編號為0的後續分組必須是分組8。如果所有確認丟失，則發送方將不得不在分組5之後停止。

（1）發送方不必發送一個全窗口大小的數據。

（2）來自接收方的一個報文段確認數據並把窗口向右邊滑動，這是因為窗口的大小是相對於確認序號的。

（3）窗口的大小可以減小，但是窗口的右邊沿卻不能夠向左移動。

（4）接收方在發送一個ACK前不必等待窗口被填滿。

由於“滑動窗口”協議的性能取決於窗口大小和網絡接收數據包的速度，在流量不穩定的環境中，性能下降甚至可能會使網絡發生衝突。 為了避免和提供端到端流量控制，可以建議“慢啓動”協議。

對於該協議的改進主要集中在如何減少TCP報文重傳方面，在TCP中每傳輸一個報文都要求接收方進行確認，大量短而頻繁的確認報文給網絡帶來了很多開銷。因此採取了延遲ACK策略來減少ACK的數量，就是接收方收到一個報文以後，不會立即發送ACK，而是等待1~200ms，這期間若有回送數據報文就捎帶確認，但收到兩個連續數據報文或者等待超時則發送一個獨立確認。有效減少了ACK的數量，改善了TCP的整體性能。 ^[4]