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/
————————————————
版權聲明：本文為CSDN博主「CQ小子」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/wdscq1234/java/article/details/52444277
喜歡這篇文章？歡迎打賞~~
