本文為媒礦工廠翻譯的技術文章

原標題：The Ultimate Guide to Internet Congestion Control

原作者：Michael Schapira

原文鏈接：https://www.compiralabs.com/ultimate-guide-congestion-control

翻譯整理：馬文濤

01

PART

介紹

擁塞控制是一個復雜的話題，圍繞它人們已經進行了數十年的學術研究。事實上，直到今天，科學家們仍對它有著激烈的討論。這篇文章旨在向非專家解釋互聯網擁塞控制的核心概念和方法。當然，這個領域有更多深層的內容，可以參考原文中其他資源的鏈接供進一步閱讀。??

今天的互聯網是一個繁忙和擁擠的地方。有許多不同的服務和應用程序相互競爭以通過相同的網絡基礎設施發送它們的流量。有時，根本沒有足夠的空間供每個人使用。?

Internet 流量被分割為數據包，這些數據包是單獨的數據單元。當網絡帶寬不能支持互聯網流量的每一個數據包的傳輸時，網絡就會變得擁擠。這就像我們的高速公路在高峰時段被車輛堵塞一樣。?

當交通量上升到壓倒性的水平時，對擁塞控制的需求變得明顯。一個例子是在超級碗周日期間，每個人都同時在線觀看比賽。當網絡容量太有限而無法支持中等數量的流量時，也會發生這種情況，這種情況可能發生在帶寬受限的偏遠或農村地區。也就是說，需要永久的擁塞控制。因為我們都共享相同的網絡資源，需求往往遠遠超過供應，所以我們需要以合理的方式共享它們。

互聯網擁塞控制通過以有組織的方式在用戶之間共享帶寬，為這個擁擠的交通系統帶來了秩序。這樣，每個人都可以享受更好的體驗質量。?

02

PART

互聯網擁塞控制

什么是互聯網擁塞控制，它為什么重要？

擁塞控制就是控制每個流量源在任何給定時間點發送數據的速率。簡而言之，擁塞控制控制著如何在所有傳輸數據的人之間分配總網絡容量。我們需要擁塞控制來防止互聯網流量被阻塞和淹沒網絡。由于其復雜性和至關重要的意義，擁塞控制是通信網絡面臨的長期挑戰。?

擁塞控制與流量控制

在我們深入研究擁塞控制之前，這里有兩個有時會混淆的術語的快速解釋：擁塞控制和流量控制。

• 流量控制關注的是防止發送方用過多的流量淹沒接收方。這是一個相當簡單的問題。接收方可以簡單地告訴發送方它可以處理的流量速度，然后發送方相應地調整其發送速率。?

• 擁塞控制是為流量找到有效利用網絡的方法，并與競爭流量進行交互而不會壓倒網絡。網絡是動態的并且提供有限的可見性，讓發件人推斷正在發生的事情。正如您在本電子書中所見，這可能是一項極其復雜的工作。

互聯網的早期開始，流量控制就一直是一個問題，因為發送計算機的傳輸速度不能比接收者可以接收的速度更快。擁塞控制直到 1986 年才成為一個嚴重的問題，當時互聯網經歷了第一次“擁塞崩潰”。?

下圖顯示了連接到互聯網的用戶的增長。（是的，1969 年只有 4 個。） 1986 年，在線用戶只有 5,000 人時，帶寬突然供不應求。當勞倫斯伯克利實驗室 (LBL) 和加州大學伯克利分校之間的幾跳網絡路徑變得擁擠時，吞吐量從通常的 32 Kbps 下降到 40 bps（下降了 1000 倍！）。這是創建互聯網擁塞控制算法的歷史觸發器。

為什么我們需要擁塞控制

我們最喜歡的解釋互聯網擁塞控制的類比是通過管道泵送水，如下圖 2 所示。

如果水流不夠強勁，最終用戶需要很長時間才能裝滿浴缸。但是，如果水太多，可能會使管道緊張并導致泄漏。同樣，如果數據通過網絡傳輸的速度不夠快，最終用戶可能無法收到足夠的數據來享受良好的體驗質量 (QoE)。例如，如果有人正在觀看高清電影，他們需要大量數據才能獲得清晰銳利的畫面。?

如果過多的數據被泵入管材，管件可能無法來得及處理。它最終可能會泄漏數據，這種現象稱為數據包丟失，導致最終用戶因重復的視頻重新緩沖而感到沮喪。因此，發送數據太快也會導致 QoE 不佳。?

擁塞控制需要控制數據處在沒有發送足夠數據和發送太多數據之間。

擁塞控制不應與路由混淆，這是另一個基本的網絡挑戰。回到水管的比喻，雖然擁塞控制的任務是確保有效地使用管道，但路由負責確定水（數據）將流經的管道。Internet 路由算法確定數據流量將通過哪些路徑。在今天的互聯網中，與早期不同，擁塞控制和路由由單獨的算法獨立處理。

擁塞控制對體驗質量的重要性

QoE 是指數據消費者在使用互聯網時的滿意度。例如，在視頻流中，QoE 表現在：

• 您的流媒體視頻開始播放需要多長時間。
  

• 圖像質量，例如您是否可以欣賞高清或較低質量的電影，或者您是否在中途看到質量突然下降。
  

• 重新緩沖時間，這是您必須花費的時間來等待您的視頻恢復。（研究表明，人們看到緩沖時的圈圈的身體反應類似于他們觀看恐怖電影時的反應。）
  

• 延遲（“直播時間”）是指操作與其在屏幕上出現之間的時間延遲。這是實時體育廣播的一個關鍵問題，即使是幾秒鐘的延遲，也可能導致觀眾在看到進球之前聽到鄰近公寓的歡呼聲或在社交媒體上看到劇透。

擁塞控制是對此類服務的 QoE 影響最大的因素之一，而不僅僅是更快的互聯網連接。?

互聯網提供商可能會聲稱升級到 5G、光纖電纜或更高的帶寬將解決您的 QoE 問題。這些往往是空洞的承諾。根據華爾街日報報道的研究，即使是帶寬最高的訂戶通常也只有大約 36% 的時間接收高清視頻。當問題出在其他地方時，消費者可能會在大型互聯網套餐上浪費他們的錢。?

QoE 的真正問題通常是數據離開云或內容分發網絡 (CDN) 并到達最終用戶設備的“最后一英里”。數據傳輸中的不同問題往往在數據到達消費者家中很久之前就出現了。因此，通過增加帶寬來擴大家庭互聯網連接就像擴大狹窄管道的口。水不能更快地通過管道的其余部分如果只是管道的嘴更寬。?

如下圖 3 所示，CDN 通過使用位于世界各地的代理服務器網絡，大大提高了內容交付的速度和可靠性。CDN 服務器離最終消費者越近，內容到達消費者設備所需的時間就越少。然而，無論距離有多小，服務器和用戶仍然經常被數據必須穿越的具有挑戰性的網段隔開。值得注意的是，對于視頻會議等不可緩存的內容，CDN 根本沒有幫助。

