滑動視窗概念不僅存在於數據鏈路層，也存在於傳輸層，兩者有不同的協定，但基本原理是相近的。其中一個重要區別是，一個是針對於幀的傳送，另一個是位元組數據的傳送。
基本介紹
- 中文名：滑動視窗
- 外文名：Sliding window
- 類型：流量控制技術
- 區別：針對於幀或位元組數據的傳送
基本信息,概念,視窗機制,滑動視窗協定,後退n協定,選擇重傳協定,背景,工作機制,流量控制,套用場景,
基本信息
概念
滑動視窗（Sliding window）是一種流量控制技術。早期的網路通信中，通信雙方不會考慮網路的擁擠情況直接傳送數據。由於大家不知道網路擁塞狀況，同時傳送數據，導致中間節點阻塞掉包，誰也發不了數據，所以就有了滑動視窗機制來解決此問題。參見滑動視窗如何根據網路擁塞傳送數據仿真視頻。圖片是一個滑動視窗的實例：
滑動視窗協定是用來改善吞吐量的一種技術，即容許傳送方在接收任何應答之前傳送附加的包。接收方告訴傳送方在某一時刻能送多少包（稱視窗尺寸）。
TCP中採用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收數據。傳送方可以通過滑動視窗的大小來確定應該傳送多少位元組的數據。當滑動視窗為0時，傳送方一般不能再傳送數據報，但有兩種情況除外，一種情況是可以傳送緊急數據，例如，允許用戶終止在遠端機上的運行進程。另一種情況是傳送方可以傳送一個1位元組的數據報來通知接收方重新聲明它希望接收的下一位元組及傳送方的滑動視窗大小。
視窗機制
滑動視窗協定的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協定視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被傳送，但是還沒有被確認的幀，或者是那些可以被傳送的幀。
下面舉例說明，假設傳送視窗尺寸為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比特滑動視窗、後退n及選擇重傳三種協定，它們的差別僅在於各自視窗尺寸的大小不同而已。1比特滑動視窗協定：傳送視窗=1，接收視窗=1；後退n協定：傳送視窗>1，接收視窗=1；選擇重傳協定：傳送視窗>1，接收視窗>1。
滑動視窗協定
後退n協定
由於停等協定要為每一個幀進行確認後才繼續傳送下一幀，大大降低了信道利用率，因此又提出了後退n協定。後退n協定中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個數據幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定逾時定時器。只要在所設定的逾時時間內仍未收到確認幀，就要重發相應的數據幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器逾時後仍未返回其確認信息，則該幀被判為出錯或丟失，此時傳送方就不得不重新傳送出錯幀及其後的N幀。
從這裡不難看出，後退n協定一方面因連續傳送數據幀而提高了效率，但另一方面，在重傳時又必須把原來已正確傳送過的數據幀進行重傳（僅因這些數據幀之前有一個數據幀出了錯），這種做法又使傳送效率降低。由此可見，若傳輸信道的傳輸質量很差因而誤碼率較大時，連續測協定不一定優於停止等待協定。此協定中的傳送視窗的大小為k，接收視窗仍是1。
選擇重傳協定
在後退n協定中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求傳送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱為選擇重發（SELECTICE REPEAT），其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。
背景
如果過多的源同時以很快的速度傳送大量的數據包，而此時接收方並沒有如此高的接收數據的能力，因此極易導致網路的擁塞。所以，為了控制傳送方的傳送速度，防止傳送方並考慮到受傳送緩衝區大小的制約等，要求對傳送方已發出但尚未經確認的幀的數目加以限制，同時使網路的傳輸效率得到提高，滑動視窗協定應運而生，它使得傳送方可以在未收到確認的情況下，同時傳送多個數據分組，由此大大提升了網路吞吐量。
在任何基於自動重發請求進行錯誤控制的通信協定中，接收方必須確認收到的數據包。 如果傳送方在合理的時間內沒有收到確認，則重發數據。沒有聽到確認的傳送方不知道接收方是否實際接收到分組（數據可能在傳輸中丟失或損壞）。 如果錯誤檢測顯示損壞，則數據包將被接收方忽略，並且不會傳送確認。 因為網路傳輸的時延，將有大量時間被用於等待確認，導致傳輸效率低下。
工作機制
工作原理
通過限制在任何給定時間可以傳送或接收的數據包的數量，滑動視窗協定允許使用固定大小的序列號傳送無限數量的數據包。傳送方側的術語“視窗”表示接收方尚未確認的分組總數的邏輯邊界。接收方在每個確認包中通知傳送器當前的最大接收緩衝區大小（視窗邊界）。 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。
流量控制
減小視窗尺寸TCP連線階段，雙方協商視窗尺寸，同時接收方預留數據快取區；
傳送方根據協商的結果，傳送符合視窗尺寸的數據位元組流，並等待對方的確認；
傳送方根據確認信息，改變視窗的尺寸，增加或者減少傳送未得到確認的位元組流中的位元組數。調整過程包括：如果出現傳送擁塞，傳送視窗縮小為原來的一半，同時將逾時重傳的時間間隔擴大一倍。
