基于包丟失檢測的 Reno、NewReno 或者 cubic 為代表，其主要問題有 Buffer bloat 和長肥管道兩種。和這些算法不同，bbr 算法會以時(shí)間窗口內(nèi)的最大帶寬 max_bw 和最小 RTT min_rtt，并以此計(jì)算發(fā)送速率和擁塞窗口

RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 算法關(guān)于擁塞窗口的核心就是計(jì)算 BtlBW 和 RTprop，根據(jù)這兩者值計(jì)算 BDP

bbr 算法輸出 pacing_rate 和 cwnd 兩個(gè)數(shù)據(jù)。pacing_rate 決定發(fā)包速率，cwnd 為窗口大小

TCP Tahoe 和 Reno

這兩個(gè)算法是根據(jù)其第一次加入到4.3BSD的時(shí)間回溯命名的，兩個(gè)名字對應(yīng)自其第一次出現(xiàn)時(shí)BSD的代號，而代號分別取自太浩湖（Lake Tahoe）和其附近的城市里諾市

? Tahoe：如果收到三次重復(fù)確認(rèn)——即第四次收到相同確認(rèn)號的分段確認(rèn)，并且分段對應(yīng)包無負(fù)載分段和無改變接收窗口——的話，Tahoe算法則進(jìn)入快速重傳，將慢啟動閾值改為當(dāng)前擁塞窗口的一半，將擁塞窗口降為1個(gè)MSS，并重新進(jìn)入慢啟動階段

? Reno：如果收到三次重復(fù)確認(rèn)，Reno算法則進(jìn)入快速重傳，只將擁塞窗口減半來跳過慢啟動階段，將慢啟動閾值設(shè)為當(dāng)前新的擁塞窗口值，進(jìn)入一個(gè)稱為“快速恢復(fù)”的新設(shè)計(jì)階段

Fast recovery

是Reno算法新引入的一個(gè)階段，在將丟失的分段重傳后，啟動一個(gè)超時(shí)定時(shí)器，并等待該丟失分段包的分段確認(rèn)后，再進(jìn)入擁塞控制階段。如果仍然超時(shí)，則回到慢啟動階段

TCP Vegas

至1990年代中期，TCP量度延遲和RTT都是以傳輸緩存中最后一個(gè)被傳送的分段包為準(zhǔn)。vegas通過度量傳輸緩存中每個(gè)傳送分段包來代替只量度一個(gè)分段包，通過每次度量的平均值來增加擁塞窗口。該算法取名自內(nèi)華達(dá)州最大的城市拉斯維加斯。不過由于一些資源公平性原因，該算法并沒有在彼得森的實(shí)驗(yàn)室之外廣泛部署。一些研究認(rèn)為該算法和其他擁塞算法混合使用，可能會導(dǎo)致性能競爭不及其他算法。在各種TCP擁塞算法的比較研究中，Vegas被認(rèn)為是最平滑的控制算法，其次為CUBIC

TCP New Reno

TCP New Reno是對TCP Reno中快速恢復(fù)階段的重傳進(jìn)行改善的一種改進(jìn)算法，其定義于RFC 6582，覆蓋了原有在RFC 3782和RFC 2582的舊定義。

在Reno的快速恢復(fù)中，一旦出現(xiàn)3次重復(fù)確認(rèn)，TCP發(fā)送方會重發(fā)重復(fù)確認(rèn)對應(yīng)序列號的分段并設(shè)置定時(shí)器等待該重發(fā)分段包的分段確認(rèn)包，當(dāng)該分段確認(rèn)包收到后，就立即退出快速恢復(fù)階段，進(jìn)入擁塞控制階段，但如果某個(gè)導(dǎo)致重復(fù)確認(rèn)的分段包到遇到重復(fù)確認(rèn)期間所發(fā)送的分段包存在多個(gè)丟失的話，則這些丟失只能等待超時(shí)重發(fā)，并且導(dǎo)致?lián)砣翱诙啻芜M(jìn)入擁塞控制階段而多次下降。而New Reno的快速恢復(fù)中，一旦出現(xiàn)3次重復(fù)確認(rèn)，TCP發(fā)送方先記下3次重復(fù)確認(rèn)時(shí)已發(fā)送但未確認(rèn)的分段的最大序列號，然后重發(fā)重復(fù)確認(rèn)對應(yīng)序列號的分段包。如果只有該重復(fù)確認(rèn)的分段丟失，則接收方接收該重發(fā)分段包后，會立即返回最大序列號的分段確認(rèn)包，從而完成重發(fā)；但如果重復(fù)確認(rèn)期間的發(fā)送包有多個(gè)丟失，接收方在接收該重發(fā)分段后，會返回非最大序列號的分段確認(rèn)包，從而發(fā)送方繼續(xù)保持重發(fā)這些丟失的分段，直到最大序列號的分段確認(rèn)包的返回，才退出快速恢復(fù)階段。