這最后一英里通常是一段混亂的旅程，可能包括不同網絡（CDN、ISP、家庭）和網段（移動、有線、無線、家庭 WiFi）之間的多次傳輸。這段旅程的每一段都涉及可以從一個時刻到下一個時刻不斷變化的條件，這使得擁塞控制變得非常復雜。成功的擁塞控制必須同時滿足三個不同的目標，這三個目標可能相互矛盾。

03

PART

擁塞控制的三個目標

擁塞控制的三個目標是：?

• 充分利用網絡帶寬

• 將數據丟失和延遲降至最低

• 在所有連接中保持公平?

這三個目標之間存在明確的權衡。盡管您想充分利用網絡帶寬，但您不想過沖，因為這會導致數據丟失。您可以不惜一切代價優先考慮公平性，但這可能會導致您未充分利用網絡帶寬。

除非您解決這些目標中的每一個，否則您無法完全解決擁塞控制。這是更深入的解釋。?

想象一個簡單的場景，如下圖 4 所示，顯示了三個連接對：

通常，互聯網連接是雙向的。例如，Facebook 向最終用戶發送數據，但這些最終用戶也將數據發送回 Facebook。每個發送者也是接收者，反之亦然。為了簡化事情，我們假設在所有三個連接中，一個端點（發送方）正在向另一個端點（接收方）發送流量。具體來說：

Facebook 服務器（發送方 1）向 Facebook 用戶（接收方 1）發送流量

Netflix 服務器（發送方 2）將流量發送到 Netflix 視頻客戶端（接收方 2）

Zoom 視頻會議用戶（發送方 3）向不同的 Zoom 用戶（接收方 3）發送流量

假設三個發送方共享一個帶寬為 120 Mbps 的網絡鏈接，這意味著它可以每秒傳輸 120 兆位（120,000,000 位）數據。?三個連接應該使用什么數據傳輸速率？這正是擁塞控制算法必須確定的。以下是我們的三個擁塞控制目標影響算法結果的方式。

充分利用網絡帶寬

Internet 服務和應用程序通常希望以盡可能高的速率發送數據，因為這可以為用戶帶來更好的 QoE。因此，擁塞控制應該使應用程序能夠使用盡可能多的可用帶寬。?

在我們的示例中，我們的帶寬為 120 Mbps。該算法可以允許每個連接使用 10 Mbps，但這意味著它們一起僅使用可用 120 Mbps 中的 30 個。這留下了很多閑置帶寬未使用。這也意味著應用程序可能會被限制在比良好 QoE 所需的帶寬更低的帶寬上。因此，理想情況下，三個發送方應以 120 Mbps 的速率注入流量，從而充分利用鏈路。

將數據包丟失和延遲降至最低?

當數據包進入網絡的速度超過網絡支持的速度時，就會造成擁塞，而擁塞會導致數據包延遲或丟失。?
例如，想象一下，每個應用程序都以 60 Mbps 的恒定速率傳輸數據。它們的總傳輸速率為 3 x 60 = 180 Mbps，比網絡帶寬高 50%。?

這是個問題。網絡無法在所有數據包進入網絡后立即發送，因為實在是太多了。網絡在路由器 A 上存儲（緩沖）額外的數據包，直到它可以繼續發送它們。這會導致數據到達接收器的延遲，如果網絡中沒有足夠的空間來存儲數據，甚至可能導致數據被丟棄和丟失。?

在連接之間保持公平

最后一個要求是算法必須公平地對待所有發件人。當談到擁塞控制時，可能很難定義“公平”的一般含義。對于我們的簡單示例，我們將說“公平”意味著每個發送方都可以以相同的平均速率傳輸數據。如果 Facebook 可以以 80 Mbps 的速度發送數據，而 Netflix 和 Zoom 只能以 20 Mbps 的速度發送數據，那么這對 Netflix 和 Zoom 或使用這些應用程序的人來說并不公平。?

為了解決所有 3 個目標，我們可以說每個發送方應該以 40 Mbps 的速度傳輸數據。這似乎是完美的解決方案，它解決了所有 3 個要求：

?

• 充分利用網絡帶寬。總網絡使用率為 120 Mbps，這是容量的 100%，可確保不會浪費額外的帶寬。?

• 將數據包丟失和延遲降至最低。流量進入鏈路的速度不會超過網絡的處理速度，因此不會出現不必要的數據包延遲或數據包丟失。

• 在連接之間保持公平。每個發送方使用完全相同的帶寬份額。

它看似簡單。那么為什么擁塞控制是一個如此復雜的挑戰呢？這是因為互聯網流量的真實世界遠比我們簡單的例子復雜得多。

在現實世界的互聯網擁塞控制中，這些發件人中的每一個都獨立于其他人做出決定。這是在沒有太多關于網絡內條件的信息（例如鏈路容量）的情況下完成的，并且網絡條件在不斷變化。更重要的是，競爭網絡帶寬的連接可能遠遠不止三個，新連接意外進入網絡而其他連接突然離開。?

我們將在下一節中更詳細地討論這一點。?

04

PART

為什么

為什么互聯網擁塞控制如此具有挑戰性？提示：因為現實世界很復雜

擁塞控制是網絡研究和實踐中解決的最持久和最關鍵的問題之一。妨礙互聯網擁塞控制解決方案的主要問題都存在于具有挑戰性的“最后一英里”，其中：

• 隨著時間的推移，網絡狀況可能會發生巨大變化并迅速變化

• 傳送速率決策是分散的

• 流量發送者關于網絡狀況的信息非常有限

• 不同的連接爭奪網絡帶寬

• 共享同一網絡的 Internet 應用程序和服務具有不同且相互沖突的需求

高度可變的網絡條件

最后一英里網絡通常是復雜、多樣和動態的環境。不同的網段在大小、結構、丟失模式、網絡延遲、競爭水平等方面可能有所不同。把它想象成一大堆混亂的管道，其中一些又大又寬，而另一些則狹窄、漏水和扭曲。?

?

即使使用圖 4 中的簡單示例也可以說明網絡條件的多樣性。網絡屬性包括：?

• 網絡鏈路帶寬

• 數據包通過鏈接所花費的時間（也稱為鏈接延遲）

• 當鏈路容量耗盡時，RouterA用于存儲多余數據包的緩沖區大小

• RouterA緩存滿時丟棄報文的排隊策略

• 更多?

?

所有這些特性對擁塞控制有著顯著的影響。例如，如果網絡隊列或緩沖區很淺，那么即使是少量的帶寬過沖也會導致數據包丟失。但是，如果緩沖區很深，超出帶寬可能會導致數據包在網絡內聚合，以便在擁塞再次緩解時發送，從而導致長時間延遲。

