淺談TCP擁塞控制算法

 TCP經過維護一個擁塞窗口來進行擁塞控制，擁塞控制的原則是，只要網絡中沒有出現擁塞，擁塞窗口的值就能夠再增大一些，以便把更多的數據包發送出去，但只要網絡出現擁塞，擁塞窗口的值就應該減少一些，以減小注入到網絡中的數據包數。

TCP擁塞控制算法發展的過程當中出現了以下幾種不一樣的思路：

• 基於丟包的擁塞控制：將丟包視爲出現擁塞，採起緩慢探測的方式，逐漸增大擁塞窗口，當出現丟包時，將擁塞窗口減少，如Reno、Cubic等。
• 基於時延的擁塞控制：將時延增長視爲出現擁塞，延時增長時增大擁塞窗口，延時減少時減少擁塞窗口，如Vegas、FastTCP等。
• 基於鏈路容量的擁塞控制：實時測量網絡帶寬和時延，認爲網絡上報文總量大於帶寬時延乘積時出現了擁塞，如BBR。
• 基於學習的擁塞控制：沒有特定的擁塞信號，而是藉助評價函數，基於訓練數據，使用機器學習的方法造成一個控制策略，如Remy。

擁塞控制算法的核心是選擇一個有效的策略來控制擁塞窗口的變化，下面介紹幾種經典的擁塞控制算法。

 

Vegas

Vegas^[1]將時延RTT的增長做爲網絡出現擁塞的信號，RTT增長，擁塞窗口減少，RTT減少，擁塞窗口增長。具體來講，Vegas經過比較實際吞吐量和指望吞吐量來調節擁塞窗口的大小，指望吞吐量：Expected  = cwnd /  BaseRTT，實際吞吐量：Actual = cwnd / RTT，diff = (Expected-Actual) * BaseRTT，BaseRTT是全部觀測來回響應時間的最小值，通常是創建鏈接後所發的第一個數據包的RTT，cwnd是目前的擁塞窗口的大小。Vegas定義了兩個閾值a，b，當diff > b時，擁塞窗口減少，當a <= diff <=b時，擁塞窗口不變，當diff < a時，擁塞窗口增長。

Vegas算法採用RTT的改變來判斷網絡的可用帶寬，能精確地測量網絡的可用帶寬，效率比較好。可是，網絡中Vegas與其它算法共存的狀況下，基於丟包的擁塞控制算法會嘗試填滿網絡中的緩衝區，致使Vegas計算的RTT增大，進而下降擁塞窗口，使得傳輸速度愈來愈慢，所以Vegas未能在Internet上廣泛採用。

適用場景：適用於網絡中只存在Vegas一種擁塞控制算法，競爭公平的狀況。

 

Reno

Reno^[2]將擁塞控制的過程分爲四個階段：慢啓動、擁塞避免、快重傳和快恢復，是現有的衆多擁塞控制算法的基礎，下面詳細說明這幾個階段。

慢啓動階段，在沒有出現丟包時每收到一個ACK就將擁塞窗口大小加一（單位是MSS，最大單個報文段長度），每輪次發送窗口增長一倍，呈指數增加，若出現丟包，則將擁塞窗口減半，進入擁塞避免階段；當窗口達到慢啓動閾值或出現丟包時，進入擁塞避免階段，窗口每輪次加一，呈線性增加；當收到對一個報文的三個重複的ACK時，認爲這個報文的下一個報文丟失了，進入快重傳階段，當即重傳丟失的報文，而不是等待超時重傳；快重傳完成後進入快恢復階段，將慢啓動閾值修改成當前擁塞窗口值的一半，同時擁塞窗口值等於慢啓動閾值，而後進入擁塞避免階段，重複上訴過程。Reno擁塞控制過程如圖1所示。

                           圖一、TCP Reno 擁塞控制過程

Reno算法將收到ACK這一信號做爲擁塞窗口增加的依據，在早期低帶寬、低時延的網絡中可以很好的發揮做用，可是隨着網絡帶寬和延時的增長，Reno的缺點就漸漸體現出來了，發送端從發送報文到收到ACK經歷一個RTT，在高帶寬延時（High Bandwidth-Delay Product，BDP）網絡中，RTT很大，致使擁塞窗口增加很慢，傳輸速度須要通過很長時間才能達到最大帶寬，致使帶寬利用率將低。

