本文為媒礦工廠翻譯的技術(shù)文章

原標(biāo)題：The Ultimate Guide to Internet Congestion Control

原作者：Michael Schapira

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

翻譯整理：馬文濤

01

PART

介紹

擁塞控制是一個(gè)復(fù)雜的話題，圍繞它人們已經(jīng)進(jìn)行了數(shù)十年的學(xué)術(shù)研究。事實(shí)上，直到今天，科學(xué)家們?nèi)詫?duì)它有著激烈的討論。這篇文章旨在向非專家解釋互聯(lián)網(wǎng)擁塞控制的核心概念和方法。當(dāng)然，這個(gè)領(lǐng)域有更多深層的內(nèi)容，可以參考原文中其他資源的鏈接供進(jìn)一步閱讀。??

今天的互聯(lián)網(wǎng)是一個(gè)繁忙和擁擠的地方。有許多不同的服務(wù)和應(yīng)用程序相互競(jìng)爭(zhēng)以通過相同的網(wǎng)絡(luò)基礎(chǔ)設(shè)施發(fā)送它們的流量。有時(shí)，根本沒有足夠的空間供每個(gè)人使用。?

Internet 流量被分割為數(shù)據(jù)包，這些數(shù)據(jù)包是單獨(dú)的數(shù)據(jù)單元。當(dāng)網(wǎng)絡(luò)帶寬不能支持互聯(lián)網(wǎng)流量的每一個(gè)數(shù)據(jù)包的傳輸時(shí)，網(wǎng)絡(luò)就會(huì)變得擁擠。這就像我們的高速公路在高峰時(shí)段被車輛堵塞一樣。?

當(dāng)交通量上升到壓倒性的水平時(shí)，對(duì)擁塞控制的需求變得明顯。一個(gè)例子是在超級(jí)碗周日期間，每個(gè)人都同時(shí)在線觀看比賽。當(dāng)網(wǎng)絡(luò)容量太有限而無(wú)法支持中等數(shù)量的流量時(shí)，也會(huì)發(fā)生這種情況，這種情況可能發(fā)生在帶寬受限的偏遠(yuǎn)或農(nóng)村地區(qū)。也就是說，需要永久的擁塞控制。因?yàn)槲覀兌脊蚕硐嗤木W(wǎng)絡(luò)資源，需求往往遠(yuǎn)遠(yuǎn)超過供應(yīng)，所以我們需要以合理的方式共享它們。

互聯(lián)網(wǎng)擁塞控制通過以有組織的方式在用戶之間共享帶寬，為這個(gè)擁擠的交通系統(tǒng)帶來(lái)了秩序。這樣，每個(gè)人都可以享受更好的體驗(yàn)質(zhì)量。?

02

PART

互聯(lián)網(wǎng)擁塞控制

什么是互聯(lián)網(wǎng)擁塞控制，它為什么重要？

擁塞控制就是控制每個(gè)流量源在任何給定時(shí)間點(diǎn)發(fā)送數(shù)據(jù)的速率。簡(jiǎn)而言之，擁塞控制控制著如何在所有傳輸數(shù)據(jù)的人之間分配總網(wǎng)絡(luò)容量。我們需要擁塞控制來(lái)防止互聯(lián)網(wǎng)流量被阻塞和淹沒網(wǎng)絡(luò)。由于其復(fù)雜性和至關(guān)重要的意義，擁塞控制是通信網(wǎng)絡(luò)面臨的長(zhǎng)期挑戰(zhàn)。?

擁塞控制與流量控制

在我們深入研究擁塞控制之前，這里有兩個(gè)有時(shí)會(huì)混淆的術(shù)語(yǔ)的快速解釋：擁塞控制和流量控制。

• 流量控制關(guān)注的是防止發(fā)送方用過多的流量淹沒接收方。這是一個(gè)相當(dāng)簡(jiǎn)單的問題。接收方可以簡(jiǎn)單地告訴發(fā)送方它可以處理的流量速度，然后發(fā)送方相應(yīng)地調(diào)整其發(fā)送速率。?

• 擁塞控制是為流量找到有效利用網(wǎng)絡(luò)的方法，并與競(jìng)爭(zhēng)流量進(jìn)行交互而不會(huì)壓倒網(wǎng)絡(luò)。網(wǎng)絡(luò)是動(dòng)態(tài)的并且提供有限的可見性，讓發(fā)件人推斷正在發(fā)生的事情。正如您在本電子書中所見，這可能是一項(xiàng)極其復(fù)雜的工作。

互聯(lián)網(wǎng)的早期開始，流量控制就一直是一個(gè)問題，因?yàn)榘l(fā)送計(jì)算機(jī)的傳輸速度不能比接收者可以接收的速度更快。擁塞控制直到 1986 年才成為一個(gè)嚴(yán)重的問題，當(dāng)時(shí)互聯(lián)網(wǎng)經(jīng)歷了第一次“擁塞崩潰”。?

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

為什么我們需要擁塞控制

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

如果水流不夠強(qiáng)勁，最終用戶需要很長(zhǎng)時(shí)間才能裝滿浴缸。但是，如果水太多，可能會(huì)使管道緊張并導(dǎo)致泄漏。同樣，如果數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)乃俣炔粔蚩?#xff0c;最終用戶可能無(wú)法收到足夠的數(shù)據(jù)來(lái)享受良好的體驗(yàn)質(zhì)量 (QoE)。例如，如果有人正在觀看高清電影，他們需要大量數(shù)據(jù)才能獲得清晰銳利的畫面。?

如果過多的數(shù)據(jù)被泵入管材，管件可能無(wú)法來(lái)得及處理。它最終可能會(huì)泄漏數(shù)據(jù)，這種現(xiàn)象稱為數(shù)據(jù)包丟失，導(dǎo)致最終用戶因重復(fù)的視頻重新緩沖而感到沮喪。因此，發(fā)送數(shù)據(jù)太快也會(huì)導(dǎo)致 QoE 不佳。?

擁塞控制需要控制數(shù)據(jù)處在沒有發(fā)送足夠數(shù)據(jù)和發(fā)送太多數(shù)據(jù)之間。

擁塞控制不應(yīng)與路由混淆，這是另一個(gè)基本的網(wǎng)絡(luò)挑戰(zhàn)?；氐剿艿谋扔?#xff0c;雖然擁塞控制的任務(wù)是確保有效地使用管道，但路由負(fù)責(zé)確定水（數(shù)據(jù)）將流經(jīng)的管道。Internet 路由算法確定數(shù)據(jù)流量將通過哪些路徑。在今天的互聯(lián)網(wǎng)中，與早期不同，擁塞控制和路由由單獨(dú)的算法獨(dú)立處理。