此外，通過這些鏈路傳輸的數據量不斷變化。從一秒到下一秒，不同的交通量擠在同一段管道上。此外，一些鏈路本身可能會呈現出具有挑戰性的條件，例如易于丟失的移動網絡或衛星網絡。在這樣的網絡中，連接所經歷的數據包丟失可能根本不是由于擁塞，而是由于其他原因，例如物理介質或用戶移動性。網絡狀況的不確定性使得難以就當前的發送速率做出明智的決定。

?

發送速率決策是分散的?

目前，每個發送方就發送數據包時使用的速率做出自己的獨立決定。沒有中央機構監督這些決定，也沒有明顯的方式讓任何給定的發件人知道競爭發件人正在使用哪些速率，甚至有多少其他發件人在網絡帶寬上與之競爭。盡管我們希望利率決策能夠相互良好地互動，但沒有辦法確保這一點。?

?

關于傳輸成功和失敗的有限反饋

發送方對網絡本身的可見性非常有限，這一事實使問題更加復雜。除了非常特定的網絡環境（如數據中心）、互聯網網絡，特別是最后一英里網絡，不向發送方提供任何直接反饋。在最后一英里環境中，您將看到的唯一反饋是終端接收者和發送者之間的端點反饋。?

這很像試圖了解在看不見的水管網絡中發生了什么。您知道水已經離開了自來水公司的水庫，但您不知道在它通過不同的管道到達用戶的浴缸時會發生什么。可能會出現水管爆裂、水進入較小管道時流量過大或最終用戶家庭管道出現一系列泄漏的情況。這些中的任何一個都可能導致用戶無法注滿浴缸。也有可能是家里的其他人同時洗碗來分流水。?

通過 Internet 網絡發送流量在許多方面都是相似的。發送方不知道其數據在發送給用戶的途中發生了什么，只知道數據是否最終到達了用戶（有時他們甚至不知道）。如果數據在途中丟失或延遲，沒有人確切知道發生這種情況的原因。

?

連接之間的競爭?

當多個連接在同一個網絡上的互動，如在我們前面的例子，一個發送者的動態行為可以顯著影響其他發件人。在圖 4 中，我們展示了通過同一網絡連接的三對用戶。如果發送方 1 立即決定顯著提高其傳輸速率，這可能會導致擁塞，從而導致所有三個發送方的數據包丟失。或者，如果發送方的傳輸突然終止，網絡帶寬將立即釋放以供其他連接使用。發件人無法明確知道哪些其他發件人正在使用或已停止使用網絡，但盡管缺乏信息，但仍需要有效地采取行動。?

已經有許多擁塞控制解決方案，例如 TCP Cubic 和 BBR。任何新的擁塞控制解決方案都必須與其他解決方案共存，這些解決方案更加混亂，進一步增加了網絡環境的不確定性。任何新的擁塞控制算法仍然需要對使用不同擁塞控制解決方案的連接保持公平。使用對使用其他算法的連接過于激進的擁塞控制解決方案是不公平的（例如，BBR），并拖累它們的性能。

?

需求多樣且相互沖突的互聯網服務

在這種混亂的因素組合中，還有更多的問題需要考慮。Internet 服務和應用程序在帶寬和延遲方面可能有不同的要求。實時視頻流等服務；增強、虛擬或混合現實；和寬帶物聯網，都有不同的要求。有時，不可能同時滿足。

想想圖 4 中的第一個示例，其中 Facebook、Netflix 和 Zoom 都共享一個連接鏈接。每個應用程序都希望為其用戶提供“良好的 QoE”，但他們對“良好”的定義各不相同。

對于像 Netflix 這樣的點播視頻，擁有支持高清觀看的高帶寬至關重要，因此對于觀看者來說，畫面始終清晰銳利。如果視頻傳輸中存在較小的、持續的延遲，則不會給觀看者帶來不便。

Zoom 視頻會議首先需要低延遲，以防止不同人發言時出現時間延遲。即使是半秒的延遲也會導致參與者互相交談并錯過談話的重要部分。

Internet 應用程序的時間敏感性也有所不同。想象一下，您的智能手機在您播放電影時下載了軟件更新。顯然，電影是時間敏感的，在播放時應該給予更高的帶寬優先級。如果您的電影不會被中斷，不得不重新緩沖或以較低的清晰度而不是高清顯示，那么您會更喜歡讓軟件更新需要更長的時間。

應用程序需求的多樣性意味著網絡帶寬應該如何劃分并不總是很清楚。這可以用一個關于駱駝和斑馬一起穿越沙漠的寓言來解釋。他們的水量有限，所以公平地說，他們同意每個人喝相同的水量。當他們到達綠洲時，斑馬幾乎因脫水而倒下，但駱駝幾乎不需要水。就像斑馬和駱駝一樣，不同的互聯網服務有不同的需求，按照人為的“平等”標準對待它們有時是不可取的。

05

PART

介紹 TCP

傳輸控制協議 (TCP) 是一種流行的擁塞控制解決方案，其歷史可以追溯到互聯網的早期。它依靠數據包反饋來計算出最佳的數據傳輸速率。我們現在解釋 TCP 擁塞控制是如何工作的。

?

TCP 依賴于數據包反饋

在我們圖 4的示例中，每個發送方都傳輸數據包并接收有關數據包是否到達的反饋。該反饋采用確認 (ACK) 的形式，在接收到數據包時發送。?

盡管這種反饋非常有限，但發送者仍然可以通過檢查 ACK 來獲取有價值的信息，以跟蹤哪些數據包沒有被接收到以及數據穿越網絡需要多長時間。具體來說，當數據包經過足夠的時間但從未收到 ACK 時，可以推斷出數據包丟失。當接收到后續數據包的 ACKS 時，也可以推斷出丟失，但接收方沒有收到有關此數據包命運的消息。此外，可以通過檢查發送的數據包到達發送方所需的 ACK 時間來估計網絡延遲。從數據包傳輸到同一數據包返回 ACK 之間經過的時間稱為其往返時間 (RTT)。

?

TCP擁塞窗口

TCP 擁塞控制中的一個關鍵概念是擁塞窗口。擁塞窗口是在任何給定時間從發送方到接收方的途中（或“飛行中”）數據包的最大允許數量。一旦數據包到達接收方并且發送方收到 ACK，數據包就已經到達并且不再“在飛行中”。實際上，擁塞窗口指定了在任何給定時間可以“傳輸”的數據字節數，但為簡單起見，我們將根據數據包數來考慮它。