New Reno在低錯(cuò)誤率時(shí)運(yùn)行效率和“選擇確認(rèn)”（Selective ACKnowledgement，SACK）相當(dāng)，在高錯(cuò)誤率仍優(yōu)于Reno

TCP Hybla

TCP Hybla旨在消除由于高延遲地面線路或者衛(wèi)星無線鏈路下導(dǎo)致的RTT過長而對TCP鏈接的影響。它通過對擁塞窗口動態(tài)分析來修改，來減少對RTT的性能依賴

TCP BIC 和 CUBIC

TCP BIC（Binary Increase Congestion control）旨在優(yōu)化高速高延遲網(wǎng)絡(luò)（即根據(jù)RFC 1072所定義的“長肥網(wǎng)絡(luò)”（long fat network，LFN））的擁塞控制，其擁塞窗口算法使用二分搜索算法嘗試找到能長時(shí)間保持擁塞窗口最大值的值。Linux內(nèi)核在2.6.8至2.6.18使用該算法作為默認(rèn)TCP擁塞算法。

CUBIC則是比BIC更溫和和系統(tǒng)化的分支版本，其使用三次函數(shù)代替二分算法作為其擁塞窗口算法，并且使用函數(shù)拐點(diǎn)作為擁塞窗口的設(shè)置值。Linux內(nèi)核在2.6.19后使用該算法作為默認(rèn)TCP擁塞算法

TCP Westwood和Westwood+

TCP Westwood改良自New Reno，不同于以往其他擁塞控制算法使用丟失來測量，其通過對確認(rèn)包測量來確定一個(gè)“合適的發(fā)送速度”，并以此調(diào)整擁塞窗口和慢啟動閾值。其改良了慢啟動階段算法為“敏捷探測（Agile Probing）”，和設(shè)計(jì)了一種持續(xù)探測擁塞窗口的方法來控制進(jìn)入“敏捷探測”，使鏈接盡可能地使用更多的帶寬。Westwood+使用更長的帶寬估計(jì)間隔和優(yōu)化的濾波器來修正Westwood對ACK壓縮場景對帶寬估計(jì)過高的問題。通過以上改良，TCP Westwood系列算法在有線網(wǎng)絡(luò)和無線網(wǎng)絡(luò)的擁塞控制上獲取平衡，尤其研究中針對于無線通信網(wǎng)絡(luò)上

Compound TCP

復(fù)合TCP（Compound TCP）是微軟自己實(shí)現(xiàn)的TCP擁塞控制算法，通過同時(shí)維護(hù)兩個(gè)擁塞窗口，來實(shí)現(xiàn)在長肥網(wǎng)絡(luò)有較好的性能而又不損失公平性。該算法在Windows Vista和Windows Server 2008開始廣泛部署，并通過補(bǔ)丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一個(gè)舊版本的移植實(shí)現(xiàn)

TCP PRR

TCP PRR（TCP Proportional Rate Reduction ）是旨在恢復(fù)期間提高發(fā)送數(shù)據(jù)的準(zhǔn)確性。該算法確保恢復(fù)后的擁塞窗口大小盡可能接近慢啟動閾值。在Google進(jìn)行的測試中，能將平均延遲降低3~10%，恢復(fù)的超時(shí)減少5%。PRR算法之后作為Linux內(nèi)核3.2版本的默認(rèn)擁塞算法

