擁塞控制和流量控制的區別

擁塞控制

網絡擁塞現象是指到達通信子網中某一部分的分組數量過多,使得該部分網絡來不及處理,以致引起這部分乃至整個網絡性能下降的現象,嚴重時甚至會導致網絡通信業務陷入停頓,即出現死鎖現象。擁塞控制是處理網絡擁塞現象的一種機制。
流量控制數據的傳送與接收過程當中很可能出現收方來不及接收的情況,這時就需要對發方進行控制,以免數據丟失。            

流量控制機制：

流量控制用於防止在端口阻塞的情況下丟幀，這種方法是當發送或接收緩衝區開始溢出時通過將阻塞信號發送回源地址實現的。流量控制可以有效的防止由於網絡中瞬間的大量數據對網絡帶來的衝擊，保證用戶網絡高效而穩定的運行。
            

TCP的擁塞控制            
                       
1. 引言
        TCP是Internet上通用的傳輸層協議之一，是目前應用最廣泛的傳輸控制協議，其核心是擁塞控制機制。基於Internet的交換機的通信信道、處理速度及緩衝存儲空間通常是網上所有主機共享的資源，也是網絡系統潛在的瓶頸。隨着信源主機數以及信源業務端業務量的不斷增多，瓶頸處就有可能發生資源競爭，從而導致網絡擁塞。TCP的一個重要組成部分是執行擁塞控制和擁塞恢復的算法集合。TCP擁塞控制算法的目標是最大限度利用網絡帶寬，同時不產生數據流傳輸中的擁塞現象。因此，自從上個世紀80年代出現第一次擁塞崩潰以來，TCP擁塞控制策略就在不斷地進行完善和改進。
2. 傳統的TCP擁塞控制機制
         傳統的TCP中的擁塞控制機制主要是基於Van Jacobson提出的"慢啓動"算法、"擁塞避免"算法和一個用於估計週轉RTT(round trip time)的算法。
         慢啓動算法通過觀察到新分組進入網絡的速率應該與另一端返回確認的速率相同而進行工作。慢啓動爲發送方的TCP增加了另一個窗口：擁塞窗口(congestion window)， 記爲cwnd。當與另一個網絡的主機建立TCP連接時，擁塞窗口被初始化爲1個報文段（即另一端通告的報文段大小）。每收到一個ACK，擁塞窗口就增加一個報文段（cwnd以字節爲單位，但是慢啓動以報文段大小爲單位進行增加）。發送方取擁塞窗口與通告窗口中的最小值作爲發送上限。擁塞窗口是發送方使用的流量控制，而通告窗口則是接收方使用的流量控制。發送方開始時發送一個報文段，然後等待ACK。當收到該ACK時，擁塞窗口從1增加爲2，即可以發送兩個報文段。當收到這兩個報文段的ACK時，擁塞窗口就增加爲4，這是一種指數增加的關係。在某些點上可能達到了互聯網的容量，於是中間路由器開始丟棄分組。擁塞避免算法是一種處理丟失分組的方法。該算法假定由於分組受到損壞引起的丟失是非常少的（遠小於1%），因此分組丟失就意味着在源主機和目的主機之間的某處網絡上發生了擁塞。有兩種分組丟失的指示：發生超時和接收到重複的確認。擁塞避免算法和慢啓動算法是兩個目的不同、獨立的算法。但是當擁塞發生時，我們希望降低分組進入網絡的傳輸速率，於是可以調用慢啓動來作到這一點。在實際中這兩個算法通常在一起實現。1990年出現的TCP Reno版本增加了"快速重傳"算法、"快速恢復"算法，避免了當網絡擁塞不夠嚴重時採用"慢啓動"算法而造成過大地減小發送窗口尺寸的現象。
3. 擁塞控制的四個階段
         a．慢啓動階段(slow start)：發送方一開始便向網絡發送多個報文段，直至達到接收方通告的窗口大小爲止。當發送方和接收方處於同一個局域網時，這種方式是可以的。但是如果在發送方和接收方之間存在多個路由器和速率較慢的鏈路時，就有可能出現一些問題。一些中間路由器必須緩存分組，並有可能耗盡存儲器的空間。
         b．擁塞避免階段（congestion avoidance）：當發現超時或收到3個相同ACK確認幀時，則表示有丟包事件，此時網絡已發生擁塞現象，此時要進行相應的擁塞控制。將慢啓動閾值設置爲當前擁塞窗口的一半；如檢測到超時，擁塞窗口就被置爲l。如果擁塞窗口小於或等於慢啓動閾值，TCP重新進人慢啓動階段；如果擁塞窗口大於慢啓動閾值，TCP執行擁塞避免算法。
          c．快速重傳階段(fast retransmit)：當TCP源端收到到三個相同的ACK副本時，即認爲有數據包丟失，則源端重傳丟失的數據包，而不必等待RTO超時。同時將ssthresh設置爲當前cwnd值的一半，並且將cwnd減爲原先的一半。
          d．快速恢復階段(fast recovery) ：當"舊"數據包離開網絡後，才能發送"新"數據包進入網絡，即同一時刻在網絡中傳輸的數據包數量是恆定的。如果發送方收到一個重複的ACK，則認爲已經有一個數據包離開了網絡，於是將擁塞窗口加1。                       
                        