圖 5 下面說明了擁塞窗口的概念。假設擁塞窗口是 10 個數據包。如果發送方已經發送了 4 個數據包，它仍然可以在等待前 4 個到達目的地的同時再發送 6 個。但是，如果發送方發送了 10 個數據包，則在收到表示數據包已到達接收方的 ACK 之前，它無法發送另一個數據包。否則，發送方將超過可以傳輸的數據包數量。?

?

TCP 控制擁塞窗口的大小。擁塞窗口越大，同時到達接收方的數據包就越多；這意味著以更快的速度發送流量。TCP 擁塞控制就是隨時間調整擁塞窗口的大小。如果擁塞窗口過大，發送數據包的速率將超過網絡容量，導致數據包丟失和/或延遲。如果擁塞窗口太小，可能會發送流量太慢以獲得良好的體驗質量。

請注意，TCP 并未明確更改發送速率。換句話說，TCP 發送方不會以“將發送速率更改為 7 Mbps”的形式做出決定。相反，通過更改擁塞窗口來間接更改發送速率。例如，如果窗口大小為 100，每個數據包的大小為 4000 位，RTT 為 1 秒，那么平均而言，發送速率為 (100x4000)/1 = 400,000 bps = 0.4 Mbps。?稍后我們將在討論 TCP 擁塞控制的替代方案時重新討論這一點。

?

TCP 的工作原理：慢啟動和擁塞避免

TCP 開始時將擁塞窗口設置得非常小，并在每個 RTT 期間加倍。這個階段被稱為“慢啟動”。它會一直持續到 TCP 連接遇到困難，例如，以丟包的形式出現，或者當擁塞窗口超過某個閾值時。當慢啟動終止時，連接進入“擁塞避免”階段。在擁塞避免期間，擁塞窗口的大小在成功接收到 ACK 時增加，并在檢測到數據包丟失時減小。

圖 6 顯示了 TCP Reno 在前 20 秒的緩慢啟動，然后是擁塞避免。TCP Reno 是 1990 年提出的 TCP 的經典變體。假設使用 TCP Reno 的發送方單獨在鏈路上。當處于擁塞避免模式時，只要沒有數據包丟失并且發送數據包的 ACK 繼續到達發送方，發送方就會增加其擁塞窗口大小。每個接收到的 ACK 窗口大小的增加是適度的，以避免超出網絡容量。?

在某些時候，發送速率將超過鏈路容量，鏈路的緩沖區將達到飽和點，并且數據包將丟失。發生這種情況時，TCP Reno 會將擁塞窗口大小減半。這導致了 Reno 著名的“鋸齒”行為，如下所示。在這里，發送方達到鏈路容量，看到數據包丟失，然后在重新開始上升之前急劇下降。這種形式的行為，其中擁塞窗口在收到 ACK 時增加一個固定的加性因子，并在檢測到數據包丟失時減少一個倍增因子，稱為Additive-Increase-Multiplicative-Decrease（簡稱 AIMD）。如果 TCP Reno 一段時間沒有收到任何反饋，它也可以將流量速率拖回到緩慢的啟動狀態。?

多個發送方的 TCP 收斂和公平性

當多個 TCP 發送方共享相同的網絡帶寬時，它們必須不斷地對彼此的發送速率做出反應，而實際上并不知道這些速率是多少。

假設兩個發送方共享同一網絡鏈路，如下圖 7 所示，鏈路容量為 R Mbps。

理想情況下，兩個發送器隨著時間的推移平均共享帶寬，就像流過管道的兩股相等的水流一樣，而不是一條水流接管整個管道，不為其他水流留出空間。但這很難實現，尤其是在兩個發件人之間沒有直接協調的情況下。?

令人驚訝的是，TCP 在公平分配帶寬方面做得相當不錯。要了解原因，請查看下面的圖 8，其中連接 1 和連接 2 在容量為 R Mbps 的鏈路上發送流量。x 軸顯示連接 1 的發送速率，y 軸顯示連接 2 的發送速率。在圖表上的任何給定點，總發送速率為 x+y。該圖還顯示了“公平線”，代表兩個連接以相同速率發送的每種情況。?

公平線上的某些點顯然是不可取的。例如，當公平線大約為零時，發送速率非常低效并且遠低于鏈路的全部容量。在線路另一端的某個點，發送速率的總和變得過高并超過 R，導致數據包丟失。?

相比之下，在圖 9 中，虛線表示 x+y=R，涵蓋了兩個連接的組合發送速率與鏈路容量完全匹配的每種情況：鏈路被充分利用。

發送速率的理想組合是圖 8 中的線與圖 9 中的線相交的點。圖 10 顯示了 x=y=R/2 處的理想點，這將最大化公平性和帶寬利用率。

當多個流交互時，TCP 的鋸齒行為逐漸靠近公平帶寬分配線，如下圖 11 所示：?

圖 11 展示了以下場景中兩個發送方的聯合發送速率。從圖中可以看出，連接 1 的發送速率最初高于連接 2 的發送速率。隨著時間的推移，每個發送方以線性方式增加它們的速率，直到它們的聯合速率達到總鏈路容量的 R 線。在這一點上，他們都開始看到數據包丟失并將速率降低了一半。具有較高流量速率的發送方，即連接 1，因此比較慢的發送方降低其速率更多，導致兩個連接的發送速率比以前更接近彼此。這種線性增加隨后速率減半繼續進行，每次使兩個發送速率更接近，因此更好地接近公平結果。

這種發送者越來越接近公平線的行為，無論有多少發送者都適用；發送速率較快的發件人總是比速率較慢的發件人降低速率更多（因為速率快的一半多于慢速率的一半），從而使速率較慢的發件人最終趕上。?

?

各種各樣的 TCP 風格

?

到目前為止，我們以 TCP Reno 為例說明了 TCP，但 TCP 有許多不同的變體。其他類型的 TCP 也有慢啟動階段和擁塞避免階段；并響應于接收或未接收到 ACK 來調整擁塞窗口。TCP 變體之間的差異在于擁塞窗口的調整方式，通常集中在擁塞避免階段。

TCP Cubic

一個突出的例子是 TCP Cubic，它于 1998 年提出并在當今網絡中仍然是占主導地位的 TCP。Cubic 是許多操作系統的默認擁塞控制算法，特別是 Linux 操作系統。TCP Cubic 嘗試比 TCP Reno 更快地接管可用帶寬，同時仍然對其他 TCP 連接保持公平。與 TCP Reno 一樣，當在擁塞避免模式下檢測到數據包丟失時，Cubic 也將其擁塞窗口減半。?

主要區別在于 Cubic 如何在擁塞避免期間提高其速率。假設 TCP Cubic 發送方在其擁塞窗口大小為 W 時遇到數據包丟失，然后將其擁塞窗口減半。直觀上，Cubic 最初會急劇增加其擁塞窗口，然后隨著接近 W 逐漸減慢擁塞窗口的增長，這也是它之前遇到的問題。如果擁塞窗口超過 W 而沒有看到丟包，Cubic 會逐漸增加擁塞窗口的增長。這種先凹后凸的行為模仿了三次多項式的圖形，因此得名。圖 12 說明了由于數據包丟失而導致擁塞窗口減半后擁塞窗口的變化。

