TCP-IP詳解：滑動視窗（Sliding Window）

參考書籍：TCP-IP Guide

TCP的優勢

從傳輸資料來講，TCP/UDP以及其他協議都可以完成資料的傳輸，從一端傳輸到另外一端，TCP比較出眾的一點就是提供一個可靠的，流控的資料轉送，所以實現起來要比其他協議複雜的多，先來看下這兩個修飾詞的意義：

 1. Reliability ，提供TCP的可靠性，TCP的傳輸要保證資料能夠準確到達目的地，如果不能，需要能檢測出來並且重新發送資料。

 2. Data Flow Control，提供TCP的流控特性，管理髮送資料的速率，不要超過裝置的承載能力

為了能夠實現以上2點，TCP實現了很多細節的功能來保證資料轉送，比如說 滑動視窗適應系統，逾時重傳機制，累計ACK等，這次先介紹一下滑動視窗的一些知識點。

滑動視窗引入

在閱讀一些文章的時候看到一個大牛做的視頻，非常不錯易於理解滑動視窗的機制，可以先看下：http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html

IP層協議屬於不可靠的協議，IP層並不關係資料是否發送到了對端，TCP通過確認機制來保證資料轉送的可靠性，在比較早的時候使用的是send--wait--send的模式，其實這種模式叫做stop-wait模式，發送資料方在發送資料之後會啟動定時器，但是如果資料或者ACK丟失，那麼定時器到期之後，收不到ACK就認為發送出現狀況，要進行重傳。這樣就會降低了通訊的效率，如下圖所示，這種方式被稱為 positive acknowledgment with retransmission (PAR)

滑動視窗

可以假設一下，來最佳化一下PAR效率低的缺點，比如我讓發送的每一個包都有一個id，接收端必須對每一個包進行確認，這樣裝置A一次多發送幾個片段，而不必等候ACK，同時接收端也要告知它能夠收多少，這樣發送端發起來也有個限制，當然還需要保證順序性，不要亂序，對於亂序的狀況，我們可以允許等待一定情況下的亂序，比如說先緩衝提前到的資料，然後去等待需要的資料，如果一定時間沒來就DROP掉，來保證順序性。

在TCP/IP協議棧中，滑動視窗的引入可以解決此問題，先來看從概念上資料分為哪些類

1. Sent and Acknowledged：這些資料表示已經發送成功並已經被確認的資料，比如圖中的前31個bytes，這些資料其實的位置是在視窗之外了，因為視窗內順序最低的被確認之後，要移除視窗，實際上是視窗進行合攏，同時開啟接收新的帶發送的資料

2. Send But Not Yet Acknowledged：這部分資料稱為發送但沒有被確認，資料被發送出去，沒有收到接收端的ACK，認為並沒有完成發送，這個屬於視窗內的資料。

3. Not Sent，Recipient Ready to Receive：這部分是儘快發送的資料，這部分資料已經被載入到緩衝中，也就是視窗中了，等待發送，其實這個視窗是完全有接收方告知的，接收方告知還是能夠接受這些包，所以發送方需要儘快的發送這些包

4. Not Sent，Recipient Not Ready to Receive： 這些資料屬於未發送，同時接收端也不允許發送的，因為這些資料已經超出了發送端所接收的範圍

對於接收端也是有一個接收視窗的，類似發送端，接收端的資料有3個分類，因為接收端並不需要等待ACK所以它沒有類似的接收並確認了的分類，情況如下

1.  Received and ACK Not Send to Process：這部分資料屬於接收了資料但是還沒有被上層的應用程式接收，也是被緩衝在視窗內

2.  Received  Not ACK: 已經接收並，但是還沒有回複ACK，這些包可能輸屬於Delay ACK的範疇了

3.  Not Received：有空位，還沒有被接收的資料。

發送視窗和可用視窗

對於發送方來講，視窗內的包括兩部分，就是發送視窗（已經發送了，但是沒有收到ACK），可用視窗，接收端允許發送但是沒有發送的那部分稱為可用視窗。

1. Send Window ： 20個bytes 這部分值是有接收方在三向交握的時候進行通告的，同時在接收過程中也不斷的通告可以發送的視窗大小，來進行適應

2. Window Already Sent: 已經發送的資料，但是並沒有收到ACK。

滑動視窗原理

TCP並不是每一個報文段都會回複ACK的，可能會對兩個報文段發送一個ACK，也可能會對多個報文段發送1個ACK【累計ACK】，比如說發送方有1/2/3 3個報文段，先發送了2,3 兩個報文段，但是接收方期望收到1報文段，這個時候2,3報文段就只能放在緩衝中等待報文1的空洞被填上，如果報文1，一直不來，報文2/3也將被丟棄，如果報文1來了，那麼會發送一個ACK對這3個報文進行一次確認。

舉一個例子來說明一下滑動視窗的原理：

1. 假設32~45 這些資料，是上層Application發送給TCP的，TCP將其分成四個Segment來發往internet

2. seg1 32~34 seg3 35~36 seg3 37~41 seg4 42~45  這四個片段，依次發送出去，此時假設接收端之接收到了seg1 seg2 seg4

3. 此時接收端的行為是回複一個ACK包說明已經接收到了32~36的資料，並將seg4進行緩衝（保證順序，產生一個儲存seg3 的hole）

4. 發送端收到ACK之後，就會將32~36的資料包從發送並沒有確認切到發送已經確認，提出視窗，這個時候視窗向右移動

5. 假設接收端通告的Window Size仍然不變，此時視窗右移，產生一些新的空位，這些是接收端允許發送的範疇

6. 對於丟失的seg3，如果超過一定時間，TCP就會重新傳送（重傳機制），重傳成功會seg3 seg4一塊被確認，不成功，seg4也將被丟棄

就是不斷重複著上述的過程，隨著視窗不斷滑動，將真箇資料流發送到接收端，實際上接收端的Window Size通告也是會變化的，接收端根據這個值來確定何時及發送多少資料，從對資料流進行流控。原理圖如下圖所示：

滑動視窗動態調整

主要是根據接收端的接收情況，動態去調整Window Size，然後來控制發送端的資料流量

1. 用戶端不斷快速發送資料，伺服器接收相對較慢，看下實驗的結果

a. 包175，發送ACK攜帶WIN = 384，告知用戶端，現在只能接收384個位元組

b. 包176，用戶端果真只發送了384個位元組，Wireshark也比較智能，也宣告TCP Window Full

c. 包177，伺服器回複一個ACK，並通告視窗為0，說明接收方已經收到所有資料，並儲存到緩衝區，但是這個時候應用程式並沒有接收這些資料，導致緩衝區沒有更多的空間，故通告視窗為0, 這也就是所謂的零視窗，零視窗期間，發送方停止發送資料

d. 用戶端察覺到視窗為0，則不再發送資料給接收方

e. 包178，接收方發送一個視窗通告，告知發送方已經有接收資料的能力了，可以發送資料包了

f.  包179，收到視窗通告之後，就發送緩衝區內的資料了.

總結一點，就是接收端可以根據自己的狀況通告視窗大小，從而控制發送端的接收，進行流量控制

參考文章

1.http://www.cricode.com/2679.html

2.http://kb.cnblogs.com/page/209100/