滑動窗口協議

本文轉載自查看原文 2019-06-06 14:50 2573

滑動窗口協議（Sliding Window Protocol），屬於 TCP協議的一種應用，用於網絡數據傳輸時的流量控制，以避免擁塞的發生。該協議允許發送方在停止並等待確認前發送多個數據分組。由於發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸，提高網絡吞吐量。

中文名: 滑動窗口協議
外文名: Sliding Window Protocol

類型: 可靠數據傳輸協議
層次結構: 4層

背景

編輯

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

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

定義

編輯

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

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

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

滑動窗口協議的時間線

工作機制

編輯

工作原理

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

操作

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

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

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

當接收方接收到一個數據包時，它會適當地更新其變量，並用新的nr發送確認。發送方跟蹤其收到的最高確認。發送方知道已經接收到但不包括na的所有分組，但是對於na和ns之間的分組是不確定的,即na≤nr≤ns。

並且序列號總是符合na≤nr≤nx≤nt≤na+wt的規則,證明如下：

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

nr≤ns：完全接收的數據包的范圍不能超出部分接收的數據包的結尾。

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

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

發送方操作

每當發送方具有要發送的數據時，它可以在最新的確認na之前傳輸序列號高達wt數據包。也就是說，只要nt<na + wt，它可以傳送分組號nt。

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

接收方操作

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

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

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

應用場景

編輯

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

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

應用實例

編輯

[1] 停止等待協議（stop-and-wait）

停止等待協議示意圖

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

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

[2]回退n步協議（GO-BACK-N）

回退N-步協議示意圖

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

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

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

[3]選擇重傳協議（selective repeat）

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

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

存在的問題在於：最為普遍的HDLC協議使用3位序列號，並具有選擇性重復的可選條件。但是，如果使用選擇性重復，則必須保持nt +nr≤8的要求;如果wr增加到2，則wt必須降低到6。假設wr = 2，但是與wt = 7一起使用未修改的發射機。進一步假設接收器以nr = ns = 0開始。
　　現在假設接收器看到以下一系列數據包（均為模8）：
　　0 1 2 3 4 5 6（暫停）0
　　由於wr = 2，接收方將接受並存儲最終的數據包0（在系列中認為它是數據包8），同時請求重發數據包7。.然而，發送方也不可能接收到任何確認，並且在后一種情況下，接收機將接收錯誤的分組作為分組8。解決方案是發送方限制wt≤6。通過這種限制，接收方在接收到分組6后知道發送方的na≥1，並且因此編號為0的后續分組必須是分組8。如果所有確認丟失，則發送方將不得不在分組5之后停止。

注意事項

編輯

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

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

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

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

協議改進

編輯

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

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

TCP滑動窗口機制

TCP滑動窗口機制

我們可以大概看一下上圖的模型：

首先是AB之間三次握手建立TCP連接。在報文的交互過程中，A將自己的緩沖區大小（窗口大小）3發送給B，B同理，這樣雙方就知道了對端的窗口大小。

A開始發送數據，A連續發送3個單位的數據，因為他知道B的緩沖區大小。在這一波數據發送完后，A就不能再發了，需等待B的確認。

A發送過來的數據逐漸將緩沖區填滿。

這時候緩沖區中的一個報文被進程讀取，緩沖區有了一個空位，於是B向A發送一個ACK，這個報文中指示窗口大小為1。

A收到B發過來的ACK消息，並且知道B將窗口大小調整為1，因此他只發送了一個單位的數據並且等待B的下一個確認報文。

如此反復。

什么是滑動窗口協議？
一圖勝千言，看下面的圖。簡單解釋下，發送和接受方都會維護一個數據幀的序列，這個序列被稱作窗口。發送方的窗口大小由接受方確定，目的在於控制發送速度，以免接受方的緩存不夠大，而導致溢出，同時控制流量也可以避免網絡擁塞。下面圖中的4,5,6號數據幀已經被發送出去，但是未收到關聯的 ACK，7,8,9幀則是等待發送。可以看出發送端的窗口大小為6，這是由接受端告知的（事實上必須考慮擁塞窗口cwnd，這里暫且考慮 cwnd>rwnd）。此時如果發送端收到4號ACK，則窗口的左邊緣向右收縮，窗口的右邊緣則向右擴展，此時窗口就向前“滑動了”，即數據幀10 也可以被發送。

