TCP協(xié)議擁塞控制的滑動窗口協(xié)議解析

TCP協(xié)議作為一個可靠的面向流的傳輸協(xié)議，其可靠性和流量控制由滑動窗口協(xié)議保證，而擁塞控制則由控制窗口結(jié)合一系列的控制算法實現(xiàn)。

一、滑動窗口協(xié)議

關(guān)于這部分自己不曉得怎么敘述才好，因為理解的部分更多，下面就用自己的理解來介紹下TCP的精髓：滑動窗口協(xié)議。

所謂滑動窗口協(xié)議，自己理解有兩點：1. “窗口”對應(yīng)的是一段可以被發(fā)送者發(fā)送的字節(jié)序列，其連續(xù)的范圍稱之為“窗口”；2. “滑動”則是指這段“允許發(fā)送的范圍”是可以隨著發(fā)送的過程而變化的，方式就是按順序“滑動”。在引入一個例子來說這個協(xié)議之前，我覺得很有必要先了解以下前提：

-1. TCP協(xié)議的兩端分別為發(fā)送者A和接收者B，由于是全雙工協(xié)議，因此A和B應(yīng)該分別維護著一個獨立的發(fā)送緩沖區(qū)和接收緩沖區(qū)，由于對等性（A發(fā)B收和B發(fā)A收），我們以A發(fā)送B接收的情況作為例子；

-2. 發(fā)送窗口是發(fā)送緩存中的一部分，是可以被TCP協(xié)議發(fā)送的那部分，其實應(yīng)用層需要發(fā)送的所有數(shù)據(jù)都被放進了發(fā)送者的發(fā)送緩沖區(qū)；

-3. 發(fā)送窗口中相關(guān)的有四個概念：已發(fā)送并收到確認的數(shù)據(jù)（不再發(fā)送窗口和發(fā)送緩沖區(qū)之內(nèi)）、已發(fā)送但未收到確認的數(shù)據(jù)（位于發(fā)送窗口之中）、允許發(fā)送但尚未發(fā)送的數(shù)據(jù)以及發(fā)送窗口外發(fā)送緩沖區(qū)內(nèi)暫時不允許發(fā)送的數(shù)據(jù)；

-4. 每次成功發(fā)送數(shù)據(jù)之后，發(fā)送窗口就會在發(fā)送緩沖區(qū)中按順序移動，將新的數(shù)據(jù)包含到窗口中準(zhǔn)備發(fā)送；

TCP建立連接的初始，B會告訴A自己的接收窗口大小，比如為‘20’：

字節(jié)31-50為發(fā)送窗口

A發(fā)送11個字節(jié)后，發(fā)送窗口位置不變，B接收到了亂序的數(shù)據(jù)分組：

只有當(dāng)A成功發(fā)送了數(shù)據(jù)，即發(fā)送的數(shù)據(jù)得到了B的確認之后，才會移動滑動窗口離開已發(fā)送的數(shù)據(jù)；同時B則確認連續(xù)的數(shù)據(jù)分組，對于亂序的分組則先接收下來，避免網(wǎng)絡(luò)重復(fù)傳遞：

二、流量控制

流量控制方面主要有兩個要點需要掌握。一是TCP利用滑動窗口實現(xiàn)流量控制的機制；二是如何考慮流量控制中的傳輸效率。

1. 流量控制

所謂流量控制，主要是接收方傳遞信息給發(fā)送方，使其不要發(fā)送數(shù)據(jù)太快，是一種端到端的控制。主要的方式就是返回的ACK中會包含自己的接收窗口的大小，并且利用大小來控制發(fā)送方的數(shù)據(jù)發(fā)送：

這里面涉及到一種情況，如果B已經(jīng)告訴A自己的緩沖區(qū)已滿，于是A停止發(fā)送數(shù)據(jù)；等待一段時間后，B的緩沖區(qū)出現(xiàn)了富余，于是給A發(fā)送報文告訴A我的rwnd大小為400，但是這個報文不幸丟失了，于是就出現(xiàn)A等待B的通知||B等待A發(fā)送數(shù)據(jù)的死鎖狀態(tài)。為了處理這種問題，TCP引入了持續(xù)計時器（Persistence timer），當(dāng)A收到對方的零窗口通知時，就啟用該計時器，時間到則發(fā)送一個1字節(jié)的探測報文，對方會在此時回應(yīng)自身的接收窗口大小，如果結(jié)果仍未0，則重設(shè)持續(xù)計時器，繼續(xù)等待。

2. 傳遞效率