擁塞控制對(duì)體驗(yàn)質(zhì)量的重要性

QoE 是指數(shù)據(jù)消費(fèi)者在使用互聯(lián)網(wǎng)時(shí)的滿意度。例如，在視頻流中，QoE 表現(xiàn)在：

• 您的流媒體視頻開始播放需要多長(zhǎng)時(shí)間。
  

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

• 重新緩沖時(shí)間，這是您必須花費(fèi)的時(shí)間來(lái)等待您的視頻恢復(fù)。（研究表明，人們看到緩沖時(shí)的圈圈的身體反應(yīng)類似于他們觀看恐怖電影時(shí)的反應(yīng)。）
  

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

擁塞控制是對(duì)此類服務(wù)的 QoE 影響最大的因素之一，而不僅僅是更快的互聯(lián)網(wǎng)連接。?

互聯(lián)網(wǎng)提供商可能會(huì)聲稱升級(jí)到 5G、光纖電纜或更高的帶寬將解決您的 QoE 問題。這些往往是空洞的承諾。根據(jù)華爾街日?qǐng)?bào)報(bào)道的研究，即使是帶寬最高的訂戶通常也只有大約 36% 的時(shí)間接收高清視頻。當(dāng)問題出在其他地方時(shí)，消費(fèi)者可能會(huì)在大型互聯(lián)網(wǎng)套餐上浪費(fèi)他們的錢。?

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

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

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

03

PART

擁塞控制的三個(gè)目標(biāo)

擁塞控制的三個(gè)目標(biāo)是：?

• 充分利用網(wǎng)絡(luò)帶寬

• 將數(shù)據(jù)丟失和延遲降至最低

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

這三個(gè)目標(biāo)之間存在明確的權(quán)衡。盡管您想充分利用網(wǎng)絡(luò)帶寬，但您不想過沖，因?yàn)檫@會(huì)導(dǎo)致數(shù)據(jù)丟失。您可以不惜一切代價(jià)優(yōu)先考慮公平性，但這可能會(huì)導(dǎo)致您未充分利用網(wǎng)絡(luò)帶寬。

除非您解決這些目標(biāo)中的每一個(gè)，否則您無(wú)法完全解決擁塞控制。這是更深入的解釋。?

想象一個(gè)簡(jiǎn)單的場(chǎng)景，如下圖 4 所示，顯示了三個(gè)連接對(duì)：

通常，互聯(lián)網(wǎng)連接是雙向的。例如，Facebook 向最終用戶發(fā)送數(shù)據(jù)，但這些最終用戶也將數(shù)據(jù)發(fā)送回 Facebook。每個(gè)發(fā)送者也是接收者，反之亦然。為了簡(jiǎn)化事情，我們假設(shè)在所有三個(gè)連接中，一個(gè)端點(diǎn)（發(fā)送方）正在向另一個(gè)端點(diǎn)（接收方）發(fā)送流量。具體來(lái)說：

Facebook 服務(wù)器（發(fā)送方 1）向 Facebook 用戶（接收方 1）發(fā)送流量

Netflix 服務(wù)器（發(fā)送方 2）將流量發(fā)送到 Netflix 視頻客戶端（接收方 2）

Zoom 視頻會(huì)議用戶（發(fā)送方 3）向不同的 Zoom 用戶（接收方 3）發(fā)送流量

假設(shè)三個(gè)發(fā)送方共享一個(gè)帶寬為 120 Mbps 的網(wǎng)絡(luò)鏈接，這意味著它可以每秒傳輸 120 兆位（120,000,000 位）數(shù)據(jù)。?三個(gè)連接應(yīng)該使用什么數(shù)據(jù)傳輸速率？這正是擁塞控制算法必須確定的。以下是我們的三個(gè)擁塞控制目標(biāo)影響算法結(jié)果的方式。

充分利用網(wǎng)絡(luò)帶寬

Internet 服務(wù)和應(yīng)用程序通常希望以盡可能高的速率發(fā)送數(shù)據(jù)，因?yàn)檫@可以為用戶帶來(lái)更好的 QoE。因此，擁塞控制應(yīng)該使應(yīng)用程序能夠使用盡可能多的可用帶寬。?

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

將數(shù)據(jù)包丟失和延遲降至最低?

當(dāng)數(shù)據(jù)包進(jìn)入網(wǎng)絡(luò)的速度超過網(wǎng)絡(luò)支持的速度時(shí)，就會(huì)造成擁塞，而擁塞會(huì)導(dǎo)致數(shù)據(jù)包延遲或丟失。?
例如，想象一下，每個(gè)應(yīng)用程序都以 60 Mbps 的恒定速率傳輸數(shù)據(jù)。它們的總傳輸速率為 3 x 60 = 180 Mbps，比網(wǎng)絡(luò)帶寬高 50%。?

這是個(gè)問題。網(wǎng)絡(luò)無(wú)法在所有數(shù)據(jù)包進(jìn)入網(wǎng)絡(luò)后立即發(fā)送，因?yàn)閷?shí)在是太多了。網(wǎng)絡(luò)在路由器 A 上存儲(chǔ)（緩沖）額外的數(shù)據(jù)包，直到它可以繼續(xù)發(fā)送它們。這會(huì)導(dǎo)致數(shù)據(jù)到達(dá)接收器的延遲，如果網(wǎng)絡(luò)中沒有足夠的空間來(lái)存儲(chǔ)數(shù)據(jù)，甚至可能導(dǎo)致數(shù)據(jù)被丟棄和丟失。?

在連接之間保持公平

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

為了解決所有 3 個(gè)目標(biāo)，我們可以說每個(gè)發(fā)送方應(yīng)該以 40 Mbps 的速度傳輸數(shù)據(jù)。這似乎是完美的解決方案，它解決了所有 3 個(gè)要求：

?

• 充分利用網(wǎng)絡(luò)帶寬。總網(wǎng)絡(luò)使用率為 120 Mbps，這是容量的 100%，可確保不會(huì)浪費(fèi)額外的帶寬。?

