轉自：https://mp.weixin.qq.com/s/NIFandX8w-Cynnbl-f2Lwg
一、前言
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 所示。
圖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 是從上一次縮小擁塞窗口經過的時間，Wmax 是上一次發生擁塞時的窗口大小，
β是乘法減小因子。從函數中可以看出擁塞窗口的增長不再與 RTT 有關，而僅僅取決上次發生擁塞時的最大窗口和距離上次發生擁塞的時間間隔值。
Cubic 擁塞窗口增長曲線如下，凸曲線部分爲穩定增長階段，凹曲線部分爲最大帶寬探測階段。如圖 2 所示，在剛開始時，擁塞窗口增長很快，在接近 Wmax 口時，增長速度變的平緩，避免流量突增而導致丟包；在 Wmax 附近，擁塞窗口不再增加；之後開始緩慢地探測網絡最大吞吐量，保證穩定性（在 Wmax 附近容易出現擁塞），在遠離 Wmax 後，增大窗口增長的速度，保證了帶寬的利用率。
圖 2、TCP Cubic 擁塞窗口增長函數
當出現丟包時，將擁塞窗口進行乘法減小，再繼續開始上述增長過程。此方式可以使得擁塞窗口一直維持在 Wmax 附近，從而保證了帶寬的利用率。Cubic 的擁塞控制過程如圖 3 所示：
圖 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 由於不會填滿網絡緩衝區，時延一直處於較低狀態。
圖 4、Cubic 和 BBR RTT 對比
由於 BBR 算法不將丟包作爲擁塞信號，所以在丟包率較高的網絡中，BBR 依然有極高的吞吐量，如圖 5 所示，在 1% 丟包率的網絡環境下，Cubic 的吞吐量已經降低 90% 以上，而 BBR 的吞吐量幾乎沒有受到影響，當丟包率大於 15% 時，BBR 的吞吐量才大幅下降。
圖 5、Cubic 和 BBR 傳輸速率與丟包率關係對比
BBR 算法是反饋驅動的，有自主調節機制，不受 TCP 擁塞控制狀態機的控制，通過測量網絡容量來調整擁塞窗口，發送速率由自己掌控，而傳統的擁塞控制算法只負責計算擁塞窗口，而不管發送速率（pacing rate），怎麼發由 TCP 自己決定，這樣會在瓶頸帶寬附近因發送速率的激增導致數據包排隊或出現丟包。
經過測試，在高延時、高丟包率的環境下，BBR 相對於 Cubic 算法在傳輸速度上有較大的提升，具體的測試結果表 1 所示：
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.