適用場景：適用於低延時、低帶寬的網絡。

 

Cubic

Cubic^[3]是Linux內核2.6以後的默認TCP擁塞控制算法，使用一個立方函數（cubic function）做爲擁塞窗口的增加函數，其中，C是調節因子，t是從上一次縮小擁塞窗口通過的時間，W_max是上一次發生擁塞時的窗口大小，，β是乘法減少因子。從函數中能夠看出擁塞窗口的增加再也不與RTT有關，而僅僅取決上次發生擁塞時的最大窗口和距離上次發生擁塞的時間間隔值。

Cubic擁塞窗口增加曲線以下，凸曲線部分爲穩定增加階段，凹曲線部分爲最大帶寬探測階段。如圖2所示，在剛開始時，擁塞窗口增加很快，在接近W_max口時，增加速度變的平緩，避免流量突增而致使丟包；在W_max附近，擁塞窗口再也不增長；以後開始緩慢地探測網絡最大吞吐量，保證穩定性（在W_max附近容易出現擁塞），在遠離W_max後，增大窗口增加的速度，保證了帶寬的利用率。

                         圖二、TCP Cubic 擁塞窗口增加函數

當出現丟包時，將擁塞窗口進行乘法減少，再繼續開始上述增加過程。此方式可使得擁塞窗口一直維持在Wmax附近，從而保證了帶寬的利用率。Cubic的擁塞控制過程如圖3所示：

圖三、TCP Cubic擁塞控制過程

Cubic算法的優勢在於只要沒有出現丟包，就不會主動下降本身的發送速度，能夠最大程度的利用網絡剩餘帶寬，提升吞吐量，在高帶寬、低丟包率的網絡中能夠發揮較好的性能。

可是，Cubic同以前的擁塞控制算法同樣，沒法區分擁塞丟包和傳輸錯誤丟包，只要發現丟包，就會減少擁塞窗口，下降發送速率，而事實上傳輸錯誤丟包時網絡不必定發生了擁塞，可是傳輸錯誤丟包的機率很低，因此對Cubic算法的性能影響不是很大。

Cubic算法的另外一個不足之處是過於激進，在沒有出現丟包時會不停地增長擁塞窗口的大小，向網絡注入流量，將網絡設備的緩衝區填滿，出現Bufferbloat（緩衝區膨脹）。因爲緩衝區長期趨於飽和狀態，新進入網絡的的數據包會在緩衝區裏排隊，增長無謂的排隊時延，緩衝區越大，時延就越高。另外Cubic算法在高帶寬利用率的同時依然在增長擁塞窗口，間接增長了丟包率，形成網絡抖動加重。

適用場景：適用於高帶寬、低丟包率網絡，可以有效利用帶寬。

 

BBR

BBR^[4]是谷歌在2016年提出的一種新的擁塞控制算法，已經在Youtube服務器和谷歌跨數據中心廣域網上部署，據Youtube官方數據稱，部署BBR後，在全球範圍內訪問Youtube的延遲下降了53%，在時延較高的發展中國家，延遲下降了80%。目前BBR已經集成到Linux 4.9以上版本的內核中。

BBR算法不將出現丟包或時延增長做爲擁塞的信號，而是認爲當網絡上的數據包總量大於瓶頸鍊路帶寬和時延的乘積時纔出現了擁塞，因此BBR也稱爲基於擁塞的擁塞控制算法（Congestion-Based Congestion Control）。BBR算法週期性地探測網絡的容量，交替測量一段時間內的帶寬極大值和時延極小值，將其乘積做爲做爲擁塞窗口大小（交替測量的緣由是極大帶寬和極小時延不可能同時獲得，帶寬極大時網絡被填滿形成排隊，時延必然極大，時延極小時須要數據包不被排隊直接轉發，帶寬必然極小），使得擁塞窗口始的值始終與網絡的容量保持一致。

因爲BBR的擁塞窗口是精確測量出來的，不會無限的增長擁塞窗口，也就不會將網絡設備的緩衝區填滿，避免了出現Bufferbloat問題，使得時延大大下降。如圖4所示，網絡緩衝區被填滿時時延爲250ms，Cubic算法會繼續增長擁塞窗口，使得時延持續增長到500ms並出現丟包，整個過程Cubic一直處於高時延狀態，而BBR因爲不會填滿網絡緩衝區，時延一直處於較低狀態。