下面就滑動窗口協議做出更詳細的說明，這里為了簡單起見設定發送方窗口大小為2，接受方大小為1。看下面圖：

一：初始態，發送方沒有幀發出，發送窗口前后沿相重合。接收方0號窗口打開，等待接收0號幀；
二：發送方打開0號窗口，表示已發出0幀但尚確認返回信息。此時接收窗口狀態不變；
三：發送方打開0、1號窗口，表示0、1號幀均在等待確認之列。至此，發送方打開的窗口數已達規定限度，在未收到新的確認返回幀之前，發送方將暫停發送新的數據幀。接收窗口此時狀態仍未變；
四：接收方已收到0號幀，0號窗口關閉，1號窗口打開，表示准備接收1號幀。此時發送窗口狀態不變；
五：發送方收到接收方發來的0號幀確認返回信息，關閉0號窗口，表示從重發表中刪除0號幀。此時接收窗口狀態仍不變
六：發送方繼續發送2號幀，2號窗口打開，表示2號幀也納入待確認之列。至此，發送方打開的窗口又已達規定限度，在未收到新的確認返回幀之前，發送方將暫停發送新的數據幀，此時接收窗口狀態仍不變；
七：接收方已收到1號幀，1號窗口關閉，2號窗口打開，表示准備接收2號幀。此時發送窗口狀態不變；
八：發送方收到接收方發來的1號幀收畢的確認信息，關閉1號窗口，表示從重發表中刪除1號幀。此時接收窗口狀態仍不變。

1比特滑動窗口協議?
上面說的只是滑動窗口協議的理論，實際應用中又有不同。首先就是停等協議(stop－and－wait)，這時接受方的窗口和發送方的窗口大小都是1，1 個比特就夠表示了，所以也叫1比特滑動窗口協議。發送方這時自然發送每次只能發送一個，並且必須等待這個數據包的ACK，才能發送下一個。雖然在效率上比較低，帶寬利用率明顯較低，不過在網絡環境較差，或是帶寬本身很低的情況下，還是適用的。看下面的流程圖：

后退n協議?
    停等協議雖然實現簡單，也能較好的適用惡劣的網絡環境，但是顯然效率太低。所以有了后退n協議，這也是滑動窗口協議真正的用處，這里發送的窗口大小為n，接受方的窗口仍然為1。具體看下面的圖，這里假設n=9：
    首先發送方一口氣發送10個數據幀，前面兩個幀正確返回了，數據幀2出現了錯誤，這時發送方被迫重新發送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。
    后退n協議的好處無疑是提高了效率，但是一旦網絡情況糟糕，則會導致大量數據重發，反而不如上面的停等協議，實際上這是很常見的，具體可以參考TCP擁塞控制。

選擇重傳協議？
后退n協議的另外一個問題是，當有錯誤幀出現后，總是要重發該幀之后的所有幀，毫無疑問在網絡不是很好的情況下會進一步惡化網絡狀況，重傳協議便是用來解決這個問題。原理也很簡單，接收端總會緩存所有收到的幀，當某個幀出現錯誤時，只會要求重傳這一個幀，只有當某個序號后的所有幀都正確收到后，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的緩存。

TCP滑動窗口易錯處

前段時間研究分布式時寫了一個可擴展的服務器組程序，服務器組之間通信時老是達不到想要的性能。后來抓包排查，原來是TCP滑動窗口引起的問題，本來是很基礎的東西，奈何當初沒有太在意，導致錯誤的產生，現在詳細寫出來，忘不太清楚者警惕！

滑動窗口的基本情況我有必要廢話一下。TCP通信為了保證可靠性，每次發送的數據都需要得到對方的ACK才確認對方收到了(僅保證對方TCP接收緩沖收到數據了，但不保證對方應用程序取到數據了)，這時如果每次發送一次就要停下來等着對方的ACK消息，顯然是一種極大的資源浪費和低下的效率，這時就有了滑動窗口的出現。

