中文摘要
摘要：擁塞控制是TCP ( Transmission Control Protocol) 協議中重要的一個部分，被不斷的改進與完善。本文對網絡擁塞的出現原因和情況進行分析的同時，總結了現有的隱式擁塞控制算法的基本思路以及擁塞控制在當下面臨的問題。
關鍵詞：擁塞控制；互聯網
英文摘要
Abstraction: Congestion control is an important part of TCP protocol and has been improved gradually all these times. This Passage is going to make a brief summary about the cause of congestive collapse, the main idea of congestion control algorithm and the problem it faces nowadays.
Keywords：Congestion control; Internet
1. 概述
擁塞崩潰是互聯網的發展之路上必須面對的一個問題。隨着互聯網的發展與互聯網用戶的激增，互聯網用戶對於互聯網的需求量超過了互聯網設備（如路由器）的承載能力。這將會導致網絡擁塞崩潰的發生。一旦擁塞崩潰的發生，這條鏈路便會陷入一個惡性循環，嚴重影響了網絡的性能。本文將圍繞網絡擁塞出現的原因，擁塞控制的基本思路以及擁塞控制面臨的問題展開討論。
2. 擁塞的出現與擁塞控制
1. 網絡擁塞的出現條件
當網絡存在過多的數據分組以至於超過了網絡設備所能提供的極限時，網絡的性能就會下降，這種現象就叫爲擁塞[1]。網絡擁塞主要出現在網絡資源相對短缺的部分，比如一個網絡的瓶頸鍊路。例如在互聯網中的某一個路由器節點上，有過多的數據分組同時請求通過同一個端口進行存儲轉發。
1. 若該路由器緩存空間足夠大，所有的數據分組能夠被緩存並等待被轉發。由於此時數據分組數量較多，故排隊時延非常大。當發送發定時器超時後，便會重發該分組，最終網絡上會有多個相同的冗餘分組[2]。
2. 若該路由器的緩存空間有限，故多餘的數據分組會被這個路由器丟棄。之前存儲轉發該分組所消耗的傳輸容量被浪費掉了[2]。
3. 若端設備沒有擁塞處理機制，在經歷超時事件之後，會選擇以原來的速度重發該分組及其後內容。但是路由器的擁塞狀態沒有得到改善，新發來的分組仍然不能得到有效處理，反而造成了更多的冗餘數據。最終會陷入惡性循環。
2. 擁塞控制的基本思路
在討論具體的擁塞控制方法之前，先明確期望通過擁塞控制得到的結果。
擁塞是由於當前的網絡中存在過多的數據分組，超出了網絡設備的處理能力導致的。我們期望通過某種方法能夠控制用戶發送分組的速度，從而避免某一時刻在某一網絡設備中的數據分組過多，也就從根本上解決了擁塞的出現。如何告知用戶當前的網絡狀態則使得擁塞控制分成了兩個不同的方向。
顯式的通過網絡設備告知端設備控制發送速度。
當路由器發現當前網絡的流量大於某個閥值時，可以預判可能出現的擁塞，並通過顯式發送標誌信息告知端設備當前路由器狀態。端設備根據該信息控制發送速度，便可達到控制甚至避免擁塞的出現。隱式的通過丟包以及超時事件對發送速度進行控制。
顯式的通知需要網絡設備的配合，而路由器不一定都支持這個功能。隱式的擁塞控制則完全由端設備完成。由上面的分析可以發現，擁塞的出現會導致分組的丟包或者超時事件的發生。當端設備檢測到超時或者丟包事件標誌着當前的鏈路出現了擁塞。此時根據不同的事件控制發送速度即可達到擁塞控制的目的。本文主要討論隱式的擁塞控制。
3. 擁塞控制核心算法及思路
上文分析了擁塞的出現原因以及能從端設備檢測的特徵。本節主要依據這些特徵，描述擁塞控制算法的基本設計思路以及原因。
傳統的隱式擁塞控制主要有四種工具來降低擁塞出現的可能。這些方法所遵循的原則有兩條：響應並處理當前出現的問題與儘量避免同樣問題的出現
1. 當前網絡處於正常狀態
慢啓動
當一個新的TCP連接建立並開始傳輸分組的時候，並不知道當前的擁塞窗口的大小。我們期望傳輸速度能夠穩定在擁塞窗口，最大程度的利用網絡。但是由於選擇隱式的擁塞控制，端設備無法知道當前網絡狀態，需要嘗試才能知道擁塞窗口大致值。
慢啓動便是從一個較低的窗口大小開始增長並嘗試，在如Tahoe和Reno擁塞控制中，這個初始值設置爲1。但是線性增長嘗試非常浪費時間，快速增長到可能的擁塞窗口是一個比較明智的選。Tahoe和Reno選擇指數增長也是這個原因。
擁塞避免
當窗口增長到一個可能的擁塞窗口大小時，我們既希望能窗口大小夠維持在真實擁塞窗口附近以保證較高的利用率，但是又不能確定當前猜測的擁塞窗口就是真實的擁塞窗口，期望能夠繼續增長逼近真實的擁塞窗口。
擁塞避免則是用來處理這種情況的。當窗口增長到一個可能的擁塞窗口的大小時，放慢增長速度，並同時更新擁塞窗口。在Tahoe和Reno中選擇線性增長。而現在最主要的問題是這個可能的擁塞窗口是如何得出來的，以及如何去維護它。在出現擁塞之前，由於一直在嘗試當前窗口是否會導致擁塞，預估的擁塞窗口大小便隨着嘗試而增大。
2. 當出現重複ACK或者超時
在討論具體出現擁塞的兩個處理算法之前，先討論重複ACK或超時對擁塞控制系統意味着什麼以及需要怎麼處理這種情況。
正如上文所說，擁塞控制系統需要先響應並處理這個事件：一旦重複ACK或者超時出現，說明當前的鏈路出現了擁塞。發送方需要立即減小發送速度，防止擁塞惡化。然後擁塞控制系統需要避免當前的情況再次發生：其需要適當的減少可能的擁塞窗口，並再次從減小的窗口向可能的擁塞窗口增加，開始新的一輪試探。
出現丟包或超時對於發送方，有兩種可能的反饋，分別對應擁塞的兩種不同的狀態。
第一種情況是出現了多次重複的ACK。這說明網絡中丟失了分組，但是網絡情況還沒特別糟糕，因爲收到了其後的ACK代表着後面的分組能夠正常的傳輸到接收方。
另一種情況是發生了超時事件。這一種情況就比較令人擔憂了。因爲若不是傳輸的最後一個分組的情況下，沒有收到任何ACK代表着其後所有的分組均發生丟包或者極其嚴重的時延。這代表着當前的網絡狀態非常糟糕。
針對第一種情況，衍生出了快速重傳以及快速恢復算法，用來針對網絡擁塞還不是特別嚴重的情況。對於第二種情況，由於網絡狀況已經非常糟糕了，擁塞控制系統應選擇慢啓動的方法，重新從一個較小的窗口開始嘗試。
快速重傳
快速重傳是將第一種情況具體化了，不同算法可能選擇不同的事件作爲快速重傳的標誌。快速重傳不必等待定時器超時從而提高了信道利用率和吞吐率[3]。當觸發快速重傳時，代表着網絡已經出現了擁塞，但是還沒有那麼嚴重，需要適當的減少速度。Tahoe算法就選擇一視同仁，令其進行慢啓動。而Reno之後就稍微進行了優化，使用了快速恢復算法。
快速恢復
快速恢復算法則是針對第一種情況的適當優化。若當前網絡狀態還沒有那麼糟糕，無需從一個很低的窗口重新開始嘗試，而是選擇一個合適的窗口大小開始增長。Reno就選擇當前擁塞窗口的一半作爲嘗試的起點。
傳統的擁塞控制系統主要參考重複ACK和超時事件作爲擁塞事件的標記。但是除了這兩個因素，還有其他的因素可以用於觀測當前網絡狀態。
RTT作爲一次往返的時延，可以粗略觀測到當前擁塞程度的變化。可以通過機器學習訓練其根據RTT的大小自動調節流量大小。
對於一些特殊的站點，一天當中某一時刻訪問的流量是具有統計規律的。同樣可以通過機器學習訓練其依照這種規律來預測擁塞窗口，減少嘗試的開銷。
4. 擁塞控制面臨的問題
當今網絡日益複雜，擁塞控制面臨着很多需要解決的問題。
1) 異質性
當今的網絡是種各樣不同的子網絡構成，而每個子網絡包含不同的子拓撲，這就導致了不同的網絡包含不同的鏈路特性。從帶寬的角度來講，鏈路質量可能是非常慢速如移動網絡，或者是非常高速的鏈路如核心網絡，數量級從Kbps到Gbps。從時延的角度來講，場景的變化從本地網絡通信到衛星通信，數量級從毫秒到秒。這就導致了現實的網絡場景的多樣性，這種多樣性隨着網絡的快速發展，而變得越來越複雜[4]。傳統的擁塞控制沒有考慮不同網絡環境下的處理，導致其性能和效率可能會受損。
2) 公平性
公平性也是擁塞控制系統需要特別注意的一點。如沒有擁塞控制的UDP協議對於有擁塞控制的TCP協議，就是不公平的。而TCP協議中各個擁塞控制的算法也存在不公平的現象。如何在不同擁塞控制協議下保持公平性，是擁塞控制需要解決的一個問題。如果一個擁塞控制算法無法保證數據流的公平性，最終則會導致網絡流量的侵略性以及造成得此失彼的結果。
3) 無線網絡的擁塞控制
在傳統的擁塞控制中，重複ACK和超時往往是由於擁塞所導致的，而在無線網絡中，這種錯誤可能只是由於信號問題而非擁塞。這時無需降低發送窗口。對於擁塞控制系統來說，如何分清這種由於信號問題還是擁塞導致重複ACK或超時，是一個需要解決的問題。
5. 總結
擁塞控制從提出到今日已四十年有餘，但是仍然沒有提出完美的解決方案。這是由於網絡用戶日益增長的網絡需求與有限的網絡資源的基本矛盾所導致的。我們所期望最優的擁塞控制系統是在保證公平性前提下最高效率地利用網絡資源並避免丟包的發生。隨着人工智能的發展以及端設備計算能力的增加，未來的擁塞控制可能會向智能化的方向發展。
參考文獻
[1]. 孔金生, 任平英, “TCP網絡擁塞控制研究,” 計算機技術與發展, Volume 1, 2014, pp43-46
[2]. James F. Kurose, and Keith W. Ross, 計算機網絡-自頂向上方法與Internet特色(第六版), 機械工業出版社, Oct. 2016, pp.177-178
[3]. Kevin Fall, and Sally Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP,” ACM SIGCOMM Computer Communication Review, Volume 26 Issue 3, July. 1996, pp.5-21.
[4]. Welson, “TCP網絡擁塞控制的困境,” [EB/OL] http://wetest.qq.com/lab/view/246.html, Jan. 2017
