TCP的擁塞控制

1.引言

       計算機網絡中的帶寬、交換結點中的緩存和處理機等，都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞。這種狀況就叫作擁塞。

       擁塞控制就是防止過多的數據注入網絡中，這樣可使網絡中的路由器或鏈路不致過載。擁塞控制是一個全局性的過程，和流量控制不一樣，流量控制指點對點通訊量的控制。

2.慢開始與擁塞避免

       發送方維持一個叫作擁塞窗口cwnd（congestion window）的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，而且動態地在變化。發送方讓本身的發送窗口等於擁塞窗口，另外考慮到接受方的接收能力，發送窗口可能小於擁塞窗口。

       慢開始算法的思路就是，不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增長擁塞窗口的大小。

       這裏用報文段的個數的擁塞窗口大小舉例說明慢開始算法，實時擁塞窗口大小是以字節爲單位的。以下圖：

       固然收到單個確認但此確認多個數據報的時候就加相應的數值。因此一次傳輸輪次以後擁塞窗口就加倍。這就是乘法增加，和後面的擁塞避免算法的加法增加比較。

       爲了防止cwnd增加過大引發網絡擁塞，還需設置一個慢開始門限ssthresh狀態變量。ssthresh的用法以下：

當cwnd<ssthresh時，使用慢開始算法。

當cwnd>ssthresh時，改用擁塞避免算法。

當cwnd=ssthresh時，慢開始與擁塞避免算法任意。

       擁塞避免算法讓擁塞窗口緩慢增加，即每通過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規律緩慢增加。

       不管是在慢開始階段仍是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確承認能是其餘緣由的分組丟失，可是由於沒法斷定，因此都當作擁塞來處理），就把慢開始門限設置爲出現擁塞時的發送窗口大小的一半。而後把擁塞窗口設置爲1，執行慢開始算法。以下圖：

      再次提醒這裏只是爲了討論方便而將擁塞窗口大小的單位改成數據報的個數，實際上應當是字節。

3.快重傳和快恢復

       快重傳要求接收方在收到一個失序的報文段後就當即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器時間到期。以下圖：

快重傳配合使用的還有快恢復算法，有如下兩個要點:

①當發送方連續收到三個重複確認時，就執行「乘法減少」算法，把ssthresh門限減半。可是接下去並不執行慢開始算法。

②考慮到若是網絡出現擁塞的話就不會收到好幾個重複的確認，因此發送方如今認爲網絡可能沒有出現擁塞。因此此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法。以下圖：

4.隨機早期檢測RED

       以上的擁塞避免算法並無和網絡層聯繫起來，實際上網絡層的策略對擁塞避免算法影響最大的就是路由器的丟棄策略。在簡單的狀況下路由器一般按照先進先出的策略處理到來的分組。當路由器的緩存裝不下分組的時候就丟棄到來的分組，這叫作尾部丟棄策略。這樣就會致使分組丟失，發送方認爲網絡產生擁塞。更爲嚴重的是網絡中存在不少的TCP鏈接，這些鏈接中的報文段一般是複用路由路徑。若發生路由器的尾部丟棄，可能影響到不少條TCP鏈接，結果就是這許多的TCP鏈接在同一時間進入慢開始狀態。這在術語中稱爲全局同步。全局同步會使得網絡的通訊量忽然降低不少，而在網絡恢復正常以後，其通訊量又忽然增大不少。

       爲避免發生網路中的全局同步現象，路由器採用隨機早期檢測(RED:randomearly detection)。該算法要點以下：

       使路由器的隊列維持兩個參數，即隊列長隊最小門限min和最大門限max，每當一個分組到達的時候，RED就計算平均隊列長度。而後分狀況對待到來的分組：

①平均隊列長度小於最小門限——把新到達的分組放入隊列排隊。

②平均隊列長度在最小門限與最大門限之間——則按照某一律率將分組丟棄。

③平均隊列長度大於最大門限——丟棄新到達的分組。

      以機率p隨機丟棄分組，讓擁塞控制只在個別的TCP鏈接上執行，於是避免全局性的擁塞控制。

       RED的關鍵就是選擇三個參數最小門限、最大門限、丟棄機率和計算平均隊列長度。平均隊列長度採用加權平均的方法計算平均隊列長度，這和往返時間（RTT）的計算策略是同樣的。

 

爲了防止網絡的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啓動(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳(Fast retransmit)」、「快速恢復(Fast Recovery)」算法，再後來在TCP NewReno中又對「快速恢復」算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)算法，還有其餘方面的大大小小的改進，成爲網絡研究的一個熱點。

TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，在以前咱們還討論過TCP還有一個對端通告的接收窗口(rwnd)用於流量控制。窗口值的大小就表明可以發送出去的但尚未收到ACK的最大數據報文段，顯然窗口越大那麼數據發送的速度也就越快，可是也有越可能使得網絡出現擁塞，若是窗口值爲1，那麼就簡化爲一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制算法就是要在這二者之間權衡，選取最好的cwnd值，從而使得網絡吞吐量最大化且不產生擁塞。

因爲須要考慮擁塞控制和流量控制兩個方面的內容，所以TCP的真正的發送窗口=min(rwnd, cwnd)。可是rwnd是由對端肯定的，網絡環境對其沒有影響，因此在考慮擁塞的時候咱們通常不考慮rwnd的值，咱們暫時只討論如何肯定cwnd值的大小。關於cwnd的單位，在TCP中是以字節來作單位的，咱們假設TCP每次傳輸都是按照MSS大小來發送數據的，所以你能夠認爲cwnd按照數據包個數來作單位也能夠理解，因此有時咱們說cwnd增長1也就是至關於字節數增長1個MSS大小。