圖四、Cubic和BBR RTT對比

因爲BBR算法不將丟包做爲擁塞信號，因此在丟包率較高的網絡中，BBR依然有極高的吞吐量，如圖5所示，在1%丟包率的網絡環境下，Cubic的吞吐量已經下降90%以上，而BBR的吞吐量幾乎沒有受到影響，當丟包率大於15%時，BBR的吞吐量才大幅降低。

圖五、Cubic和BBR傳輸速率與丟包率關係對比

BBR算法是反饋驅動的，有自主調節機制，不受TCP擁塞控制狀態機的控制，經過測量網絡容量來調整擁塞窗口，發送速率由本身掌控，而傳統的擁塞控制算法只負責計算擁塞窗口，而無論發送速率（pacing rate），怎麼發由TCP本身決定，這樣會在瓶頸帶寬附近因發送速率的激增致使數據包排隊或出現丟包。

通過測試，在高延時、高丟包率的環境下，BBR相對於Cubic算法在傳輸速度上有較大的提高，具體的測試結果表1所示：

表1 200ms延時下Cubic與BBR傳輸速度對比

BBR算法的不足之處在於設備隊列緩存較大時，BBR可能會競爭不過Cubic等比較激進算法，緣由是BBR不主動去佔據隊列緩存，若是Cubic的流量長期佔據隊列緩存，會使得BBR在多個週期內測量的極小RTT增大，進而使BBR的帶寬減少。

適用場景：適用於高帶寬、高時延、有必定丟包率的長肥網絡，能夠有效下降傳輸時延，並保證較高的吞吐量。

 

Remy

Remy^[5]也稱爲計算機生成的擁塞控制算法（computer-generated congestion-control algorithm），採用機器學習的方式生成擁塞控制算法模型。經過輸入各類參數模型（如瓶頸鍊路速率、時延、瓶頸鍊路上的發送者數量等），使用一個目標函數定量判斷算法的優劣程度，在生成算法的過程當中，針對不一樣的網絡狀態採用不一樣的方式調整擁塞窗口，反覆修改調節方式，直到目標函數最優，最終會生成一個網絡狀態到調節方式的映射表，在真實的網絡中，根據特定的網絡環境從映射表直接選取擁塞窗口的調節方式。

Remy試圖屏蔽底層網絡環境的差別，採用一個通用的擁塞控制算法模型來處理不一樣的網絡環境。這種方式比較依賴輸入的訓練集（歷史網絡模型），若是訓練集可以全面覆蓋全部可能出現的網絡環境及擁塞調節算法，Remy算法在應用到真實的網絡環境中時可以表現的很好，可是若是真實網絡與訓練網絡差別較大，Remy算法的性能會比較差。

適用場景：網絡環境爲複雜的異構網絡，但願計算機可以針對不一樣網絡場景自動選擇合適的擁塞控制方式，要求現有的網絡模型可以覆蓋全部可能出現狀況。

 

總結

每一種擁塞控制算法都是在必定的網絡環境下誕生的，適合特定的場景，沒有一種一勞永逸的算法。網絡環境愈來愈複雜，擁塞控制算法也在不斷地演進。本文不是要去選擇一個最好的算法，只是簡單介紹了幾種典型算法的設計思路、優缺點以及適用場景，但願能給你們帶來一些啓發。

 

參考論文

[1] S.O. L. Brakmo and L. Peterson. TCP Vegas: New techniques for congestiondetection and avoidance. In SIGCOMM, 1994. Proceedings. 1994 InternationalConference on. ACM, 1994.

[2] V.Jacobson, 「Congestion avoidance and control,」 in ACM SIGCOMM ComputerCommunication Review, vol. 18. ACM, 1988, pp. 314–329.

[3] L. X. I. R. Sangtae Ha. Cubic: A new TCP -friendlyhigh-speed TCP variant. In SIGOPS-OSR, July 2008. ACM, 2008.

[4] C.S. G. S. H. Y. Neal Cardwell, Yuchung Cheng and V. Jacobson. BBR:congestion-based congestion control. ACM Queue, 14(5):20{53, 2016.

[5] K.Winstein and H. Balakrishnan. TCP Ex Machina: Computer-generated Congestion Control.In Proceedings of the ACM SIGCOMM 2013 Conference, 2013.