TCP-IP詳解：滑動視窗（Sliding Window）
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，收到視窗通告之後，就傳送緩衝區內的資料了.
總結一點，就是接收端可以根據自己的狀況通告視窗大小，從而控制傳送端的接收，進行流量控制