慢啓動：最初的TCP在鏈接創建成功後會向網絡中發送大量的數據包，這樣很容易致使網絡中路由器緩存空間耗盡，從而發生擁塞。所以新創建的鏈接不可以一開始就大量發送數據包，而只能根據網絡狀況逐步增長每次發送的數據量，以免上述現象的發生。具體來講，當新建鏈接時，cwnd初始化爲1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增長1個MSS大小。這樣cwnd的值就隨着網絡往返時間(Round Trip Time,RTT)呈指數級增加，事實上，慢啓動的速度一點也不慢，只是它的起點比較低一點而已。咱們能夠簡單計算下：

   開始           --->     cwnd = 1

   通過1個RTT後   --->     cwnd = 2*1 = 2

   通過2個RTT後   --->     cwnd = 2*2= 4

   通過3個RTT後   --->     cwnd = 4*2 = 8

若是帶寬爲W，那麼通過RTT*log2W時間就能夠佔滿帶寬。

擁塞避免：從慢啓動能夠看到，cwnd能夠很快的增加上來，從而最大程度利用網絡帶寬資源，可是cwnd不能一直這樣無限增加下去，必定須要某個限制。TCP使用了一個叫慢啓動門限(ssthresh)的變量，當cwnd超過該值後，慢啓動過程結束，進入擁塞避免階段。對於大多數TCP實現來講，ssthresh的值是65536(一樣以字節計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值再也不指數級往上升，開始加法增長。此時當窗口中全部的報文段都被確認時，cwnd的大小加1，cwnd的值就隨着RTT開始線性增長，這樣就能夠避免增加過快致使網絡擁塞，慢慢的增長調整到網絡的最佳值。

上面討論的兩個機制都是沒有檢測到擁塞的狀況下的行爲，那麼當發現擁塞了cwnd又該怎樣去調整呢？

首先來看TCP是如何肯定網絡進入了擁塞狀態的，TCP認爲網絡擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每個報文段都有一個定時器，稱爲重傳定時器(RTO)，當RTO超時且尚未獲得數據確認，那麼TCP就會對該報文段進行重傳，當發生超時時，那麼出現擁塞的可能性就很大，某個報文段可能在網絡中某處丟失，而且後續的報文段也沒有了消息，在這種狀況下，TCP反應比較「強烈」：

1.把ssthresh下降爲cwnd值的一半

2.把cwnd從新設置爲1

3.從新進入慢啓動過程。

從總體上來說，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減少。能夠看出TCP的該原則能夠較好地保證流之間的公平性，由於一旦出現丟包，那麼當即減半退避，能夠給其餘新建的流留有足夠的空間，從而保證整個的公平性。

其實TCP還有一種狀況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會當即發送ACK，TCP利用3個相同的ACK來斷定數據包的丟失，此時進行快速重傳，快速重傳作的事情有：

1.把ssthresh設置爲cwnd的一半

2.把cwnd再設置爲ssthresh的值(具體實現有些爲ssthresh+3)

3.從新進入擁塞避免階段。

後來的「快速恢復」算法是在上述的「快速重傳」算法後添加的，當收到3個重複ACK時，TCP最後進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復算法通常同時使用。快速恢復的思想是「數據包守恆」原則，即同一個時刻在網絡中的數據包數量是恆定的，只有當「老」數據包離開了網絡後，才能向網絡中發送一個「新」的數據包，若是發送方收到一個重複的ACK，那麼根據TCP的ACK機制就代表有一個數據包離開了網絡，因而cwnd加1。若是可以嚴格按照該原則那麼網絡中不多會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。

具體來講快速恢復的主要步驟是：

1.當收到3個重複ACK時，把ssthresh設置爲cwnd的一半，把cwnd設置爲ssthresh的值加3，而後重傳丟失的報文段，加3的緣由是由於收到3個重複的ACK，代表有3個「老」的數據包離開了網絡。 

2.再收到重複的ACK時，擁塞窗口增長1。

3.當收到新的數據包的ACK時，把cwnd設置爲第一步中的ssthresh的值。緣由是由於該ACK確認了新的數據，說明從重複ACK時的數據都已收到，該恢復過程已經結束，能夠回到恢復以前的狀態了，也即再次進入擁塞避免狀態。

快速重傳算法首次出如今4.3BSD的Tahoe版本，快速恢復首次出如今4.3BSD的Reno版本，也稱之爲Reno版的TCP擁塞控制算法。

能夠看出Reno的快速重傳算法是針對一個包的重傳狀況的，然而在實際中，一個重傳超時可能致使許多的數據包的重傳，所以當多個數據包從一個數據窗口中丟失時而且觸發快速重傳和快速恢復算法時，問題就產生了。所以NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，能夠恢復一個窗口內多個包丟失的狀況。具體來說就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno須要收到該窗口內全部數據包的確認後纔會退出快速恢復狀態，從而更一步提升吞吐量。

SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會所有告訴對方，從而減小數據發送方重傳的盲目性。好比說序號1，2，3，5，7的數據收到了，那麼普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項裏面告知對端，從而提升性能，當使用SACK的時候，NewReno算法能夠不使用，由於SACK自己攜帶的信息就可使得發送方有足夠的信息來知道須要重傳哪些包，而不須要重傳哪些包。