?

TCP Vegas

另一個有趣的 TCP 變體是 TCP Vegas。Vegas 對延遲敏感，不像 Reno 和 Cubic，后者完全基于損失。對于基于丟失的擁塞控制算法，分組 RTT 對增加或減少擁塞窗口的決定沒有影響。相比之下，當 Vegas 處于擁塞避免狀態時，它不僅會像基于丟失的 TCP 變體那樣在遇到丟包后減小窗口大小，還會在 RTT“太長”時減小窗口大小。Vegas 也只會在觀察到 RTT“足夠低”時才增加窗口大小。?

與 Reno 和 Cubic 不同， Vegas 會注意到增加的 RTT當數據包在網絡隊列中等待時。因此，當數據包開始在網絡內聚合時，它可以通過降低速率來保持低數據包延遲。雖然這在理論上聽起來不錯，但它也帶來了一個主要缺點。當 TCP Vegas 發送方在相同鏈路上與 TCP Reno 或 Cubic 發送方競爭時，前者總是為后者讓路。這是因為Vegas發送方在更早的階段就開始降低速率，從而使他們自己的網絡帶寬份額非常小。由于 Reno/Cubic 發送方沒有注意到 RTT 捕獲的數據包延遲的增加，因此它們會繼續全速發送，直到發現數據包丟失。

?

特定環境的 TCP 變體

某些 TCP 變體針對特定環境進行了優化，例如數據中心、WiFi 網絡和衛星網絡。例如，衛星數據傳輸的往返時間 (RTT) 可能是數百毫秒，這在互聯網術語中是很長的時間。高 RTT 意味著發送方可能需要很長時間才能收到有關數據包的任何反饋。最重要的是，衛星數據傳輸網絡經常會遇到不可忽略的、與擁塞無關的數據包丟失。標準 TCP 假設任何丟失都表示擁塞；但如果丟失與擁塞無關，發送方將無緣無故地降低流量速率。因此，一種不同形式的衛星 TCP，稱為 TCP Hybla，被發明來處理這些問題。?

WiFi 和移動網絡通常也會遇到非擁塞相關的損失，以及其他挑戰，例如由于信號強度或用戶移動性的變化而導致的帶寬頻繁變化。這鼓勵研究人員和從業人員針對這些特定環境定制解決方案。

相對大量的不同 TCP 變體表明了 TCP 的算法缺陷，這需要設計不同的點解決方案。盡管 TCP 在 Internet 上的表現令人欽佩，但它在許多實際環境中的性能卻是出了名的糟糕。?

我們現在將詳細說明 TCP 的缺點和可能的替代方案。

06

PART

TCP 不足之處

TCP 的硬連線響應并不總是有意義

每個 TCP 變體都有一個內置到解決方案中的硬連線響應。TCP 是一個嚴格的公式，它對數據包級別的事件產生固定的響應。例如，每當檢測到丟包時，TCP 以相同的方式響應，而沒有考慮不同的丟包原因可能需要不同的響應。通常，這涉及將發送速率減半，就像在 TCP Reno 和 Cubic 中所做的那樣。?

TCP 的回應反映了其基本假設。關于丟包的兩個強有力但隱含的假設是：

• 任何數據包丟失都是網絡擁塞的標志

• 發送方始終是擁塞的負責人

然而，正如我們在下面解釋的，這些假設在實踐中經常被推翻。

丟包的可能原因有很多，每個都需要不同的響應。即使是相同的連接也可能在不同的時間因不同的原因而丟失數據包。以下是一些可能的場景：

圖 13 顯示了對上述四種情況中每一種情況的最佳響應。

?

在許多情況下，硬連線 TCP 響應實際上與最有效的響應相反。例如，如果丟包與擁塞無關，則發送方應提高其發送速率，而不是將其減半。使 TCP 算法在擁塞控制方面效率低下的根本問題是，任何不考慮原因或上下文的對數據包丟失的硬連線響應都將無法提供高性能。

將流量減半的決定純屬武斷。為什么是一半而不是三分之二或四分之一？沒有真正的答案。

TCP 是一種尺寸，并不能適合所有的人

TCP 的另一個基本限制是您無法針對不同應用程序和網絡條件的需要對其進行自定義。?

無論您是在曼哈頓的智能電視上觀看 VoD，還是在巴塞羅那的移動設備上觀看現場體育賽事，TCP（默認為 Cubic）都將以完全相同的方式運行。它不能適應網絡上運行的不同互聯網應用和服務的具體要求，也不能根據網絡情況定制其速率調整規則。?

早些時候，我們舉了一個例子，有人在他們的移動設備上看電影，同時在后臺下載軟件更新。理想情況下，作為主要用戶的時間敏感電影應該優先于軟件下載，這被稱為清道夫。但是，如果兩個應用程序都使用 TCP Reno 或 TCP Cubic，則不會發生這種情況。正如我們在第 4 節中討論的，Reno 和 Cubic 將嘗試確保兩個連接（幾乎）平等地共享網絡帶寬。這可能會導致流視頻獲得的帶寬少于支持高清觀看所需的帶寬，而軟件更新下載的速度卻不必要地快。

不同的網絡表現出非常不同的特征。一些網絡可能有大量與擁塞無關的丟包，這可能是個人在巴塞羅那的移動網絡上觀看體育直播的情況。這是因為移動網絡連接不太穩定，網絡帶寬和隨后的丟失率經常變化。在其他網絡中，所有損失都可能與擁塞有關，曼哈頓智能電視上播放的電影可能就是這種情況。在某些網絡中，帶寬競爭可能非常激烈，而在其他網絡中，發送方可以有效地與其他連接隔離。在某些情況下，網絡緩沖區可能非常深，而在其他情況下，它們可能非常淺。

再次，使用 TCP，互聯網數據傳輸成為一種不太適合任何人的尺寸。它不是根據每個用戶、應用程序或網絡的需要進行定制的。為了解決這個問題，通過針對特定上下文定制硬連線響應，為特定網絡環境或特定應用設計了 TCP 的變體。然而，TCP 算法框架的局限性通常提供遠非最佳性能，即使在設計它們的環境中也是如此。

計算機科學家一直在探索克服這些基本問題的其他類型的擁塞控制算法。較新的非 TCP 擁塞控制算法，例如BBR和PCC，采用完全不同的方法。這些替代方案基于收集有意義的數據并使用它來確定最佳行動方案。

這些 TCP 的替代方案可以粗略地分為基于模型和無模型的方法。

07

PART

TCP 的替代方案