• 將數(shù)據(jù)包丟失和延遲降至最低。流量進(jìn)入鏈路的速度不會(huì)超過網(wǎng)絡(luò)的處理速度，因此不會(huì)出現(xiàn)不必要的數(shù)據(jù)包延遲或數(shù)據(jù)包丟失。

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

它看似簡(jiǎn)單。那么為什么擁塞控制是一個(gè)如此復(fù)雜的挑戰(zhàn)呢？這是因?yàn)榛ヂ?lián)網(wǎng)流量的真實(shí)世界遠(yuǎn)比我們簡(jiǎn)單的例子復(fù)雜得多。

在現(xiàn)實(shí)世界的互聯(lián)網(wǎng)擁塞控制中，這些發(fā)件人中的每一個(gè)都獨(dú)立于其他人做出決定。這是在沒有太多關(guān)于網(wǎng)絡(luò)內(nèi)條件的信息（例如鏈路容量）的情況下完成的，并且網(wǎng)絡(luò)條件在不斷變化。更重要的是，競(jìng)爭(zhēng)網(wǎng)絡(luò)帶寬的連接可能遠(yuǎn)遠(yuǎn)不止三個(gè)，新連接意外進(jìn)入網(wǎng)絡(luò)而其他連接突然離開。?

我們將在下一節(jié)中更詳細(xì)地討論這一點(diǎn)。?

04

PART

為什么

為什么互聯(lián)網(wǎng)擁塞控制如此具有挑戰(zhàn)性？提示：因?yàn)楝F(xiàn)實(shí)世界很復(fù)雜

擁塞控制是網(wǎng)絡(luò)研究和實(shí)踐中解決的最持久和最關(guān)鍵的問題之一。妨礙互聯(lián)網(wǎng)擁塞控制解決方案的主要問題都存在于具有挑戰(zhàn)性的“最后一英里”，其中：

• 隨著時(shí)間的推移，網(wǎng)絡(luò)狀況可能會(huì)發(fā)生巨大變化并迅速變化

• 傳送速率決策是分散的

• 流量發(fā)送者關(guān)于網(wǎng)絡(luò)狀況的信息非常有限

• 不同的連接爭(zhēng)奪網(wǎng)絡(luò)帶寬

• 共享同一網(wǎng)絡(luò)的 Internet 應(yīng)用程序和服務(wù)具有不同且相互沖突的需求

高度可變的網(wǎng)絡(luò)條件

最后一英里網(wǎng)絡(luò)通常是復(fù)雜、多樣和動(dòng)態(tài)的環(huán)境。不同的網(wǎng)段在大小、結(jié)構(gòu)、丟失模式、網(wǎng)絡(luò)延遲、競(jìng)爭(zhēng)水平等方面可能有所不同。把它想象成一大堆混亂的管道，其中一些又大又寬，而另一些則狹窄、漏水和扭曲。?

?

即使使用圖 4 中的簡(jiǎn)單示例也可以說明網(wǎng)絡(luò)條件的多樣性。網(wǎng)絡(luò)屬性包括：?

• 網(wǎng)絡(luò)鏈路帶寬

• 數(shù)據(jù)包通過鏈接所花費(fèi)的時(shí)間（也稱為鏈接延遲）

• 當(dāng)鏈路容量耗盡時(shí)，RouterA用于存儲(chǔ)多余數(shù)據(jù)包的緩沖區(qū)大小

• RouterA緩存滿時(shí)丟棄報(bào)文的排隊(duì)策略

• 更多?

?

所有這些特性對(duì)擁塞控制有著顯著的影響。例如，如果網(wǎng)絡(luò)隊(duì)列或緩沖區(qū)很淺，那么即使是少量的帶寬過沖也會(huì)導(dǎo)致數(shù)據(jù)包丟失。但是，如果緩沖區(qū)很深，超出帶寬可能會(huì)導(dǎo)致數(shù)據(jù)包在網(wǎng)絡(luò)內(nèi)聚合，以便在擁塞再次緩解時(shí)發(fā)送，從而導(dǎo)致長(zhǎng)時(shí)間延遲。

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

?

發(fā)送速率決策是分散的?

目前，每個(gè)發(fā)送方就發(fā)送數(shù)據(jù)包時(shí)使用的速率做出自己的獨(dú)立決定。沒有中央機(jī)構(gòu)監(jiān)督這些決定，也沒有明顯的方式讓任何給定的發(fā)件人知道競(jìng)爭(zhēng)發(fā)件人正在使用哪些速率，甚至有多少其他發(fā)件人在網(wǎng)絡(luò)帶寬上與之競(jìng)爭(zhēng)。盡管我們希望利率決策能夠相互良好地互動(dòng)，但沒有辦法確保這一點(diǎn)。?

?

關(guān)于傳輸成功和失敗的有限反饋

發(fā)送方對(duì)網(wǎng)絡(luò)本身的可見性非常有限，這一事實(shí)使問題更加復(fù)雜。除了非常特定的網(wǎng)絡(luò)環(huán)境（如數(shù)據(jù)中心）、互聯(lián)網(wǎng)網(wǎng)絡(luò)，特別是最后一英里網(wǎng)絡(luò)，不向發(fā)送方提供任何直接反饋。在最后一英里環(huán)境中，您將看到的唯一反饋是終端接收者和發(fā)送者之間的端點(diǎn)反饋。?

這很像試圖了解在看不見的水管網(wǎng)絡(luò)中發(fā)生了什么。您知道水已經(jīng)離開了自來(lái)水公司的水庫(kù)，但您不知道在它通過不同的管道到達(dá)用戶的浴缸時(shí)會(huì)發(fā)生什么?？赡軙?huì)出現(xiàn)水管爆裂、水進(jìn)入較小管道時(shí)流量過大或最終用戶家庭管道出現(xiàn)一系列泄漏的情況。這些中的任何一個(gè)都可能導(dǎo)致用戶無(wú)法注滿浴缸。也有可能是家里的其他人同時(shí)洗碗來(lái)分流水。?

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

?

連接之間的競(jìng)爭(zhēng)?

當(dāng)多個(gè)連接在同一個(gè)網(wǎng)絡(luò)上的互動(dòng)，如在我們前面的例子，一個(gè)發(fā)送者的動(dòng)態(tài)行為可以顯著影響其他發(fā)件人。在圖 4 中，我們展示了通過同一網(wǎng)絡(luò)連接的三對(duì)用戶。如果發(fā)送方 1 立即決定顯著提高其傳輸速率，這可能會(huì)導(dǎo)致?lián)砣?#xff0c;從而導(dǎo)致所有三個(gè)發(fā)送方的數(shù)據(jù)包丟失?；蛘?#xff0c;如果發(fā)送方的傳輸突然終止，網(wǎng)絡(luò)帶寬將立即釋放以供其他連接使用。發(fā)件人無(wú)法明確知道哪些其他發(fā)件人正在使用或已停止使用網(wǎng)絡(luò)，但盡管缺乏信息，但仍需要有效地采取行動(dòng)。?

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