4. 對傳統TCP擁塞控制機制的發展及改進
        4.1 對慢啓動的改進　　
        慢啓動(slow start)算法通過逐漸增加cwnd的大小來探測可用的網絡容量，防止連接開始時採用不合適的發送量導致網絡擁塞。然而有時該算法也會浪費可用的網絡容量，因爲慢啓動算法總是從cwnd＝l開始，每收到一個ACK，cwnd增加l，對RTT時間長的網絡，爲使cwnd達到一個合適的值，需要花很長的時間，特別是網絡實際容量很大時，會造成浪費。爲此可採用大的初始窗口，大的初始窗口避免了延遲ACK機制下單個報文段初始窗口的等待超時問題，縮短了小TCP流的傳輸時間和大延遲鏈路上的慢啓動時間。
         在慢啓動階段，在每個RTT時間內，cwnd增加一倍，這樣當cwnd增加到一定的值時，就可能導致以網絡能夠處理的最大容量的2倍來發送數據，從而淹沒網絡。Hoe建議使用packet-pair算法和測量RTT來爲ssthresh估計合適值，以此來適時地結束慢啓動階段。但是由於受各方面干擾，估算合理的ssthresh值並不容易，因此這個方法的效果是有限的。而Smooth-start較爲平滑地從慢啓動過渡到擁塞避免階段，減少了報文段丟失和突發通訊量，提高了TCP擁塞控制的性能。
 4.2 對重傳與恢復的改進
          爲了避免不必要的重傳超時，有人提出了一種受限傳輸機制：如果接收方的廣播窗口允許的話，發送方接收到一個或者兩個重複的ACK(acknowledgment)後，繼續傳輸新的數據報文段。受限的傳輸機制允許具有較小窗口的TCP連接進行錯誤恢復，而且避免了不必要的重傳。
          有很多情況下，數據報文段並沒有丟失，但TCP發送方可能會誤判數據報文段丟失，然後調用擁塞控制規程減少擁塞窗口的大小。比如當重傳定時器過早溢出時，發送方在重傳數據報文段時不必要地減少了擁塞窗口，而這時並沒有數據報文段丟失。如果是由於數據報文段的重新組織而不是數據報文段丟失，而導致3個重複的確認，同樣會導致發送方不必要地在快速重傳數據報文段後減少擁塞窗口。
           如果TCP的發送方在重傳數據報文段一個RTT後發現接收方接收到了重傳數據報文段的兩個拷貝，則可以推斷重傳是不必要的。這時，TCP的發送方可以撤銷對擁塞窗口的減少。發送方可以通過將慢啓動門限增加到原始值，調用慢啓動規程使擁塞窗口恢復原先值。除了恢復擁塞窗口，TCP發送方還可以調整重複確認門限或者重傳超時參數來避免由於多次不必要的重傳而浪費帶寬。
4.3 對公平性的改進 
        在擁塞避免階段，如果沒有發生丟包事件，則TCP發送方的cwnd在每個RTT時間內大約可以增加一個報文段大小，但這樣會造成具有不同RTT時間或窗口尺寸的多個連接在瓶頸處對帶寬競爭的不公平性，RTT時間或窗口小的連接，相應的cwnd增長速度也相對緩慢，所以只能得到很小一部分帶寬。
        要解決上述問題，可以通過在路由器處使用公平隊列和TCP友好緩存管理來進行控制以增加公平性。然而如沒有路由器的參與，要增加公平性，就要求TCP發送端的擁塞控制進行相應的改變，在擁塞避免階段使共享同一資源的各個TCP連接以相同速度發送數據，從而確保了各個連接間的公平性。
 5. 結論
        該文在研究和分析各種基於TCP的數據流擁塞控制算法和參考有關文檔的基礎上，對以TCP爲核心的擁塞控制機制進行了發展和改進，這些改進將使TCP的性能在不同的網絡中取得更好的性能。其中避免不必要的重傳超時、撤銷不必要的擁塞控制等是隨着網絡技術的發展而對TCP的改進，它們通過不同的方式改進了TCP的性能，具有更廣泛的適應性。