前段時間，老板發了篇資料，下面是我學習的相關記錄整理。

https://aws.amazon.com/cn/blogs/china/talking-about-network-optimization-from-the-flow-control-algorithm/

PS：ubuntu24默認使用的tcp控制算法。還是 cubic

sysctl net.ipv4.tcp_available_congestion_control
# net.ipv4.tcp_available_congestion_control = reno cubic
sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = cubic

代碼地址：https://github.com/google/bbr

安裝使用 BBR v3

https://github.com/google/bbr/blob/v3/README.md

Viewing the TCP BBR v3 sources

You can view the current sources here:
tcp_bbr.c

Obtaining kernel sources with TCP BBR v3

There are two main options for downloading the code:

1. To create a new git repo starting from a Linux kernel with TCP BBR v3,
   you can run:

git clone -o google-bbr -b v3  https://github.com/google/bbr.git
cd bbr/

2. To download the code into an existing git repo, you can use:

git remote add google-bbr https://github.com/google/bbr.git
git fetch google-bbr
git checkout google-bbr/v3

Note that if you already have a git repo that has imported the Linux source
tree, then the second option will be much faster and use much less space, since
it will only need to download the small deltas relative to the mainline Linux
source distribution.

Building and installing the kernel

To build a Linux kernel with TCP BBR v3 support, copy that kernel to a target
(Debian or Ubuntu) test machine (bare metal or GCE), and reboot that machine,
you can use the following script, included in the TCP BBR v3 distribution:

./gce-install.sh -m ${HOST}

Checking the kernel installation

Once the target test machine has finished rebooting, then ssh to the target
test machine and become root with sudo or equivalent. First check that the
machine booted the kernel you built above:

uname -a

You should see the branch name SHA1 hash, and build time stamp from the kernel
you built above.

Then check what congestion control modules are available with:

sysctl net.ipv4.tcp_available_congestion_control

You should see something like:

net.ipv4.tcp_available_congestion_control = reno bbr cubic dctcp

Install test dependencies

Next, copy the test scripts to the target test machine with:

scp -r gtests/net/tcp/bbr/nsperf/ ${HOST}:/tmp/

Before running the tests for the first time, as a one-time step you’ll need to
install the dependencies on the test machine, as root:

mv /tmp/nsperf /root/
cd /root/nsperf
./configure.sh

Running TCP BBR v3 tests and generating graphs

To run the tests, ssh to the target test machine and become root with sudo or
equivalent. Then run the tests and generate graphs with:

cd /root/nsperf
./run_tests.sh
./graph_tests.sh

This will run for hours, and place the graphs in the ./graphs/ directory.

You can run and graph a subset of the tests by specifying the test by name as
an environment variable. For example:

cd /root/nsperf
tests=random_loss ./run_tests.sh
tests=random_loss ./graph_tests.sh

WebRTC上改進的一些可能

BBR v3 與 WebRTC 的結合場景

WebRTC 的核心傳輸層通常使用 UDP（如音視頻流通過 RTP 傳輸），但某些場景可能依賴 TCP 或 QUIC（如數據通道通過 SCTP over QUIC）。BBR v3 的適用場景包括：

• 基于 QUIC 的傳輸：QUIC 協議內置擁塞控制（如 BBR），可替代傳統 TCP。
• TURN/TCP 中繼：當 WebRTC 通過 TURN 服務器使用 TCP 傳輸時，可啟用 BBR v3。
• 用戶態擁塞控制：在應用層實現 BBR 邏輯（如通過自定義網絡棧）。

TURN/TCP 中繼

• 對于基于 TCP 的傳輸（如 TURN 中繼），設置擁塞控制算法為 BBR：

sysctl -w net.ipv4.tcp_congestion_control=bbr

# TURN 服務器配置（coturn）
listening-port=3478
relay-threads=8
lt-cred-mech
use-auth-secret
congestion-control=bbr

• 對于 QUIC 傳輸，需使用支持 BBR 的 QUIC 實現（如 Google 的 quiche）。
• QUIC 兼容性：需 QUIC 庫明確支持 BBR（如 Cloudflare quiche 支持 BBRv1）。