?

需求多樣且相互沖突的互聯(lián)網(wǎng)服務(wù)

在這種混亂的因素組合中，還有更多的問題需要考慮。Internet 服務(wù)和應(yīng)用程序在帶寬和延遲方面可能有不同的要求。實(shí)時(shí)視頻流等服務(wù)；增強(qiáng)、虛擬或混合現(xiàn)實(shí)；和寬帶物聯(lián)網(wǎng)，都有不同的要求。有時(shí)，不可能同時(shí)滿足。

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

對(duì)于像 Netflix 這樣的點(diǎn)播視頻，擁有支持高清觀看的高帶寬至關(guān)重要，因此對(duì)于觀看者來(lái)說，畫面始終清晰銳利。如果視頻傳輸中存在較小的、持續(xù)的延遲，則不會(huì)給觀看者帶來(lái)不便。

Zoom 視頻會(huì)議首先需要低延遲，以防止不同人發(fā)言時(shí)出現(xiàn)時(shí)間延遲。即使是半秒的延遲也會(huì)導(dǎo)致參與者互相交談并錯(cuò)過談話的重要部分。

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

應(yīng)用程序需求的多樣性意味著網(wǎng)絡(luò)帶寬應(yīng)該如何劃分并不總是很清楚。這可以用一個(gè)關(guān)于駱駝和斑馬一起穿越沙漠的寓言來(lái)解釋。他們的水量有限，所以公平地說，他們同意每個(gè)人喝相同的水量。當(dāng)他們到達(dá)綠洲時(shí)，斑馬幾乎因脫水而倒下，但駱駝幾乎不需要水。就像斑馬和駱駝一樣，不同的互聯(lián)網(wǎng)服務(wù)有不同的需求，按照人為的“平等”標(biāo)準(zhǔn)對(duì)待它們有時(shí)是不可取的。

05

PART

介紹 TCP

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

?

TCP 依賴于數(shù)據(jù)包反饋

在我們圖 4的示例中，每個(gè)發(fā)送方都傳輸數(shù)據(jù)包并接收有關(guān)數(shù)據(jù)包是否到達(dá)的反饋。該反饋采用確認(rèn) (ACK) 的形式，在接收到數(shù)據(jù)包時(shí)發(fā)送。?

盡管這種反饋非常有限，但發(fā)送者仍然可以通過檢查 ACK 來(lái)獲取有價(jià)值的信息，以跟蹤哪些數(shù)據(jù)包沒有被接收到以及數(shù)據(jù)穿越網(wǎng)絡(luò)需要多長(zhǎng)時(shí)間。具體來(lái)說，當(dāng)數(shù)據(jù)包經(jīng)過足夠的時(shí)間但從未收到 ACK 時(shí)，可以推斷出數(shù)據(jù)包丟失。當(dāng)接收到后續(xù)數(shù)據(jù)包的 ACKS 時(shí)，也可以推斷出丟失，但接收方?jīng)]有收到有關(guān)此數(shù)據(jù)包命運(yùn)的消息。此外，可以通過檢查發(fā)送的數(shù)據(jù)包到達(dá)發(fā)送方所需的 ACK 時(shí)間來(lái)估計(jì)網(wǎng)絡(luò)延遲。從數(shù)據(jù)包傳輸?shù)酵粩?shù)據(jù)包返回 ACK 之間經(jīng)過的時(shí)間稱為其往返時(shí)間 (RTT)。

?

TCP擁塞窗口

TCP 擁塞控制中的一個(gè)關(guān)鍵概念是擁塞窗口。擁塞窗口是在任何給定時(shí)間從發(fā)送方到接收方的途中（或“飛行中”）數(shù)據(jù)包的最大允許數(shù)量。一旦數(shù)據(jù)包到達(dá)接收方并且發(fā)送方收到 ACK，數(shù)據(jù)包就已經(jīng)到達(dá)并且不再“在飛行中”。實(shí)際上，擁塞窗口指定了在任何給定時(shí)間可以“傳輸”的數(shù)據(jù)字節(jié)數(shù)，但為簡(jiǎn)單起見，我們將根據(jù)數(shù)據(jù)包數(shù)來(lái)考慮它。

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

?

TCP 控制擁塞窗口的大小。擁塞窗口越大，同時(shí)到達(dá)接收方的數(shù)據(jù)包就越多；這意味著以更快的速度發(fā)送流量。TCP 擁塞控制就是隨時(shí)間調(diào)整擁塞窗口的大小。如果擁塞窗口過大，發(fā)送數(shù)據(jù)包的速率將超過網(wǎng)絡(luò)容量，導(dǎo)致數(shù)據(jù)包丟失和/或延遲。如果擁塞窗口太小，可能會(huì)發(fā)送流量太慢以獲得良好的體驗(yàn)質(zhì)量。

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

?

TCP 的工作原理：慢啟動(dòng)和擁塞避免

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

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

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

多個(gè)發(fā)送方的 TCP 收斂和公平性

當(dāng)多個(gè) TCP 發(fā)送方共享相同的網(wǎng)絡(luò)帶寬時(shí)，它們必須不斷地對(duì)彼此的發(fā)送速率做出反應(yīng)，而實(shí)際上并不知道這些速率是多少。

假設(shè)兩個(gè)發(fā)送方共享同一網(wǎng)絡(luò)鏈路，如下圖 7 所示，鏈路容量為 R Mbps。

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

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

公平線上的某些點(diǎn)顯然是不可取的。例如，當(dāng)公平線大約為零時(shí)，發(fā)送速率非常低效并且遠(yuǎn)低于鏈路的全部容量。在線路另一端的某個(gè)點(diǎn)，發(fā)送速率的總和變得過高并超過 R，導(dǎo)致數(shù)據(jù)包丟失。?

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

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

當(dāng)多個(gè)流交互時(shí)，TCP 的鋸齒行為逐漸靠近公平帶寬分配線，如下圖 11 所示：?

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