TCP 的基于模型與無模型的替代方案

如果您著手為最后一英里網絡等環境設計新的擁塞控制算法，則很難完全表征該算法將遇到的所有網絡條件。在這種情況下，擁塞控制算法設計者必須決定他們可以對網絡合理地假設什么，以及他們可以從他們的觀察中自信地推斷出哪些參數。?

TCP 的替代方案主要有兩種類型：基于模型的算法和無模型算法。它們之間的根本區別在于它們是否基于對網絡及其行為方式的假設。?

基于網絡模型的算法依賴于網絡環境的表示，即網絡模型。該模型基于假設和來自觀察到的網絡動態的推論。該算法使用該模型來預測網絡動態如何演變以及不同發送速率對性能的影響方式。?

無網絡模型算法將網絡視為無法準確建模的黑箱。在沒有任何預測基礎的情況下，無模型算法會觀察由不同發送速率產生的性能，并在經驗上尋找速率和性能之間的“良好”映射。

這兩種類型的算法具有不同的優勢。如果您確信自己的假設和推論是正確的，那么基于模型的算法將使您獲得比無模型算法的實驗方法快得多的有效發送速率。但是，如果您的假設是錯誤的，那么您會在嘗試為一個模糊的網絡找到最佳發送速率時遇到很多挫折。?

想象一下，在總帶寬為 100 Mbps 的鏈路上有一個單獨的連接。最佳發送速率為 100 Mbps。具有準確模型的基于模型的算法將從 100 Mbps 開始，因此幾乎立即達到最佳發送速率。但這只有在它有一個準確的模型時才會發生。如果模型不正確，因為帶寬如果是 200 Mbps 或者發送方不是單獨在鏈路上，該算法要么無法充分利用鏈路，要么發送流量過快并導致數據包丟失。相比之下，無模型方法可能會花費寶貴的時間來探索不同發送速率對性能的影響。但是，如果基于模型的方法有錯誤的模型，則無模型算法可能會優于基于模型的算法，因為它不需要糾正錯誤的現實模型。?

基于模型的方法非常適合可預測的網絡，在這種網絡中，可以從準確的網絡模型開始。其中一些示例是大型組織（如 Google、Facebook 和 Amazon）內的私有內部網。這些網絡穩定且行為良好；網絡的所有基礎設施都在集中控制之下。?

無模型方法最適合難以準確建模的復雜網絡環境，并且在動態條件下本質上更健壯。在互聯網的最后一英里，條件在不斷變化（正如我們上面所討論的），因此無模型算法通常更合適。?

我們將更深入地研究兩種擁塞控制選項。BBR 是原型白盒、基于模型的方法，最初由 Google 為其內部網絡開發。PCC 是黑盒、無模型方法的范例，并且是 Compira Labs 解決方案的基礎。?

08

PART

BBR

BBR - 基于模型的白盒擁塞控制方法

BBR是瓶頸帶寬和 RTT 的縮寫，是 TCP 最著名的替代方案之一。BBR 是一種擁塞控制算法，用于傳送 YouTube 流量。它也被 Netflix 和其他一些重要的參與者采用。

簡約之美

BBR 本質上是相當簡單的。這是算法的基本結構。?

想象一下，一個發送方正在向另一個通信端點發送數據。在沿途的某個地方，數據遇到瓶頸環節。盡管流量可能會穿越具有多個段和不同競爭的非常復雜的網絡，但對于 BBR 而言，重要的是路徑最窄點處的帶寬。我們不知道是什么導致了瓶頸；它可能是來自其他流量、低帶寬或多個其他問題的競爭加劇。BBR 通過將整個旅程歸結為瓶頸寬度的單個鏈接來對整個網絡進行建模。它探測網絡以推斷瓶頸帶寬，然后調整其發送速率以匹配該帶寬。我們將在下面解釋 BBR 如何做到這一點。

BBR如何運作？

為了確定瓶頸鏈路帶寬，BBR 會不斷檢查其相對于數據包到達接收器的速率的發送速率。考慮帶寬為 100 Mbps 的鏈路上單獨的發送方。現在，假設鏈路不擁塞。在這種情況下，數據包到達端點的速率應該與它們離開發送方的速率大致相同；這意味著 ACK 也會以大致相同的速率到達發送方。在我們的示例中，如果發送速率為 50 Mbps，則 ACK 也應以 50 Mbps 的速度到達。但是，如果發送速率超過帶寬并且鏈路飽和，流量將以與帶寬相同的速率到達接收器，因為這是鏈路可以支持的最快速率。ACK 也應該以大致相同的速率到達發送方，在我們的示例中為 100 Mbps。如果發送速率保持在帶寬之上，當數據包排隊等待交付時，隊列將開始形成。通過比較發送速率和 ACK 到達速率，BBR 可以判斷它的速率是否超過了鏈路帶寬，并估計該帶寬是多少。BBR 估計的瓶頸帶寬是 BBR 的最佳操作點。它在不超過帶寬的情況下充分利用鏈路，因此將丟失和延遲保持在最低限度。

要了解 BBR 如何選擇何時以及如何增加/降低其發送速率，讓我們繼續使用 100 Mbps 鏈路上的單個發送器的簡單示例。與 TCP 一樣，BBR 以慢啟動模式開始，每個 RTT 將其速率加倍。這一直持續到發送速率超過估計的瓶頸帶寬。當這種情況發生時，BBR 會降低其速率以匹配估計的帶寬并進入擁塞避免模式。BBR 會周期性地將其速率提高 25%，以檢查瓶頸帶寬是否發生了變化。如果接收速率同步上升，BBR 知道它可以以更高的速率繼續。如果接收速率沒有隨著發送速率的增加而上升，則數據包的發送速率顯然高于網絡可以支持的速率。這意味著緩沖區中有一行數據包在等待，這可能會導致數據包丟失或過度延遲。為了解決這個問題，BBR 通過將發送速率降低到低于之前標準的 25% 來定期排空隊列，因此可以發送緩沖的數據包而不會再堆積。如果我們在示例中繪制 BBR 發送方的發送速率圖，它看起來像這樣：

?

盡管我們的示例是針對由單個鏈接組成的網絡路徑，但 BBR 將整個路徑建模為單個鏈接，無論該路徑實際包含多少個鏈接。為此，BBR 在每種情況下都使用相同的過程來估計帶寬。當多個持久的 BBR 連接在同一鏈路上發送流量時，實驗表明它們通常都能獲得公平的帶寬份額。

BBR 與 TCP

BBR 與 TCP 的主要區別有兩點：

BBR 調整發送速率，而不是擁塞窗口。我們已經解釋過 TCP 改變的是擁塞窗口而不是實際的發送速率。對于 BBR，將決定以 Mbps 為單位的流量速度。

