參考書籍：TCP-IP Guide

TCP的優(yōu)勢

從傳輸數(shù)據(jù)來講，TCP/UDP以及其他協(xié)議都可以完成數(shù)據(jù)的傳輸，從一端傳輸?shù)搅硗庖欢耍琓CP比較出眾的一點就是提供一個可靠的，流控的數(shù)據(jù)傳輸，所以實現(xiàn)起來要比其他協(xié)議復(fù)雜的多，先來看下這兩個修飾詞的意義：

 1. Reliability ，提供TCP的可靠性，TCP的傳輸要保證數(shù)據(jù)能夠準確到達目的地，如果不能，需要能檢測出來并且重新發(fā)送數(shù)據(jù)。

 2. Data Flow Control，提供TCP的流控特性，管理發(fā)送數(shù)據(jù)的速率，不要超過設(shè)備的承載能力

為了能夠?qū)崿F(xiàn)以上2點，TCP實現(xiàn)了很多細節(jié)的功能來保證數(shù)據(jù)傳輸，比如說 滑動窗口適應(yīng)系統(tǒng)，超時重傳機制，累計ACK等，這次先介紹一下滑動窗口的一些知識點。

滑動窗口引入

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

IP層協(xié)議屬于不可靠的協(xié)議，IP層并不關(guān)系數(shù)據(jù)是否發(fā)送到了對端，TCP通過確認機制來保證數(shù)據(jù)傳輸?shù)目煽啃裕诒容^早的時候使用的是send--wait--send的模式，其實這種模式叫做stop-wait模式，發(fā)送數(shù)據(jù)方在發(fā)送數(shù)據(jù)之后會啟動定時器，但是如果數(shù)據(jù)或者ACK丟失，那么定時器到期之后，收不到ACK就認為發(fā)送出現(xiàn)狀況，要進行重傳。這樣就會降低了通信的效率，如下圖所示，這種方式被稱為 positive acknowledgment with retransmission (PAR)

滑動窗口

可以假設(shè)一下，來優(yōu)化一下PAR效率低的缺點，比如我讓發(fā)送的每一個包都有一個id，接收端必須對每一個包進行確認，這樣設(shè)備A一次多發(fā)送幾個片段，而不必等候ACK，同時接收端也要告知它能夠收多少，這樣發(fā)送端發(fā)起來也有個限制，當然還需要保證順序性，不要亂序，對于亂序的狀況，我們可以允許等待一定情況下的亂序，比如說先緩存提前到的數(shù)據(jù)，然后去等待需要的數(shù)據(jù)，如果一定時間沒來就DROP掉，來保證順序性！

在TCP/IP協(xié)議棧中，滑動窗口的引入可以解決此問題，先來看從概念上數(shù)據(jù)分為哪些類

1. Sent and Acknowledged：這些數(shù)據(jù)表示已經(jīng)發(fā)送成功并已經(jīng)被確認的數(shù)據(jù)，比如圖中的前31個bytes，這些數(shù)據(jù)其實的位置是在窗口之外了，因為窗口內(nèi)順序最低的被確認之后，要移除窗口，實際上是窗口進行合攏，同時打開接收新的帶發(fā)送的數(shù)據(jù)

2. Send But Not Yet Acknowledged：這部分數(shù)據(jù)稱為發(fā)送但沒有被確認，數(shù)據(jù)被發(fā)送出去，沒有收到接收端的ACK，認為并沒有完成發(fā)送，這個屬于窗口內(nèi)的數(shù)據(jù)。

3. Not Sent，Recipient Ready to Receive：這部分是盡快發(fā)送的數(shù)據(jù)，這部分數(shù)據(jù)已經(jīng)被加載到緩存中，也就是窗口中了，等待發(fā)送，其實這個窗口是完全有接收方告知的，接收方告知還是能夠接受這些包，所以發(fā)送方需要盡快的發(fā)送這些包

4. Not Sent，Recipient Not Ready to Receive： 這些數(shù)據(jù)屬于未發(fā)送，同時接收端也不允許發(fā)送的，因為這些數(shù)據(jù)已經(jīng)超出了發(fā)送端所接收的范圍