這種發(fā)送者越來(lái)越接近公平線的行為，無(wú)論有多少發(fā)送者都適用；發(fā)送速率較快的發(fā)件人總是比速率較慢的發(fā)件人降低速率更多（因?yàn)樗俾士斓囊话攵嘤诼俾实囊话?#xff09;，從而使速率較慢的發(fā)件人最終趕上。?

?

各種各樣的 TCP 風(fēng)格

?

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

TCP Cubic

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

主要區(qū)別在于 Cubic 如何在擁塞避免期間提高其速率。假設(shè) TCP Cubic 發(fā)送方在其擁塞窗口大小為 W 時(shí)遇到數(shù)據(jù)包丟失，然后將其擁塞窗口減半。直觀上，Cubic 最初會(huì)急劇增加其擁塞窗口，然后隨著接近 W 逐漸減慢擁塞窗口的增長(zhǎng)，這也是它之前遇到的問題。如果擁塞窗口超過 W 而沒有看到丟包，Cubic 會(huì)逐漸增加擁塞窗口的增長(zhǎng)。這種先凹后凸的行為模仿了三次多項(xiàng)式的圖形，因此得名。圖 12 說明了由于數(shù)據(jù)包丟失而導(dǎo)致?lián)砣翱跍p半后擁塞窗口的變化。

?

TCP Vegas

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

與 Reno 和 Cubic 不同， Vegas 會(huì)注意到增加的 RTT當(dāng)數(shù)據(jù)包在網(wǎng)絡(luò)隊(duì)列中等待時(shí)。因此，當(dāng)數(shù)據(jù)包開始在網(wǎng)絡(luò)內(nèi)聚合時(shí)，它可以通過降低速率來(lái)保持低數(shù)據(jù)包延遲。雖然這在理論上聽起來(lái)不錯(cuò)，但它也帶來(lái)了一個(gè)主要缺點(diǎn)。當(dāng) TCP Vegas 發(fā)送方在相同鏈路上與 TCP Reno 或 Cubic 發(fā)送方競(jìng)爭(zhēng)時(shí)，前者總是為后者讓路。這是因?yàn)閂egas發(fā)送方在更早的階段就開始降低速率，從而使他們自己的網(wǎng)絡(luò)帶寬份額非常小。由于 Reno/Cubic 發(fā)送方?jīng)]有注意到 RTT 捕獲的數(shù)據(jù)包延遲的增加，因此它們會(huì)繼續(xù)全速發(fā)送，直到發(fā)現(xiàn)數(shù)據(jù)包丟失。

?

特定環(huán)境的 TCP 變體

某些 TCP 變體針對(duì)特定環(huán)境進(jìn)行了優(yōu)化，例如數(shù)據(jù)中心、WiFi 網(wǎng)絡(luò)和衛(wèi)星網(wǎng)絡(luò)。例如，衛(wèi)星數(shù)據(jù)傳輸?shù)耐禃r(shí)間 (RTT) 可能是數(shù)百毫秒，這在互聯(lián)網(wǎng)術(shù)語(yǔ)中是很長(zhǎng)的時(shí)間。高 RTT 意味著發(fā)送方可能需要很長(zhǎng)時(shí)間才能收到有關(guān)數(shù)據(jù)包的任何反饋。最重要的是，衛(wèi)星數(shù)據(jù)傳輸網(wǎng)絡(luò)經(jīng)常會(huì)遇到不可忽略的、與擁塞無(wú)關(guān)的數(shù)據(jù)包丟失。標(biāo)準(zhǔn) TCP 假設(shè)任何丟失都表示擁塞；但如果丟失與擁塞無(wú)關(guān)，發(fā)送方將無(wú)緣無(wú)故地降低流量速率。因此，一種不同形式的衛(wèi)星 TCP，稱為 TCP Hybla，被發(fā)明來(lái)處理這些問題。?

WiFi 和移動(dòng)網(wǎng)絡(luò)通常也會(huì)遇到非擁塞相關(guān)的損失，以及其他挑戰(zhàn)，例如由于信號(hào)強(qiáng)度或用戶移動(dòng)性的變化而導(dǎo)致的帶寬頻繁變化。這鼓勵(lì)研究人員和從業(yè)人員針對(duì)這些特定環(huán)境定制解決方案。

相對(duì)大量的不同 TCP 變體表明了 TCP 的算法缺陷，這需要設(shè)計(jì)不同的點(diǎn)解決方案。盡管 TCP 在 Internet 上的表現(xiàn)令人欽佩，但它在許多實(shí)際環(huán)境中的性能卻是出了名的糟糕。?

我們現(xiàn)在將詳細(xì)說明 TCP 的缺點(diǎn)和可能的替代方案。

06

PART

TCP 不足之處

TCP 的硬連線響應(yīng)并不總是有意義

每個(gè) TCP 變體都有一個(gè)內(nèi)置到解決方案中的硬連線響應(yīng)。TCP 是一個(gè)嚴(yán)格的公式，它對(duì)數(shù)據(jù)包級(jí)別的事件產(chǎn)生固定的響應(yīng)。例如，每當(dāng)檢測(cè)到丟包時(shí)，TCP 以相同的方式響應(yīng)，而沒有考慮不同的丟包原因可能需要不同的響應(yīng)。通常，這涉及將發(fā)送速率減半，就像在 TCP Reno 和 Cubic 中所做的那樣。?

TCP 的回應(yīng)反映了其基本假設(shè)。關(guān)于丟包的兩個(gè)強(qiáng)有力但隱含的假設(shè)是：

• 任何數(shù)據(jù)包丟失都是網(wǎng)絡(luò)擁塞的標(biāo)志

• 發(fā)送方始終是擁塞的負(fù)責(zé)人

然而，正如我們?cè)谙旅娼忉尩?#xff0c;這些假設(shè)在實(shí)踐中經(jīng)常被推翻。

丟包的可能原因有很多，每個(gè)都需要不同的響應(yīng)。即使是相同的連接也可能在不同的時(shí)間因不同的原因而丟失數(shù)據(jù)包。以下是一些可能的場(chǎng)景：

圖 13 顯示了對(duì)上述四種情況中每一種情況的最佳響應(yīng)。

?

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

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

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

TCP 的另一個(gè)基本限制是您無(wú)法針對(duì)不同應(yīng)用程序和網(wǎng)絡(luò)條件的需要對(duì)其進(jìn)行自定義。?

