6、擁塞控制

6.1、擁塞控制概述

擁塞：當對網絡資源的需求超過了現有的資源的可用部分。

擁塞出現的原因：

1.鏈路容量不夠大，在鏈路上形成堆積，路由器一直是高負荷運轉。

2.路由器緩存不夠大，交來的數據太多遠遠超過了處理的速度就會在路由器緩存形成堆積，堆不下的就丟失了。

3.處理機太慢了。

網絡擁塞往往是多種原因的，僅僅增加網絡資源有可能適得其反。比如說增大路由器的緩存但并未增加鏈路帶寬和處理機速度會導致排隊時間更長一旦用TCP報文傳輸那么大量的超時重傳會引發更嚴重的問題。提高處理機的速度也不行因為你會把巨大的壓力施加給下一跳。需要耗費大量的資源。

6.2、擁塞控制與流量控制

1.流量控制是點到點的，擁塞控制是全局性網絡的。

2.擁塞控制是防止過多數據注入到網絡，控制發送速率這又與流量控制有些相似。

3.流量控制是發送緩存與接收緩存的問題，擁塞控制是網絡的問題。

6.3、擁塞控制的原理

1.開環控制方法：在設計網絡時考慮發生擁塞的因素，力求網絡不發生擁塞。

2.閉環控制方法：

基于反饋環路的概念：

?檢測網絡系統以便檢測到擁塞在何時何地發生；

?將擁塞發生的信息傳送到可采取行動的地方；

?調整網絡系統的運行已解決出現的問題。

6.4、擁塞出現的指標

1.由于緩沖區不夠而造成的分組丟失的百分數。

2.平均隊列長度。

3.超時重傳的分組數。

4.平均分組時延。

5.平均分組時延標準差。

一旦檢測到了擁塞會向源站發送擁塞信息。

6.5、擁塞通知的傳遞

IP中tos字段00表示不支持ECN傳輸，01或10表示支持ECN傳輸，11表示產生擁塞。接收端知道產生擁塞后將TCP報文首部中的ECE置為1告訴源端減小發送速率，源端降低速率后下一次發送報文TCP中的CWR置為1降低擁塞窗口(發送窗口是受對方接收窗口和擁塞窗口控制的)。

6.6、TCP擁塞控制方法

TCP采用基于窗口的方法進行擁塞控制，該方法屬于閉環控制方法。TCP發送方維持一個擁塞窗口，擁塞窗口根據網絡的擁塞程度動態的變化。發送端利用擁塞窗口根據擁塞情況調整發送的數據量若網絡沒有擁塞則增大窗口讓他多發數據提高網絡利用率。所以真正發送窗口的值為接收窗口值和擁塞窗口值的最小值。

現在我們假設對方接收緩存無限大僅考慮網絡問題探討一下TCP的擁塞控制算法。

6.6.1、慢開始算法

目的：用來探測網絡的負載或者承受能力。

算法思路：由小到大逐漸增大擁塞窗口，當自己主機剛連進網絡時如果一下注入太多資源可能造成網絡擁塞，因此循序漸進的探測網絡的擁塞程度。每收到一個確認報文擁塞窗口就增加一個報文段。

發送方每接收到一個確認報文就將擁塞窗口增加一個報文段。如圖所示我們可以看出發送一個收到一個確認下次發兩個，收到兩個確認下次發2+2=4個收到4個確認下次發4+4等于8個由此可見慢開始算法并不慢。

慢開始門限ssthresh(狀態變量)防止擁塞窗口cwnd增長過大引起網絡擁塞。

?當cwnd

?當cwnd>sshresh，停止使用慢開始算法而使用擁塞避免方法。

?當cwnd = sshresh時既可以使用慢開始算法也可以使用擁塞避免算法。

擁塞避免算法：每經過一個RTT，cwnd = cwnd + 1，他的增長是線性的。

當出現網絡擁塞時,ssthresh = max(cwnd/2,2)；cwnd = 1；執行慢開始算法。

目的：迅速減少網絡中的分組數，有利于路由器將積壓的分組處理完。

6.6.2、擁塞控制流程

?0~1執行慢開始算法擁塞窗口呈指數級增大。

?1~2達到慢開始門限時執行擁塞避免算法擁塞窗口呈線性增大。

?2~3超時重傳可能出現網絡擁塞執行將擁塞窗口置1重新執行慢開始算法。

?34同12

?4~5中間出現報文丟失收到3個確認報文執行快重傳

6.6.3、快重傳

快重傳算法要求接收方不要等待自己發送數據時才進行捎帶確認，而是要立即發送確認，即使收到了失序的報文也要立即發出對已收到的報文段的重復確認。發送方只需要一連收到3個重復確認就立即重傳這樣就不會出現超時。

當我發送M3時發生了報文丟失按理說我應該等超時之后再重新發送。但是這樣做有可能導致誤會這時候網絡可能沒有發生擁塞。當M3丟失后接收方發送已接收報文的重復確認即M2當M2重復確認3次M3立即重傳。快重傳算法可以讓發送方盡早知道報文發生了丟失。這樣就不會超時，就不會讓對方誤以為發生了擁塞。

6.6.4、快恢復算法

?當發送端收到連續3個重復確認時，發送方認為網絡很可能沒有發生阻塞，因此不執行慢開始算法，而是執行快恢復算法；

?ssthresh = cwnd/2；

?新擁塞窗口cwnd = ssthresh;

?開始執行擁塞避免算法，使擁塞窗口緩慢地線性增大。