參考書籍：TCP-IP Guide

TCP的優(yōu)勢

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

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

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

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

滑動(dòng)窗口引入

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

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

滑動(dòng)窗口

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

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

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

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

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

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

對于接收端也是有一個(gè)接收窗口的，類似發(fā)送端，接收端的數(shù)據(jù)有3個(gè)分類，因?yàn)榻邮斩瞬⒉恍枰却鼳CK所以它沒有類似的接收并確認(rèn)了的分類，情況如下

1.  Received and ACK Not Send to Process：這部分?jǐn)?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個(gè)bytes 這部分值是有接收方在三次握手的時(shí)候進(jìn)行通告的，同時(shí)在接收過程中也不斷的通告可以發(fā)送的窗口大小，來進(jìn)行適應(yīng)

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

滑動(dòng)窗口原理

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

舉一個(gè)例子來說明一下滑動(dòng)窗口的原理：

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

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

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

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

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

6. 對于丟失的seg3，如果超過一定時(shí)間，TCP就會(huì)重新傳送（重傳機(jī)制），重傳成功會(huì)seg3 seg4一塊被確認(rèn)，不成功，seg4也將被丟棄

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

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

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

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

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

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

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

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

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

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

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

參考文章

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

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