無(wú)論您是在曼哈頓的智能電視上觀看 VoD，還是在巴塞羅那的移動(dòng)設(shè)備上觀看現(xiàn)場(chǎng)體育賽事，TCP（默認(rèn)為 Cubic）都將以完全相同的方式運(yùn)行。它不能適應(yīng)網(wǎng)絡(luò)上運(yùn)行的不同互聯(lián)網(wǎng)應(yīng)用和服務(wù)的具體要求，也不能根據(jù)網(wǎng)絡(luò)情況定制其速率調(diào)整規(guī)則。?

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

不同的網(wǎng)絡(luò)表現(xiàn)出非常不同的特征。一些網(wǎng)絡(luò)可能有大量與擁塞無(wú)關(guān)的丟包，這可能是個(gè)人在巴塞羅那的移動(dòng)網(wǎng)絡(luò)上觀看體育直播的情況。這是因?yàn)橐苿?dòng)網(wǎng)絡(luò)連接不太穩(wěn)定，網(wǎng)絡(luò)帶寬和隨后的丟失率經(jīng)常變化。在其他網(wǎng)絡(luò)中，所有損失都可能與擁塞有關(guān)，曼哈頓智能電視上播放的電影可能就是這種情況。在某些網(wǎng)絡(luò)中，帶寬競(jìng)爭(zhēng)可能非常激烈，而在其他網(wǎng)絡(luò)中，發(fā)送方可以有效地與其他連接隔離。在某些情況下，網(wǎng)絡(luò)緩沖區(qū)可能非常深，而在其他情況下，它們可能非常淺。

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

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

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

07

PART

TCP 的替代方案

TCP 的基于模型與無(wú)模型的替代方案

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

TCP 的替代方案主要有兩種類型：基于模型的算法和無(wú)模型算法。它們之間的根本區(qū)別在于它們是否基于對(duì)網(wǎng)絡(luò)及其行為方式的假設(shè)。?

基于網(wǎng)絡(luò)模型的算法依賴于網(wǎng)絡(luò)環(huán)境的表示，即網(wǎng)絡(luò)模型。該模型基于假設(shè)和來(lái)自觀察到的網(wǎng)絡(luò)動(dòng)態(tài)的推論。該算法使用該模型來(lái)預(yù)測(cè)網(wǎng)絡(luò)動(dòng)態(tài)如何演變以及不同發(fā)送速率對(duì)性能的影響方式。?

無(wú)網(wǎng)絡(luò)模型算法將網(wǎng)絡(luò)視為無(wú)法準(zhǔn)確建模的黑箱。在沒有任何預(yù)測(cè)基礎(chǔ)的情況下，無(wú)模型算法會(huì)觀察由不同發(fā)送速率產(chǎn)生的性能，并在經(jīng)驗(yàn)上尋找速率和性能之間的“良好”映射。

這兩種類型的算法具有不同的優(yōu)勢(shì)。如果您確信自己的假設(shè)和推論是正確的，那么基于模型的算法將使您獲得比無(wú)模型算法的實(shí)驗(yàn)方法快得多的有效發(fā)送速率。但是，如果您的假設(shè)是錯(cuò)誤的，那么您會(huì)在嘗試為一個(gè)模糊的網(wǎng)絡(luò)找到最佳發(fā)送速率時(shí)遇到很多挫折。?

想象一下，在總帶寬為 100 Mbps 的鏈路上有一個(gè)單獨(dú)的連接。最佳發(fā)送速率為 100 Mbps。具有準(zhǔn)確模型的基于模型的算法將從 100 Mbps 開始，因此幾乎立即達(dá)到最佳發(fā)送速率。但這只有在它有一個(gè)準(zhǔn)確的模型時(shí)才會(huì)發(fā)生。如果模型不正確，因?yàn)閹捜绻?200 Mbps 或者發(fā)送方不是單獨(dú)在鏈路上，該算法要么無(wú)法充分利用鏈路，要么發(fā)送流量過快并導(dǎo)致數(shù)據(jù)包丟失。相比之下，無(wú)模型方法可能會(huì)花費(fèi)寶貴的時(shí)間來(lái)探索不同發(fā)送速率對(duì)性能的影響。但是，如果基于模型的方法有錯(cuò)誤的模型，則無(wú)模型算法可能會(huì)優(yōu)于基于模型的算法，因?yàn)樗恍枰m正錯(cuò)誤的現(xiàn)實(shí)模型。?

基于模型的方法非常適合可預(yù)測(cè)的網(wǎng)絡(luò)，在這種網(wǎng)絡(luò)中，可以從準(zhǔn)確的網(wǎng)絡(luò)模型開始。其中一些示例是大型組織（如 Google、Facebook 和 Amazon）內(nèi)的私有內(nèi)部網(wǎng)。這些網(wǎng)絡(luò)穩(wěn)定且行為良好；網(wǎng)絡(luò)的所有基礎(chǔ)設(shè)施都在集中控制之下。?

無(wú)模型方法最適合難以準(zhǔn)確建模的復(fù)雜網(wǎng)絡(luò)環(huán)境，并且在動(dòng)態(tài)條件下本質(zhì)上更健壯。在互聯(lián)網(wǎng)的最后一英里，條件在不斷變化（正如我們上面所討論的），因此無(wú)模型算法通常更合適。?

我們將更深入地研究?jī)煞N擁塞控制選項(xiàng)。BBR 是原型白盒、基于模型的方法，最初由 Google 為其內(nèi)部網(wǎng)絡(luò)開發(fā)。PCC 是黑盒、無(wú)模型方法的范例，并且是 Compira Labs 解決方案的基礎(chǔ)。?

08

PART

BBR

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

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

簡(jiǎn)約之美

BBR 本質(zhì)上是相當(dāng)簡(jiǎn)單的。這是算法的基本結(jié)構(gòu)。?

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

BBR如何運(yùn)作？

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

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

?

盡管我們的示例是針對(duì)由單個(gè)鏈接組成的網(wǎng)絡(luò)路徑，但 BBR 將整個(gè)路徑建模為單個(gè)鏈接，無(wú)論該路徑實(shí)際包含多少個(gè)鏈接。為此，BBR 在每種情況下都使用相同的過程來(lái)估計(jì)帶寬。當(dāng)多個(gè)持久的 BBR 連接在同一鏈路上發(fā)送流量時(shí)，實(shí)驗(yàn)表明它們通常都能獲得公平的帶寬份額。

BBR 與 TCP

