2016 年 10 月份的一個 youtube 鏈接: Making Linux TCP Fast，首次發布了 BBR 算法， TCP 擁塞控制開啟了新局面。

BBR 非常簡單，它背后是一個單流理想模型：

但現實情況并不遵循該模型，所以 BBR 的表現很難兌現承諾，特別在多流場景，公平性難保證，高重傳換吞吐頻繁發生。

下面是一個過程示意圖：

該表現的根本原因是 “BBR 必須用更多的 inflight 探測潛在帶寬”。而 “更多的 inflight” 和 Loss-based 算法的 AI 過程無異，但卻沒有相應的 MD 反饋，這意味著 BBR 流的 inflight 很容易被拉到一個高水位。高水位的 inflight 很容易導致排隊甚至丟包，而這正是 BBR 目標的反面。

多流共享瓶頸帶寬，背景流的侵入和退出以及它們的 AIMD 易對 BBR 造成干擾，BBR 記錄瞬時探測收益，并堅持 10-rounds，這種遲鈍反應使 BBR 很難維持理想模型的狀態機。

BBR 必須考慮更接近現實的場景，對 inflight 進行約束，這就是 BBRv2 的背景。

下面的背景引用來自：Understanding of BBRv2

However, in multiple BBRv1 flows, each sender overestimates the available bandwidth because of the max_filter that is immediately applied as new sending rate; therefore, the total amount of data sent from BBR hosts exceeds the pipe’s capacity, resulting in the standing queue creation. If the buffer sizes are not large enough to store excess data, the packet loss occurs. Moreover, this packet loss persists throughout the entire bandwidth sharing of multiple BBRv1 flows because BBRv1 does not reduce the maximum boundary of the inflight data, no matter how much packet loss occurs. This maximum boundary of the above-mentioned inflight data is the inflight cap, calculated as 2 BDP, and it is used to maintain the maximum throughput and low latency.

BBRv2 的核心在于 “更精確地測量 Delivery rate，并根據丟包，ECN 信號約束 inflight”。為此，BBRv2 在 ProbeBW 狀態引入了一個子狀態機：

以下是約束細節，來自 BBRv2 draft：

下面是一個 BBRv2 的過程示意圖：

驅動 BBRv2 狀態機轉換的不再是固定的 phase，而完全基于 “丟包”，“ECN-Mark”，“公平性” 等變量 “隨時” 進行 probe up 或 probe down：

實時跟蹤丟包率與 ECN Mark，實時調整 inflight_hi/lo，限制實際 inflight。

實時跟蹤丟包率與 ECN Mark，輔以公平性保證，驅動子狀態機狀態轉換。

在 cruise 狀態，保留 headroom 作為 “公地奉獻”。

BBRv2 專門為 Reno/CUBIC 保留一個 AIMD 周期的時間窗口，該窗口等于 0.5*Max_cwnd = BDP 個 RTT 的時間(具體計算參考 Jacobson管道)，兩次 probe up 的時間不小于該窗口，同時在明確沒有因 probe up 造成丟包的前提下，又可繼續 probe up。

在上述窗口內，BBRv2 執行 cruise，對網絡不注入任何干擾，讓 Reno/CUBIC 安靜 AI，由于 BBR probe up 采用 MI，它只在時間窗口過后，一次性執行 MI，在理論上，BBRv2 和 Reno/CUBIC 具有了同樣的 probe 周期，建立了友好共存的基礎。

如 BBRv2 draft 4.3.3.5.1 小節所述，BBRv2 希望在 DC 和 Internet 都能和 Reno/CUBIC 友好共存，巧合的是，兩類網絡的典型 BDP 是一致的：

DC 網絡：40 Gbps / 8 bits-per-Byte * 20 us / (1514 Bytes) ~= 66 packets

Internet：25Mbps / 8 bits-per-Byte * 30 ms / (1514 bytes) ~= 62 packets

probe up 之后大約 60 多個 RTT，BBRv2 便可友好地再次 probe up，這個時間在 Internet 大約 2 secs，在 DC 網絡大約 1.3 ms。該 Time Scale 不包含固定經驗值，它是 rounds 的函數，自適應各類網絡。這是一個事實上可靠的 BBR/Reno 共存保證。

和 BBRv1 的固定 8-rounds 一輪相比，BBRv2 probe up 間隔時間久了很多。策略是個好策略，但在我看來，現實場景中，都是異步流，BDP 個 RTT 的 AIMD 周期屬高斯分布的右尾，取其期望均值是高尚的，大約 30～40 個 RTT 很合理。

最近看的一本書《系統之美》，提到 “有限理性” 一詞，也叫 “看不見的腳”，和 亞當斯密 的 “看不見的手” 相對。“有限理性” 這個概念完全適用于多流共享帶寬的場景，“有限理性” 的后果就是 “公地悲劇”，各方都在自私地獲利，最終卻分擔惡果，這顯然對每一方都有利。TCP AIMD 可以完美應對 “公地悲劇”，可 BBRv1 并不能。

在一個有限資源的系統中，BBRv2 越來越多地反饋外界背景事件，這是進步，而 BBRv1 似乎很少具有全局觀，結合《系統之美》，BBRv2 正行走在突破 “公地悲劇” 的正確道路上。

單流吞吐雖下降，換取整體效果向善。

有了 TCP 友好性作為基礎，和 Reno/CUBIC 整齊劃一之后，BBRv2 便擁有了長期演進的可能性，最終作為 CUBIC 的接力者成為默認標準算法。相比之下，BBRv1 僅僅提供了一個新的思路，但它并沒有為實際部署以及與傳統 TCP 流共存做好準備。

但直到 Linux Kernel v6.1-rc2，也依然不見 BBRv2 合入(相比較而言，BBRv2 在 QUIC 上的進度卻快很多)，它依然僅存在于 Google 自己的分支：https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c

工作中涉及到 DC 內部 TCP cc 演進的問題討論，對于短突發，傾向于調大 init cwnd 為一個 BDP 左右，傾向于復用長連接，start from idle 的 cwnd 為 init cwnd。對于長流，傾向于 BBRv2，它確實比 DCTCP 更具有適應性，且包含了 DCTCP 的 feature。記錄一篇，這篇可作為資料查詢，因為形而上的東西不太多(但依然有)。

編輯：黃飛

?