TCP BBR

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google設(shè)計(jì)，于2016年發(fā)布的擁塞算法。以往大部分擁塞算法是基于丟包來作為降低傳輸速率的信號，而BBR則基于模型主動探測。該算法使用網(wǎng)絡(luò)最近出站數(shù)據(jù)分組當(dāng)時(shí)的最大帶寬和往返時(shí)間來創(chuàng)建網(wǎng)絡(luò)的顯式模型。數(shù)據(jù)包傳輸?shù)拿總€(gè)累積或選擇性確認(rèn)用于生成記錄在數(shù)據(jù)包傳輸過程和確認(rèn)返回期間的時(shí)間內(nèi)所傳送數(shù)據(jù)量的采樣率。該算法認(rèn)為隨著網(wǎng)絡(luò)接口控制器逐漸進(jìn)入千兆速度時(shí)，與緩沖膨脹相關(guān)的延遲相比丟包更應(yīng)該被認(rèn)為是識別擁塞的主要決定因素，所以基于延遲模型的擁塞控制算法（如BBR）會有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞算法，例如CUBIC

QUIC Quick UDP Internet Connections

QUIC旨在提供幾乎等同于TCP連接的可靠性，但延遲大大減少。它主要通過兩個(gè)理解HTTP流量的行為來實(shí)現(xiàn)這一點(diǎn)：

第一個(gè)變化是在連接創(chuàng)建期間大大減少開銷。由于大多數(shù)HTTP連接都需要TLS，因此QUIC使協(xié)商密鑰和支持的協(xié)議成為初始握手過程的一部分。 當(dāng)客戶端打開連接時(shí)，服務(wù)器響應(yīng)的數(shù)據(jù)包包括將來的數(shù)據(jù)包加密所需的數(shù)據(jù)。

QUIC使用UDP協(xié)議作為其基礎(chǔ)，不包括丟失恢復(fù)。相反，每個(gè)QUIC流是單獨(dú)控制的，并且在QUIC級別而不是UDP級別重傳丟失的數(shù)據(jù)。這意味著如果在一個(gè)流中發(fā)生錯(cuò)誤，協(xié)議棧仍然可以獨(dú)立地繼續(xù)為其他流提供服務(wù)

QUIC包括許多其他更普通的更改，這些更改也可以優(yōu)化整體延遲和吞吐量

每個(gè)數(shù)據(jù)包是單獨(dú)加密的，因此加密數(shù)據(jù)時(shí)不需要等待部分?jǐn)?shù)據(jù)包。 在TCP下通常不可能這樣做，其中加密記錄在字節(jié)流中，并且協(xié)議棧不知道該流中的更高層邊界。這些可以由運(yùn)行在更上層的協(xié)議進(jìn)行協(xié)商，但QUIC旨在通過單個(gè)握手過程完成這些

QUIC的另一個(gè)目標(biāo)是提高網(wǎng)絡(luò)切換期間的性能，例如當(dāng)移動設(shè)備的用戶從WiFi熱點(diǎn)切換到移動網(wǎng)絡(luò)時(shí)發(fā)生的情況。 當(dāng)這發(fā)生在TCP上時(shí)，一個(gè)冗長的過程開始了：每個(gè)現(xiàn)有連接一個(gè)接一個(gè)地超時(shí)，然后根據(jù)需要重新創(chuàng)建。期間存在較高延遲，因?yàn)樾逻B接需要等待舊連接超時(shí)后才會創(chuàng)建。 為解決此問題，QUIC包含一個(gè)連接標(biāo)識符，該標(biāo)識符唯一地標(biāo)識客戶端與服務(wù)器之間的連接，而無論源IP地址是什么。這樣只需發(fā)送一個(gè)包含此ID的數(shù)據(jù)包即可重新創(chuàng)建連接，因?yàn)榧词褂脩舻腎P地址發(fā)生變化，原始連接ID仍然有效

QUIC在應(yīng)用程序空間中實(shí)現(xiàn)，而不是在操作系統(tǒng)內(nèi)核中實(shí)現(xiàn)。當(dāng)數(shù)據(jù)在應(yīng)用程序之間移動時(shí)，這通常會由于上下文切換而調(diào)用額外的開銷。 但是在QUIC下協(xié)議棧旨在由單個(gè)應(yīng)用程序使用，每個(gè)應(yīng)用程序使用QUIC在UDP上托管自己的連接

Chromium的網(wǎng)絡(luò)堆棧同時(shí)打開QUIC和傳統(tǒng)TCP連接，并在QUIC連接失敗時(shí)以零延遲回退到TCP連接