BBR 與 TCP 的主要區(qū)別有兩點(diǎn)：

BBR 調(diào)整發(fā)送速率，而不是擁塞窗口。我們已經(jīng)解釋過 TCP 改變的是擁塞窗口而不是實(shí)際的發(fā)送速率。對(duì)于 BBR，將決定以 Mbps 為單位的流量速度。

BBR 收集有意義的統(tǒng)計(jì)數(shù)據(jù)。與 TCP 不同，BBR 不規(guī)定對(duì)數(shù)據(jù)包級(jí)事件的硬連線反應(yīng)。相反，它試圖推斷有關(guān)網(wǎng)絡(luò)的有意義的統(tǒng)計(jì)數(shù)據(jù)，主要是通過 ACK 接收速率，并以此為基礎(chǔ)來(lái)指導(dǎo)其速率選擇。

在大多數(shù)情況下，BBR 的性能優(yōu)于廣泛使用的 TCP 變體，例如 TCP Cubic。通過明確針對(duì)瓶頸帶寬，BBR 實(shí)現(xiàn)了更好的吞吐量和更低的延遲。此外，BBR 天生對(duì)非擁塞相關(guān)的丟失更具彈性，因?yàn)榕c TCP 不同，它不會(huì)將數(shù)據(jù)包丟失視為擁塞信號(hào)。?

也就是說，BBR 確實(shí)有缺點(diǎn)。

BBR 什么時(shí)候不合適？

BBR 依賴于其以易于處理且對(duì)決策有用的方式對(duì)網(wǎng)絡(luò)進(jìn)行建模的能力，無(wú)論其復(fù)雜程度如何。毫不奇怪，這并不總是可能的，尤其是在混亂的最后一英里。?

盡管 BBR 似乎有一個(gè)很好的情況模型，但網(wǎng)絡(luò)仍然可以包含各種意外。競(jìng)爭(zhēng)性交通流量突然進(jìn)出；基礎(chǔ)路線可能會(huì)發(fā)生變化；不同的發(fā)送方可能會(huì)與采用不同擁塞控制算法的連接共享鏈路；用戶移動(dòng)性可能導(dǎo)致意外丟包和帶寬波動(dòng)等等。?

當(dāng) BBR 模型偏離現(xiàn)實(shí)太遠(yuǎn)時(shí)，BBR 會(huì)做出不明智的決定。

另一個(gè)嚴(yán)重的缺點(diǎn)是 BBR 不是一個(gè)“公平”的擁塞控制解決方案。BBR 通常適用于使用相同協(xié)議的流量源。但是當(dāng) BBR 與其他流量控制協(xié)議對(duì)抗時(shí)，它的表現(xiàn)并不好。BBR 比其它流控制更加激進(jìn)，從而接管所有有限的可用帶寬。

09

PART

PCC

PCC - 一種黑匣子，無(wú)模型方法

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

“無(wú)模型”的意義

正如我們所解釋的，BBR 是一種基于模型的白盒方法，它利用網(wǎng)絡(luò)統(tǒng)計(jì)信息來(lái)推斷網(wǎng)絡(luò)狀況。PCC 正好相反。它作為一個(gè)無(wú)法理解的黑匣子接近網(wǎng)絡(luò)。PCC 發(fā)送者從不嘗試推斷網(wǎng)絡(luò)參數(shù)，例如瓶頸帶寬或丟包的根本原因。?

相反，PCC 將數(shù)據(jù)傳輸視為一系列“微實(shí)驗(yàn)”。在每個(gè)這樣的微實(shí)驗(yàn)中，發(fā)送者量化當(dāng)前發(fā)送速率的性能水平。它使用此信息隨時(shí)間調(diào)整其發(fā)送速率。?

PCC是如何工作的？

PCC 有兩個(gè)主要組成部分：?

• 效用函數(shù)
  

• 在線速率選擇算法?

?

效用函數(shù)，或效用框架，需要從所選擇的發(fā)送速率得到統(tǒng)計(jì)數(shù)據(jù)，并將其轉(zhuǎn)換成一個(gè)性能得分，或效用價(jià)值。此效用值表示以該速率發(fā)送所達(dá)到的性能水平。在線速率選擇算法針對(duì)先前選擇的發(fā)送速率觀察到的效用值決定下一次發(fā)送的速率。

PCC 效用框架：靈活性的優(yōu)勢(shì)

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

讓我們考慮一個(gè)場(chǎng)景，在這個(gè)場(chǎng)景中，某個(gè)發(fā)送速率的性能被測(cè)量為安全到達(dá)目的地的流量比例。想象一個(gè)簡(jiǎn)化的連接，發(fā)送方以 50 Mbps 的速度發(fā)送數(shù)據(jù)包，其中 30% 的數(shù)據(jù)包，或每 100 個(gè)發(fā)送的 30 個(gè)數(shù)據(jù)包在途中丟失；這意味著 70% 到達(dá)。當(dāng)使用這個(gè)簡(jiǎn)單的效用函數(shù)來(lái)量化性能時(shí)，派生的效用值等于 35，即 50 Mbps 的 70%。?

該效用函數(shù)可以用以下等式表示：

U = X(1-L)

?

其中：

• X 是發(fā)送速率

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

• U 是性能分?jǐn)?shù)?

?

例如，如果沒有數(shù)據(jù)包丟失，那么 X 和 U 是相同的，因?yàn)樗袛?shù)據(jù)包都到達(dá)了目的地。如果有一半數(shù)據(jù)包丟失，則 U=X/2。?

效用函數(shù)的這種特定選擇過于簡(jiǎn)單而無(wú)法發(fā)揮作用。原因如下：

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

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

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

本例中的效用函數(shù)完全忽略了延遲。它只會(huì)對(duì)網(wǎng)絡(luò)緩沖區(qū)耗盡并且數(shù)據(jù)包被丟棄時(shí)的擁塞做出反應(yīng)，而不是對(duì)擁塞的開始做出反應(yīng)。因此，我們可以通過設(shè)置數(shù)據(jù)包延遲和數(shù)據(jù)包丟失的懲罰來(lái)創(chuàng)建更好的效用函數(shù)，以產(chǎn)生所需的屬性。包延遲的懲罰表示為?p_D，丟包的懲罰表示為 p_L?。此類效用函數(shù)具有以下一般形式：

U = X – p_D?X – p_L?X

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

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

這正是我們之前的簡(jiǎn)單效用函數(shù)。