發送方的滑動窗口維持着當前發送的幀序號，已發出去幀的計時器，接收方當前的窗口大小(由接收方ACK通知，大體等於接收緩沖大小-未處理的消息包)，接收方滑動窗口保存的有已接收的幀信息、期待的下一幀的幀號等，至於滑動窗口的具體工作原理這里就不說了。

一個socket有兩個滑動窗口(一個sendbuf、一個recvbuf)，兩個窗口的大小是通過setsockopt函數設置的，現在問題就出在這里，通過抓包顯示，設置的窗口大小沒有生效，最后排查發現setsockopt函數是后來加上的，寫到了listen函數的后面，這樣每次accept出的socket並沒有繼承得到主socket設置的窗口大小，無語啊……

解決辦法：setsockopt函數提前到listen函數之前，這樣在服務器程序啟動監聽前recvbuf就已經有了，accept后的鏈接得到的就是recvbuf了，啟動程序運行，抓包顯示窗口已經是指定的大小了。

網絡編程其實很簡單，任何人都可以寫出一套自己的服務器框架，但是細節決定成敗，性能的高低有時候就是幾個小細節決定的（當然這里說的這個問題是個編程錯誤，不屬於可優化的細節問題）

前言

你現在的努力，是為了以后有更多的選擇。

在上一篇文章通過“表白”方式，讓我們快速了解網絡七層協議了解了網絡七層協議。
接下來我們要把重心放在網絡傳輸的可靠性上面。一起來看TCP協議，它是如何解決網絡傳輸不可靠的問題。這其中有個很關鍵的部分，就是我們的滑動窗口協議。

從工程學角度上，我們來看一看滑動窗口協議，它到底解決了一個怎樣的問題？

滑動窗口協議：

TCP協議的使用
維持發送方/接收方緩沖區
緩沖區是用來解決網絡之間數據不可靠的問題，例如丟包，重復包，出錯，亂序

在TCP協議中，發送方和接受方通過各自維護自己的緩沖區。通過商定包的重傳機制等一系列操作，來解決不可靠的問題。

問題一：如何保證次序？

提出問題：在我們滑動窗口協議之前，我們如何來保證發送方與接收方之間，每個包都能被收到。並且是按次序的呢？

問題1 發送方發送一個包1，這時候接收方確認包1。發送包2，確認包2。就這樣一直下去，知道把數據完全發送完畢，這樣就結束了。那么就解決了丟包，出錯，亂序等一些情況！同時也存在一些問題。問題：吞吐量非常的低。我們發完包1，一定要等確認包1.我們才能發送第二個包。

問題二：如何提高吞吐量？

提出問題：那么我們就不能先連發幾個包等他一起確認嗎？這樣的話，我們的速度會不會更快，吞吐量更高些呢？

改進方案如圖，這個就是我們把兩個包一起發送，然后一起確認。可以看出我們改進的方案比之前的好很多，所花的時間只是一個來回的時間。接下來，我們還有一個問題：改善了吞吐量的問題

問題三：如何實現最優解？

問題：我們每次需要發多少個包過去呢？發送多少包是最優解呢？

我們能不能把第一個和第二個包發過去后，收到第一個確認包就把第三個包發過去呢？而不是去等到第二個包的確認包才去發第三個包。這樣就很自然的產生了我們"滑動窗口"的實現。
在圖中，我們可看出灰色1號2號3號包已經發送完畢，並且已經收到Ack。這些包就已經是過去式。4、5、6、7號包是黃色的，表示已經發送了。但是並沒有收到對方的Ack，所以也不知道接收方有沒有收到。8、9、10號包是綠色的。是我們還沒有發送的。這些綠色也就是我們接下來馬上要發送的包。可以看出我們的窗口正好是11格。后面的11-16還沒有被讀進內存。要等4號-10號包有接下來的動作后，我們的包才會繼續往下發送。

正常情況

正常情況可以看到4號包對方已經被接收到，所以被塗成了灰色。“窗口”就往右移一格，這里只要保證“窗口”是7格的。我們就把11號包讀進了我們的緩存。進入了“待發送”的狀態。8、9號包已經變成了黃色，表示已經發送出去了。接下來的操作就是一樣的了，確認包后，窗口往后移繼續將未發送的包讀進緩存，把“待發送“狀態的包變為”已發送“。