ARQ與滑動視窗概念

       滑動視窗協議，是TCP使用的一種流量控制方法。該協議允許傳送方在停止並等待確認前可以連續傳送多個分組。由於傳送方不必每發一個分組就停下來等待確認，因此該協議可以加速資料的傳輸。

   自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中資料鏈路層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的資訊傳輸。如果傳送方在傳送後一段時間之內沒有收到確認幀，它通常會重新發送。ARQ可能包括停止等待ARQ協議、回退ARQ和連續ARQ協議，錯誤檢測（Error Detection）、正面確認（Positive Acknowledgment）、超時重傳（Retransmission after Timeout）和 負面確認及重傳（Negative Acknowledgment and Retransmission）等機制。

他們的概念是差不多的只是作用於不同的網路層。資料鏈路層的滑動視窗是“個數固定”的。而TCP的滑動視窗是“個數可變”的，可以由接收端設定WIN欄位來修改。

         傳統自動重傳請求分成為三種，即停等式(stop-and-wait）ARQ，回退n幀（go-back-n）ARQ，以及選擇性重傳（selective repeat）ARQ。後兩種協議是滑動視窗技術與請求重發技術的結合，由於視窗尺寸開到足夠大時，幀線上路上可以連續地流動，因此又稱其為連續ARQ協議。三者的區別在於對於出錯的資料報文的處理機制不同。三種ARQ協議中，複雜性遞增，效率也遞增。除了傳統的ARQ，還有混合ARQ（Hybrid-ARQ）。

　　當傳送視窗和接收視窗的大小都等於 1時，就是停止等待協議。

停止並等待ARQ協議(stop-and-wait)

     停止並等待協議的工作原理如下：

1. 傳送點對接收點發送資料包，然後等待接收點回復ACK並且開始計時。
2. 在等待過程中，傳送點停止傳送新的資料包。
3. 當資料包沒有成功被接收點接收時候，接收點不會發送ACK. 這樣傳送點在等待一定時間後，重新發送資料包。
4. 反覆以上步驟直到收到從接收點發送的ACK.

    傳送點的等待時間應當至少大於傳輸點資料包傳送時間（資料包容量除以傳送點傳輸速度），接收點ACK接收時間（ACK容量除以接收點傳輸速度），資料在連線上的傳送時間，接收點檢驗接收資料是否正確的時間之和。在實際應用當中，等待時間是這個和的2到3倍。

    這個協議的缺點是較長的等待時間導致低的資料傳輸速度。在低速傳輸時，對連線頻道的利用率比較好，但是在高速傳輸時，頻道的利用率會顯著下降。

回退n幀的ARQ

回退的基本原理圖：

如果當前傳送的是資料鏈路層上的最後一個幀（無論是資料幀還是確認幀），但不幸的是該幀出錯或丟失了，此種情況也適用於中間某一幀開始的所有後繼幀全部出錯或丟失的情況（同樣可以是資料幀或確認幀），那麼傳送端會一直等待下去，而且接收端對此也毫無察覺。

為了解決這個問題，需要採用超時機制。可以有多種定時方案，在早期方案中採用的一種是獨立的定時器，傳送端每傳送一個數據幀就啟動一次，當收到確認幀後，定時器復位；如果直到超時還沒有收到確認幀，則重發該幀以及後繼的幀。

其原理如圖下所示：

連續ARQ協議(Continuous ARQ)

     為了克服停止並等待ARQ協議長時間等待ACK的缺點。這個協議會連續傳送一組資料包，然後再等待這些資料包的ACK.

連續 ARQ 協議的工作原理圖：

    如圖所示，結點 A 向結點 B 傳送資料幀。當結點 A 發完 0 號幀後，不是停止等待，而是繼續傳送後續的 1 號幀、2 號幀等。由於連續傳送了許多幀，所以應答幀不僅要說明是對哪一幀進行確認或否認，而且應答幀本身也必須編號。
    結點 B 正確地收到了 0 號幀和 1 號幀，並送交其主機。現在設 2 號幀出了差錯，於是結點 B 就將有差錯的 2 號幀丟棄。結點 B 執行的協議可以有兩種選擇：一種是在出現差錯時就向結點 A 傳送否認幀，另一種則是在出現差錯時不做任何響應。我們現在假定採用後一種協議，這種協議比較簡單，使用得較多。

  選擇重傳 (Selective Repeat)

• 傳送點連續傳送資料包但對每個資料包都設有個一個計時器。
• 當在一定時間內沒有收到某個資料包的ACK時，傳送點只重新發送那個沒有ACK的資料包

  這個方法的缺點是接收點收到的資料包的順序可能不是傳送的資料包順序。因此在資料包裡必須含有順序字元來幫助接受點來排序。

• 接收點丟棄從第一個沒有收到的資料包開始的所有資料包。
• 傳送點收到NACK後，從NACK中指明的資料包開始重新發送

  這個辦法的問題是如何正確選擇表明資料包的順序字元的數量。這個數量因當包括ACK或者ACK從接收點到達傳送點的時間。

滑動視窗

        TCP滑動視窗用來暫存兩臺計算機間要傳送的資料分組。每臺執行TCP協議的計算機有兩個滑動視窗：一個用於資料傳送，另一個用於資料接收。傳送端待發資料分組在緩衝區排隊等待送出。被滑動視窗框入的分組，是可以在未收到接收確認的情況下最多送出的部分。滑動視窗左端標誌X的分組，是已經被接收端確認收到的分組。隨著新的確認到來，視窗不斷向右滑動。
       TCP協議軟體依靠滑動視窗機制解決傳輸效率和流量控制問題。它可以在收到確認資訊之前傳送多個數據分組。這種機制使得網路通訊處於忙碌狀態，提高了整個網路的吞吐率，它還解決了端到端的通訊流量控制問題，允許接收端在擁有容納足夠資料的緩衝之前對傳輸進行限制。在實際執行中，TCP滑動視窗的大小是可以隨時調整的。收發端TCP協議軟體在進行分組確認通訊時，還交換滑動視窗控制資訊，使得雙方滑動視窗大小可以根據需要動態變化，達到在提高資料傳輸效率的同時，防止擁塞的發生。
      稱視窗左邊沿向右邊沿靠近為視窗合攏，這種現象發生在資料被髮送和確認時。當視窗右邊沿向右移動時將允許傳送更多的資料，稱之為視窗張開。這種現象發生在另一端的接收程序讀取已經確認的資料並釋放了TCP的接收快取時。
      當右邊沿向左移動時，稱為視窗收縮。Host Requirements RFC強烈建議不要使用這種方式。但TCP必須能夠在某一端產生這種情況時進行處理。 如果左邊沿到達右邊沿，則稱其為一個零視窗。

   滑動視窗原理圖：

      在這個圖中，我們將位元組從1至11進行標號。接收方通告的視窗稱為提出的視窗，它覆蓋了從第4位元組到第9位元組的區域，表明接收方已經確認了包括第3位元組在內的資料，且通告視窗大小為6。我們知道視窗大小是與確認序號相對應的。傳送方計算它的可用視窗，該視窗表明多少資料可以立即被髮送。當接收方確認資料後，這個滑動視窗不時地向右移動。視窗兩個邊沿的相對運動增加或減少了視窗的大小。我們使用三個術語來描述視窗左右邊沿的運動：

• 稱視窗左邊沿向右邊沿靠近為視窗合攏。這種現象發生在資料被髮送和確認時。 
  
• 當視窗右邊沿向右移動時將允許傳送更多的資料，我們稱之為視窗張開。這種現象發生在另一端的接收程序讀取已經確認的資料並釋放了T C P的接收快取時。 
  
• 當右邊緣向左移動時，稱之為視窗收縮。

      2、視窗有3種動作：展開（右邊向右），合攏（左邊向右），收縮（右邊向左）這三種動作受接收端的控制。
                 合攏：表示已經收到相應位元組的確認了
                 展開：表示允許快取傳送更多的位元組
                 收縮（非常不希望出現的，某些實現是禁止的）：表示本來可以傳送的，現在不能傳送；但是如果收縮的是那些已經發出的，就會有問題；為了避免，收端會等待到快取中有更多快取空間時才進行通訊。
      發端視窗的大小取決於收端的視窗大小rwnd（TCP報文的視窗大小欄位）和擁塞視窗大小cwnd（見擁塞控制）
發端視窗大小 = min{ rwnd , cwnd };
3、關閉視窗：視窗縮回有個例外，就是傳送rwnd=0表示暫時不願意接收資料。這種情況下，發端不是把視窗收縮，二是停止傳送資料。（為了比避免死鎖，會用一些探測報定時傳送試探，見定時器一節）

      4、問題：某些時候，由於發端或收端的資料很慢，會引起大量的1位元組資料痛惜，浪費很多資源。
        （1）、發端的程序產生資料很慢時候，時不時的來個1位元組資料，那麼TCP就會1位元組1位元組的傳送，效率很低。
      解決方法（Nagle演算法）：
        a、將第一塊資料發出去
        b、然後等到傳送快取有足夠多的資料（最大報文段長度），或者等到收端確認的ACK時再發送資料。
        c、重複b的過程
       （2）、收端程序由於消耗資料很慢，所以可能會有這麼一種情況，收端會發送其視窗大小為1的資訊，然後有是1位元組的傳輸
      解決辦法（2種）
        a、Clark方法：在接收快取的一半變空，或者有足夠空間放最大報文長度之前，宣告接收視窗大小為0

        b、推遲確認：在對收到的報文段確認之前等待到足夠的接收快取，或者等待到一個時間段

轉自：http://blog.csdn.net/jmq_0000/article/details/7299910