一個顯而易見的問題是：單個發(fā)送字節(jié)單個確認，和窗口有一個空余即通知發(fā)送方發(fā)送一個字節(jié)，無疑增加了網(wǎng)絡(luò)中的許多不必要的報文（請想想為了一個字節(jié)數(shù)據(jù)而添加的40字節(jié)頭部吧?。?，所以我們的原則是盡可能一次多發(fā)送幾個字節(jié)，或者窗口空余較多的時候通知發(fā)送方一次發(fā)送多個字節(jié)。對于前者我們廣泛使用Nagle算法，即：

*1. 若發(fā)送應(yīng)用進程要把發(fā)送的數(shù)據(jù)逐個字節(jié)地送到TCP的發(fā)送緩存，則發(fā)送方就把第一個數(shù)據(jù)字節(jié)先發(fā)送出去，把后面的字節(jié)先緩存起來；

*2. 當(dāng)發(fā)送方收到第一個字節(jié)的確認后（也得到了網(wǎng)絡(luò)情況和對方的接收窗口大?。侔丫彌_區(qū)的剩余字節(jié)組成合適大小的報文發(fā)送出去；

*3. 當(dāng)?shù)竭_的數(shù)據(jù)已達到發(fā)送窗口大小的一半或以達到報文段的最大長度時，就立即發(fā)送一個報文段；

對于后者我們往往的做法是讓接收方等待一段時間，或者接收方獲得足夠的空間容納一個報文段或者等到接受緩存有一半空閑的時候，再通知發(fā)送方發(fā)送數(shù)據(jù)。

三、擁塞控制

網(wǎng)絡(luò)中的鏈路容量和交換結(jié)點中的緩存和處理機都有著工作的極限，當(dāng)網(wǎng)絡(luò)的需求超過它們的工作極限時，就出現(xiàn)了擁塞。擁塞控制就是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。常用的方法就是：

1. 慢開始、擁塞控制

2. 快重傳、快恢復(fù)

一切的基礎(chǔ)還是慢開始，這種方法的思路是這樣的：

-1. 發(fā)送方維持一個叫做“擁塞窗口”的變量，該變量和接收端口共同決定了發(fā)送者的發(fā)送窗口；

-2. 當(dāng)主機開始發(fā)送數(shù)據(jù)時，避免一下子將大量字節(jié)注入到網(wǎng)絡(luò)，造成或者增加擁塞，選擇發(fā)送一個1字節(jié)的試探報文；

-3. 當(dāng)收到第一個字節(jié)的數(shù)據(jù)的確認后，就發(fā)送2個字節(jié)的報文；

-4. 若再次收到2個字節(jié)的確認，則發(fā)送4個字節(jié)，依次遞增2的指數(shù)級；

-5. 最后會達到一個提前預(yù)設(shè)的“慢開始門限”，比如24，即一次發(fā)送了24個分組，此時遵循下面的條件判定：

*1. cwnd 《 ssthresh， 繼續(xù)使用慢開始算法；

*2. cwnd 》 ssthresh，停止使用慢開始算法，改用擁塞避免算法；

*3. cwnd = ssthresh，既可以使用慢開始算法，也可以使用擁塞避免算法；

-6. 所謂擁塞避免算法就是：每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口+1，即讓擁塞窗口緩慢地增大，按照線性規(guī)律增長；

-7. 當(dāng)出現(xiàn)網(wǎng)絡(luò)擁塞，比如丟包時，將慢開始門限設(shè)為原先的一半，然后將cwnd設(shè)為1，執(zhí)行慢開始算法（較低的起點，指數(shù)級增長）；

上述方法的目的是在擁塞發(fā)生時循序減少主機發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠的時間把隊列中積壓的分組處理完畢。慢開始和擁塞控制算法常常作為一個整體使用，而快重傳和快恢復(fù)則是為了減少因為擁塞導(dǎo)致的數(shù)據(jù)包丟失帶來的重傳時間，從而避免傳遞無用的數(shù)據(jù)到網(wǎng)絡(luò)?？熘貍鞯臋C制是：

-1. 接收方建立這樣的機制，如果一個包丟失，則對后續(xù)的包繼續(xù)發(fā)送針對該包的重傳請求；

-2. 一旦發(fā)送方接收到三個一樣的確認，就知道該包之后出現(xiàn)了錯誤，立刻重傳該包；

-3. 此時發(fā)送方開始執(zhí)行“快恢復(fù)”算法：

*1. 慢開始門限減半；

*2. cwnd設(shè)為慢開始門限減半后的數(shù)值；

*3. 執(zhí)行擁塞避免算法（高起點，線性增長）；