標籤:
TCP的擁塞控制擁塞(congestion)
在某段時間,若對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的效能就要變壞。
擁塞控制
擁塞控制就是防止過多的資料注入到網路中,這樣可以使網路中的路由器或鏈路不致過載。
,橫座標是提供的負載(offered load),代表單位時間內輸入給網路的分組數目。縱座標是輸送量(throughput),代表單位時間內從網路輸出的分組數目。
理想狀態:在輸送量飽和之前,網路輸送量應等於提供的負載,故輸送量曲線是45度的斜線。但當提供的負載超過某一限度時,由於網路資源受限,輸送量不再增長而保持為水平線,即輸送量達到飽和。
實際狀態:隨著提供的負載的增大,網路輸送量的增大速率逐漸減小。也就是說,在網路輸送量還未達到飽和時,就已經有一部分的輸入分組被丟棄了。當網路的輸送量明顯的小於理想的輸送量時,網路就進入了輕度擁塞的狀態。當提供的負載達到某一數值時,網路的輸送量反而隨提供的負載的增大而下降,這時網路就進入了擁塞狀態。當提供的負載繼續增大到某一數值時,網路的輸送量就下降到零,網路無法工作,這就是所謂的死結(deadlock)。
幾種擁塞控制的方法
慢開始(slow-start)
發送方維持一個叫做擁塞視窗cwnd(congestion window)的狀態變數。擁塞視窗的大小取決於網路的擁塞程度,並且動態在變化。
慢開始的演算法是這樣的:
如果立即把大量的資料位元組注入到網路,那麼就有可能引起網路阻塞,所以由小到大逐漸增大發送視窗數值,即由小到大逐漸增大擁塞視窗數值。
開始先設定cwnd = 1,發送第一個報文段M1,接收方收到後確認M1。發送方收到對M1的確認後,把cwnd從1增大到2,於是發送方接著發送M2和M3兩個報文段。接收方收到後發回對M2和M3的確認。發送方每收到一個對新報文段的確認,就使發送方的擁塞視窗加1,因此發送方收到兩個確認後,cwnd就從2增大到4,並可以發送M4-M7共4個報文段。因此使用慢開始演算法後,每經過一個傳輸輪次,擁塞視窗cwnd就加倍。
為了防止擁塞視窗cwnd增長過大引起網路擁塞,還需要設定一個慢開始門限ssthresh狀態變數。用法如下
當cwnd<ssthresh時,使用上述的慢開始演算法。
當cwnd>ssthresh時,停止使用慢開始演算法而改用擁塞避免演算法。
當cwnd=ssthresh時,既可使用慢開始演算法,也可使用擁塞避免演算法。
擁塞避免演算法(congestion avoidance)
演算法思路:
讓擁塞視窗cwnd緩慢增大,即每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1,而不是加倍。這樣,擁塞視窗cwnd按線性規律緩慢增長,比慢開始短髮的擁塞視窗增長速率緩慢很多。
執行個體:
(1)為了便於理解,途中的視窗單位不使用位元組而使用報文段的個數。慢開始門限的初始值設定為16個報文段。即ssthresh=16。
(2)在執行慢開始演算法時,擁塞視窗cwnd的初始值為1。擁塞視窗cwnd隨著傳輸輪次按指數規律增長。當擁塞視窗cwnd增長到慢開始門限ssthresh時,就改為執行擁塞避免演算法,擁塞視窗按線性增長。
(3)假定擁塞視窗的數值增長到24時,網路出現逾時。更新後的ssthresh值變為12(即為24的一半),擁塞視窗再設定為1,並開始慢開始演算法。當cwnd=ssthresh=12時改為執行擁塞避免演算法,擁塞視窗按線性規律增長。
快重傳(fast retransmit)
演算法思路:
接收方每收到一個失序的報文段後就立即發出重複確認而不要等待自己發送資料時才捎帶確認。,接收方收到了M1和M2後都分別發出了確認。現假定接收方沒有收到M3,但是收到了M4。顯然,接收方不能確認M4,因為M4是失序的報文段。根據可靠傳輸原理,接收方可以什麼都不做,也可以在適當時機發送一次對M2的確認。但是在快重傳的規定裡,接收方應及時發送對M2的重複確認,這樣做可以讓發送方及早知道報文段M3沒有達到接收方。發送方接著發送M5和M6。接受方收到後,也還要再次發出對M2的重複確認。這樣,發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段M3,不必等到重傳計時器到期。
快恢複(fast recovery)
演算法思想:
當發送方連續收到三個重複確認時,不執行慢開始演算法,由於發送方現在認為網路很有可能沒有發生擁塞,因此,與慢開始不同之處是現在不執行慢開始演算法,而是把cwnd值設定為慢開始門限ssthresh減半後的數值,然後開始執行擁塞避免演算法,使擁塞視窗緩慢地線性增大。,TCP Reno版本就是在快重傳之後採用快恢複演算法,而不是採用慢開始演算法。
電腦網路(10)-----TCP的擁塞控制