用戶態 BBR v3 使用與借鑒

• 自定義傳輸協議：在 WebRTC 的數據通道（DataChannel）中，使用基于 UDP 的自定義協議，并在應用層實現 BBR v3 算法。
• QUIC 集成：通過 QUIC 庫（如 lsquic）啟用 BBR，替代 WebRTC 默認的傳輸層。
• 針對 WebRTC 的低延遲需求調整 BBR 參數（如減少探測帶寬的頻率）。

// 在 QUIC 連接中設置 BBR 擁塞控制
quic_conn_params params;
params.cc_algorithm = QUIC_CC_ALGORITHM_BBR_V3;
quic_connection_create(&params);// WebRTC 數據通道通過 QUIC 傳輸
webrtc::DataChannelParameters channel_params;
channel_params.protocol = "quic";
peer_connection->CreateDataChannel("bbr_channel", &channel_params);

背景知識

https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster

BBR 的核心優化在于 將擁塞控制從被動響應丟包轉變為主動建模網絡路徑，通過精準測量帶寬和 RTT，實現高吞吐、低延遲、強魯棒性的網絡傳輸。BBRv2 進一步解決了公平性和穩定性問題，成為下一代互聯網傳輸協議的重要候選方案。

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 提出的一種基于網絡擁塞模型的流量控制算法，旨在更高效地利用網絡帶寬并降低延遲。與傳統的基于丟包的算法（如 CUBIC）不同，BBR 通過主動測量網絡路徑的帶寬和傳播時延（RTT），動態調整發送速率，優化網絡性能。以下是 BBR 的核心優化點：

1. 基于帶寬與時延的擁塞控制模型

• 傳統算法的缺陷：CUBIC 等算法通過檢測丟包來判斷網絡擁塞，但丟包往往發生在網絡緩沖區已滿時（此時延遲已顯著增加）。

• BBR 的改進：

  • 主動測量帶寬和 RTT：BBR 通過持續測量最大帶寬（BtlBw）和最小 RTT（RTprop），計算網絡路徑的帶寬時延積（BDP = BtlBw × RTprop），以此作為發送速率的理論上限。
  • 避免緩沖區填塞：通過控制發送速率不超過 BDP，減少數據包在中間路由器緩沖區（Buffer）中的堆積，從而降低排隊延遲（避免 Bufferbloat）。

2. 狀態機驅動的速率調整

BBR 通過以下四個狀態機動態調整發送行為：

• Startup：快速探測最大帶寬（指數級增速），類似傳統慢啟動。
• Drain：排空 Startup 階段可能導致的緩沖區堆積，降低發送速率。
• ProbeBW：周期性小幅增減速率（±25%），探測當前帶寬是否變化。
• ProbeRTT：周期性降低發送窗口，主動測量最小 RTT（避免過時的 RTT 估計）。

這種狀態機機制使得 BBR 能更快適應網絡變化，同時保持高吞吐量和低延遲。

3. 抗丟包能力強

• 傳統問題：CUBIC 在丟包時大幅降低發送速率，導致帶寬利用率下降。

• BBR 的優化：

  • 不依賴丟包作為擁塞信號，而是基于帶寬和 RTT 的變化調整速率。
  • 即使發生丟包（如隨機無線丟包），BBR 僅略微降低速率，避免過度保守。

4. 降低延遲與提高公平性

• 減少排隊延遲：通過控制發送速率不超過 BDP，避免緩沖區溢出，顯著降低 RTT。
• 公平性優化：BBRv2 進一步改進了與傳統算法（如 CUBIC）的共存公平性，減少因搶占帶寬導致的競爭失衡。

5. BBRv2 的改進

BBRv1 主要解決了高帶寬利用率與低延遲的矛盾，而 BBRv2 在此基礎上進一步優化：

• 顯式擁塞通知（ECN）支持：利用網絡設備的 ECN 標記更早檢測擁塞。
• 抗突發流量干擾：在 ProbeRTT 階段更平滑地調整速率，避免性能抖動。
• 增強多流公平性：改進多條 BBR 流共享帶寬時的公平性。