BBR 收集有意義的統計數據。與 TCP 不同，BBR 不規定對數據包級事件的硬連線反應。相反，它試圖推斷有關網絡的有意義的統計數據，主要是通過 ACK 接收速率，并以此為基礎來指導其速率選擇。

在大多數情況下，BBR 的性能優于廣泛使用的 TCP 變體，例如 TCP Cubic。通過明確針對瓶頸帶寬，BBR 實現了更好的吞吐量和更低的延遲。此外，BBR 天生對非擁塞相關的丟失更具彈性，因為與 TCP 不同，它不會將數據包丟失視為擁塞信號。?

也就是說，BBR 確實有缺點。

BBR 什么時候不合適？

BBR 依賴于其以易于處理且對決策有用的方式對網絡進行建模的能力，無論其復雜程度如何。毫不奇怪，這并不總是可能的，尤其是在混亂的最后一英里。?

盡管 BBR 似乎有一個很好的情況模型，但網絡仍然可以包含各種意外。競爭性交通流量突然進出；基礎路線可能會發生變化；不同的發送方可能會與采用不同擁塞控制算法的連接共享鏈路；用戶移動性可能導致意外丟包和帶寬波動等等。?

當 BBR 模型偏離現實太遠時，BBR 會做出不明智的決定。

另一個嚴重的缺點是 BBR 不是一個“公平”的擁塞控制解決方案。BBR 通常適用于使用相同協議的流量源。但是當 BBR 與其他流量控制協議對抗時，它的表現并不好。BBR 比其它流控制更加激進，從而接管所有有限的可用帶寬。

09

PART

PCC

PCC - 一種黑匣子，無模型方法

PCC，即性能導向擁塞控制的縮寫，由耶路撒冷希伯來大學和伊利諾伊大學厄巴納香檳分校 (UIUC)的研究人員共同開發。與 TCP 一樣，但與 BBR 不同的是，PCC 是擁塞控制算法的通用框架。所有 PCC 變體都是使用相同的效用函數和在線速率選擇的通用架構構建的，我們將在下面更詳細地討論。PCC 變體在效用函數的具體選擇和擁塞控制算法中內置的在線速率選擇方案方面有所不同。?

“無模型”的意義

正如我們所解釋的，BBR 是一種基于模型的白盒方法，它利用網絡統計信息來推斷網絡狀況。PCC 正好相反。它作為一個無法理解的黑匣子接近網絡。PCC 發送者從不嘗試推斷網絡參數，例如瓶頸帶寬或丟包的根本原因。?

相反，PCC 將數據傳輸視為一系列“微實驗”。在每個這樣的微實驗中，發送者量化當前發送速率的性能水平。它使用此信息隨時間調整其發送速率。?

PCC是如何工作的？

PCC 有兩個主要組成部分：?

• 效用函數
  

• 在線速率選擇算法?

?

效用函數，或效用框架，需要從所選擇的發送速率得到統計數據，并將其轉換成一個性能得分，或效用價值。此效用值表示以該速率發送所達到的性能水平。在線速率選擇算法針對先前選擇的發送速率觀察到的效用值決定下一次發送的速率。

PCC 效用框架：靈活性的優勢

當 PCC 發送方開始以特定速率發送數據包時，它會在 RTT 之后開始接收 ACK。這些 ACK 可以揭示信息，包括丟失的數據包比例、數據包延遲的上升或下降等。PCC 發送方收集這些信息并將其聚合為效用值或性能分數。?

讓我們考慮一個場景，在這個場景中，某個發送速率的性能被測量為安全到達目的地的流量比例。想象一個簡化的連接，發送方以 50 Mbps 的速度發送數據包，其中 30% 的數據包，或每 100 個發送的 30 個數據包在途中丟失；這意味著 70% 到達。當使用這個簡單的效用函數來量化性能時，派生的效用值等于 35，即 50 Mbps 的 70%。?

該效用函數可以用以下等式表示：

U = X(1-L)

?

其中：

• X 是發送速率

• L 是丟包的比例；例如，L=0 表示沒有丟包，L=0.1 表示丟了 10% 的包；L=0.5 表示有 50% 的數據包丟失；L=1 表示所有數據包丟失等。

• U 是性能分數?

?

例如，如果沒有數據包丟失，那么 X 和 U 是相同的，因為所有數據包都到達了目的地。如果有一半數據包丟失，則 U=X/2。?

效用函數的這種特定選擇過于簡單而無法發揮作用。原因如下：

• 如果您以 100 Mbps 的速度發送而沒有任何數據包丟失，則 U 將等于 100。?

• 如果您以 200 Mbps 的速率發送并看到 50% 的數據包丟失，則 U 仍等于 100。?

U 在這兩種情況下都是相同的，即使沒有數據包丟失顯然比丟失一半的數據包要好 - 沒有在吞吐量方面獲得任何好處。?

本例中的效用函數完全忽略了延遲。它只會對網絡緩沖區耗盡并且數據包被丟棄時的擁塞做出反應，而不是對擁塞的開始做出反應。因此，我們可以通過設置數據包延遲和數據包丟失的懲罰來創建更好的效用函數，以產生所需的屬性。包延遲的懲罰表示為?p_D，丟包的懲罰表示為 p_L?。此類效用函數具有以下一般形式：

U = X – p_D?X – p_L?X

和以前一樣，X 是發送速率，L 是丟失數據包的比例，U 是性能分數。隨著延遲和丟失的增加，對數據包延遲和數據包丟失的懲罰應該增加。因此，p_D?和 p_L?可以采用多種不同的形式。例如，當設置 p_L?=100L 時，丟包對發送方效用值的負面影響比設置 p_L?=L 時高 100 倍。觀察到，當我們設置 p_D?= 0 時，對數據包延遲沒有懲罰，并且 p_L?= L，我們得到

U = X - L *?X = X(1-L)

這正是我們之前的簡單效用函數。

現在該等式包括三個需要考慮的因素：

• 發送速率 (X)，我們希望盡可能地推高

• 數據包延遲（受?p_D?懲罰），我們希望保持盡可能低

• 丟包率（受到?p_L?的懲罰），我們也希望將其保持在盡可能低的水平

確定效用函數的好選擇可能很微妙，因為效用函數有兩個重要作用：

1. 為不同應用程序定制性能的靈活性

正如我們上面提到的，不同的應用程序有不同的需求。其中一些對延遲敏感，例如 Zoom，而另一些則需要帶寬，例如 Netflix。可以調整實用功能以匹配每個應用程序的需求。例如，當使用 PCC 進行 Zoom 時，我們可以將數據包延遲的懲罰設置為高于使用 PCC 進行 Netflix 時的懲罰。這將導致更傾向于最小化延遲的行為，正如 Zoom 所青睞的那樣，即使這是以降低帶寬利用率為代價的，而帶寬對 Netflix 來說更為重要。?