對于接收端也是有一個接收窗口的，類似發(fā)送端，接收端的數(shù)據(jù)有3個分類，因為接收端并不需要等待ACK所以它沒有類似的接收并確認了的分類，情況如下

1.  Received and ACK Not Send to Process：這部分數(shù)據(jù)屬于接收了數(shù)據(jù)但是還沒有被上層的應(yīng)用程序接收，也是被緩存在窗口內(nèi)

2.  Received  Not ACK: 已經(jīng)接收并，但是還沒有回復(fù)ACK，這些包可能輸屬于Delay ACK的范疇了

3.  Not Received：有空位，還沒有被接收的數(shù)據(jù)。

發(fā)送窗口和可用窗口

對于發(fā)送方來講，窗口內(nèi)的包括兩部分，就是發(fā)送窗口（已經(jīng)發(fā)送了，但是沒有收到ACK），可用窗口，接收端允許發(fā)送但是沒有發(fā)送的那部分稱為可用窗口。

1. Send Window ： 20個bytes 這部分值是有接收方在三次握手的時候進行通告的，同時在接收過程中也不斷的通告可以發(fā)送的窗口大小，來進行適應(yīng)

2. Window Already Sent: 已經(jīng)發(fā)送的數(shù)據(jù)，但是并沒有收到ACK。

滑動窗口原理

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

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

1. 假設(shè)32~45 這些數(shù)據(jù)，是上層Application發(fā)送給TCP的，TCP將其分成四個Segment來發(fā)往internet

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

3. 此時接收端的行為是回復(fù)一個ACK包說明已經(jīng)接收到了32~36的數(shù)據(jù)，并將seg4進行緩存（保證順序，產(chǎn)生一個保存seg3 的hole）

4. 發(fā)送端收到ACK之后，就會將32~36的數(shù)據(jù)包從發(fā)送并沒有確認切到發(fā)送已經(jīng)確認，提出窗口，這個時候窗口向右移動

5. 假設(shè)接收端通告的Window Size仍然不變，此時窗口右移，產(chǎn)生一些新的空位，這些是接收端允許發(fā)送的范疇

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

就是不斷重復(fù)著上述的過程，隨著窗口不斷滑動，將真?zhèn)€數(shù)據(jù)流發(fā)送到接收端，實際上接收端的Window Size通告也是會變化的，接收端根據(jù)這個值來確定何時及發(fā)送多少數(shù)據(jù)，從對數(shù)據(jù)流進行流控。原理圖如下圖所示：

滑動窗口動態(tài)調(diào)整

主要是根據(jù)接收端的接收情況，動態(tài)去調(diào)整Window Size，然后來控制發(fā)送端的數(shù)據(jù)流量

1. 客戶端不斷快速發(fā)送數(shù)據(jù)，服務(wù)器接收相對較慢，看下實驗的結(jié)果

a. 包175，發(fā)送ACK攜帶WIN = 384，告知客戶端，現(xiàn)在只能接收384個字節(jié)

b. 包176，客戶端果真只發(fā)送了384個字節(jié)，Wireshark也比較智能，也宣告TCP Window Full

c. 包177，服務(wù)器回復(fù)一個ACK，并通告窗口為0，說明接收方已經(jīng)收到所有數(shù)據(jù)，并保存到緩沖區(qū)，但是這個時候應(yīng)用程序并沒有接收這些數(shù)據(jù)，導(dǎo)致緩沖區(qū)沒有更多的空間，故通告窗口為0, 這也就是所謂的零窗口，零窗口期間，發(fā)送方停止發(fā)送數(shù)據(jù)

d. 客戶端察覺到窗口為0，則不再發(fā)送數(shù)據(jù)給接收方

e. 包178，接收方發(fā)送一個窗口通告，告知發(fā)送方已經(jīng)有接收數(shù)據(jù)的能力了，可以發(fā)送數(shù)據(jù)包了

f.  包179，收到窗口通告之后，就發(fā)送緩沖區(qū)內(nèi)的數(shù)據(jù)了.

總結(jié)一點，就是接收端可以根據(jù)自己的狀況通告窗口大小，從而控制發(fā)送端的接收，進行流量控制

參考文章

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

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