現(xiàn)在該等式包括三個(gè)需要考慮的因素：

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

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

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

確定效用函數(shù)的好選擇可能很微妙，因?yàn)樾в煤瘮?shù)有兩個(gè)重要作用：

1. 為不同應(yīng)用程序定制性能的靈活性

正如我們上面提到的，不同的應(yīng)用程序有不同的需求。其中一些對(duì)延遲敏感，例如 Zoom，而另一些則需要帶寬，例如 Netflix?？梢哉{(diào)整實(shí)用功能以匹配每個(gè)應(yīng)用程序的需求。例如，當(dāng)使用 PCC 進(jìn)行 Zoom 時(shí)，我們可以將數(shù)據(jù)包延遲的懲罰設(shè)置為高于使用 PCC 進(jìn)行 Netflix 時(shí)的懲罰。這將導(dǎo)致更傾向于最小化延遲的行為，正如 Zoom 所青睞的那樣，即使這是以降低帶寬利用率為代價(jià)的，而帶寬對(duì) Netflix 來(lái)說更為重要。?

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

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

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

PCC 在線速率選擇

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

這是它的工作原理。就像 TCP 和 BBR 一樣，PCC 以慢啟動(dòng)模式開始，并在每個(gè) RTT 中加倍速率。這一直持續(xù)到效用分?jǐn)?shù)停止上升；這表明 PCC 將速率提高了太多，從而導(dǎo)致性能下降。此時(shí)，PCC 進(jìn)入擁塞避免模式。

現(xiàn)在，假設(shè) PCC 以特定速率 r 發(fā)送。確定它是否應(yīng)該增加或減少其速率的簡(jiǎn)單方法如下。PCC 可以以略高于 r 的2% 的速率發(fā)送并檢查派生的效用值，然后以略低于 r 的 2% 的速率發(fā)送，并再次檢查派生的效用。在評(píng)估以更高和更低的速率發(fā)送如何影響性能（即效用值）之后，PCC 可以切換到更低或更高的速率，這取決于哪個(gè)產(chǎn)生了最高的性能分?jǐn)?shù)。

不需要逆向工程

這種調(diào)整發(fā)送速率的算法的 PCC 的最早變體被稱為PCCAllegro. 雖然很簡(jiǎn)單，但它避免了 TCP 的一些不足?？紤]發(fā)送方遇到與擁塞無(wú)關(guān)的數(shù)據(jù)包丟失的情況。例如，假設(shè)每 100 個(gè)數(shù)據(jù)包中有 1 個(gè)被丟棄，無(wú)論您發(fā)送數(shù)據(jù)的速度有多快。在這里，提高發(fā)送速率不會(huì)增加丟失數(shù)據(jù)包的比例，但會(huì)導(dǎo)致更多數(shù)據(jù)包到達(dá)接收器并獲得更好的性能分?jǐn)?shù)。因此，PCC Allegro 將選擇提高其發(fā)送速率。相反，如果發(fā)送方由于擁塞而遇到丟包，那么提高速率只會(huì)導(dǎo)致更多的丟包，而不會(huì)獲得更多流量，從而導(dǎo)致性能下降。所以這時(shí)，PCC Allegro 將因此選擇降低其發(fā)送速率?；叵胍幌?#xff0c;無(wú)論丟包的原因如何，TCP 都會(huì)降低其發(fā)送速率， ?

與 BBR 不同，PCC 算法不會(huì)嘗試確定為什么較高的速率比較低的速率更好，反之亦然。發(fā)送方不會(huì)嘗試對(duì)網(wǎng)絡(luò)條件進(jìn)行逆向工程，例如通過明確推理經(jīng)歷的數(shù)據(jù)包丟失的可能原因。相反，發(fā)送方將網(wǎng)絡(luò)視為一個(gè)黑匣子，只是試圖了解其當(dāng)前速率的哪些變化將帶來(lái)最佳性能。?

?

對(duì) PCC Allegro 的改進(jìn)

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

例如，下面的圖 15 顯示了一種 PCC 算法，該算法以 1% 的小步長(zhǎng)降低發(fā)送速率。假設(shè)發(fā)送方最初以 r 的速率發(fā)送，該速率遠(yuǎn)高于網(wǎng)絡(luò)帶寬 R。由于發(fā)送速率明顯高于網(wǎng)絡(luò)所能支持的速率，因此會(huì)出現(xiàn)大量丟包和/或包延遲. 這些損失和延遲將繼續(xù)，而速率以微小的增量緩慢下降，直到再次達(dá)到帶寬閾值?；蛘?#xff0c;如果當(dāng)前發(fā)送速率遠(yuǎn)低于可用帶寬，則每次將發(fā)送速率提高 1% 可能需要很長(zhǎng)時(shí)間才能達(dá)到合適的帶寬利用率。

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

更先進(jìn)的 PCC 速率控制方案建立在機(jī)器學(xué)習(xí)和博弈論的豐富文獻(xiàn)基礎(chǔ)之上，以解決這個(gè)問題。PCC Vivace 是一種比 PCC Allegro 更能響應(yīng)網(wǎng)絡(luò)變化并具有更好收斂速度的方案的例子。?

無(wú)模型方法的好處

正如我們上面所討論的，依賴于對(duì)網(wǎng)絡(luò)的強(qiáng)假設(shè)的擁塞控制解決方案，如 TCP 和 BBR，當(dāng)他們的網(wǎng)絡(luò)模型偏離現(xiàn)實(shí)時(shí)，很容易導(dǎo)致性能不佳。由于其無(wú)模型方法避免了任何假設(shè)，PCC 在響應(yīng)網(wǎng)絡(luò)條件的意外變化方面更加穩(wěn)健。這些變化是現(xiàn)實(shí)世界環(huán)境中的情況，尤其是在最后一英里。?

在一個(gè)簡(jiǎn)單的對(duì)照實(shí)驗(yàn)中，我們比較了 BBR 和 PCC 在反映混亂最后一英里不可預(yù)測(cè)變化的情況下。我們的延遲、可用帶寬和數(shù)據(jù)包丟失每秒都在變化。下圖顯示了對(duì) PCC 和 BBR 的影響，以及理想的帶寬利用率。

在圖表上：

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

• 點(diǎn)劃線表示 PCC

• 實(shí)線顯示 BBR

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

10

PART

結(jié)論：擁塞控制的未來(lái)

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

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

---

講師招募

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

超強(qiáng)干貨來(lái)襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。