2. 確保連接之間的公平性

我們已經討論了公平性對于擁塞控制解決方案的重要性。使用 PCC，每個發送方都專注于根據其效用函數優化自己的發送速率。因此，存在一個發件人可能會壟斷所有帶寬而導致其他連接匱乏的風險。它們達到公平均衡的原因取決于博弈論。只要 PCC 用戶是同類的，并且都使用某個家族的效用函數，就可以保證他們公平地共享帶寬。在其他重要場景中也可以保證理想的帶寬分配。

例如，這可以實現通過將一類效用函數用于主要的、時間敏感的流量（例如視頻會議），以及另一類用于“清道夫”流量（例如軟件更新）。

PCC 在線速率選擇

在效用函數之后，PCC 的第二個組成部分是在線速率選擇算法。PCC 發送者需要根據它觀察到的先前選擇的速率的效用值來決定接下來要使用的發送速率。這就是PCC的在線速率選擇算法的作用。

這是它的工作原理。就像 TCP 和 BBR 一樣，PCC 以慢啟動模式開始，并在每個 RTT 中加倍速率。這一直持續到效用分數停止上升；這表明 PCC 將速率提高了太多，從而導致性能下降。此時，PCC 進入擁塞避免模式。

現在，假設 PCC 以特定速率 r 發送。確定它是否應該增加或減少其速率的簡單方法如下。PCC 可以以略高于 r 的2% 的速率發送并檢查派生的效用值，然后以略低于 r 的 2% 的速率發送，并再次檢查派生的效用。在評估以更高和更低的速率發送如何影響性能（即效用值）之后，PCC 可以切換到更低或更高的速率，這取決于哪個產生了最高的性能分數。

不需要逆向工程

這種調整發送速率的算法的 PCC 的最早變體被稱為PCCAllegro. 雖然很簡單，但它避免了 TCP 的一些不足。考慮發送方遇到與擁塞無關的數據包丟失的情況。例如，假設每 100 個數據包中有 1 個被丟棄，無論您發送數據的速度有多快。在這里，提高發送速率不會增加丟失數據包的比例，但會導致更多數據包到達接收器并獲得更好的性能分數。因此，PCC Allegro 將選擇提高其發送速率。相反，如果發送方由于擁塞而遇到丟包，那么提高速率只會導致更多的丟包，而不會獲得更多流量，從而導致性能下降。所以這時，PCC Allegro 將因此選擇降低其發送速率。回想一下，無論丟包的原因如何，TCP 都會降低其發送速率， ?

與 BBR 不同，PCC 算法不會嘗試確定為什么較高的速率比較低的速率更好，反之亦然。發送方不會嘗試對網絡條件進行逆向工程，例如通過明確推理經歷的數據包丟失的可能原因。相反，發送方將網絡視為一個黑匣子，只是試圖了解其當前速率的哪些變化將帶來最佳性能。?

?

對 PCC Allegro 的改進

盡管 PCC Allegro 的簡單算法是有效的，但它仍然存在一些缺點。主要的困難在于它總是以固定的步長改變其速率。在我們的示例中，這是 2%。正如我們將在下面討論的，在某些情況下，這個步長會太大，而在其他情況下它會太小。?

例如，下面的圖 15 顯示了一種 PCC 算法，該算法以 1% 的小步長降低發送速率。假設發送方最初以 r 的速率發送，該速率遠高于網絡帶寬 R。由于發送速率明顯高于網絡所能支持的速率，因此會出現大量丟包和/或包延遲. 這些損失和延遲將繼續，而速率以微小的增量緩慢下降，直到再次達到帶寬閾值。或者，如果當前發送速率遠低于可用帶寬，則每次將發送速率提高 1% 可能需要很長時間才能達到合適的帶寬利用率。

另一方面，圖 16 顯示了如果步長固定在太高的值（如 30%）會發生什么。首先考慮圖 16(a) 中描述的場景，其中連接以 r1 的速率在鏈路上發送，該速率遠低于可用帶寬 R。這會導致網絡利用率低下，因此 PCC 算法將提高其速率。由于步長很大，發送方將在一次巨大的跳躍中提高其速率，并且很可能大大超過網絡容量，如圖所示。然后，為了從這個錯誤中恢復過來，它會將其速率降低到過低，如圖 16(b) 所示，然后再次增加，依此類推。

更先進的 PCC 速率控制方案建立在機器學習和博弈論的豐富文獻基礎之上，以解決這個問題。PCC Vivace 是一種比 PCC Allegro 更能響應網絡變化并具有更好收斂速度的方案的例子。?

無模型方法的好處

正如我們上面所討論的，依賴于對網絡的強假設的擁塞控制解決方案，如 TCP 和 BBR，當他們的網絡模型偏離現實時，很容易導致性能不佳。由于其無模型方法避免了任何假設，PCC 在響應網絡條件的意外變化方面更加穩健。這些變化是現實世界環境中的情況，尤其是在最后一英里。?

在一個簡單的對照實驗中，我們比較了 BBR 和 PCC 在反映混亂最后一英里不可預測變化的情況下。我們的延遲、可用帶寬和數據包丟失每秒都在變化。下圖顯示了對 PCC 和 BBR 的影響，以及理想的帶寬利用率。

在圖表上：

• 虛線表示充分利用可用帶寬而不會造成丟包和延遲的最佳發送速率

• 點劃線表示 PCC

• 實線顯示 BBR

由于網絡的混亂性質，您可以看到 PCC 和 BBR 性能之間的差距。PCC 比 BBR 率更接近地反映了最佳線的波峰和波谷。

10

PART

結論：擁塞控制的未來

正如您現在所了解的，擁塞控制幾十年來一直是一項挑戰。試圖解決這個問題的計算機科學家需要克服許多障礙，包括模糊的、不斷變化的最后一英里條件；來自其他連接的持續競爭；需要以最小的數據包丟失和延遲來平衡帶寬利用率；以及在連接之間保持公平的要求等等。

對于互聯網數據傳輸來說，這是一個激動人心的時刻，新的解決方案觸手可及。很長一段時間以來，TCP 范式第一次受到質疑，并且其他方案——例如 BBR 和 PCC——已經被部署。隨著我們的生活越來越多地需要網絡，對高質量和公平網絡訪問的需求只會增長。我們已經看到企業和消費者對流媒體視頻、視頻會議、電子競技、在線實時宗教服務等應用程序的需求不斷增加。今天，我們需要更有效的方法來提高互聯網體驗質量。擁塞控制是服務提供商要考慮的關鍵因素。?

---

講師招募

LiveVideoStackCon 2022 音視頻技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎通過?speaker@livevideostack.com?提交個人資料及議題描述，我們將會在24小時內給予反饋。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的互联网拥塞控制终极指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。