Google BBR TCP 擁塞控制演算法：四大變速引擎深度解析

四大變速引擎 (狀態機)

1. Startup (啟動/慢啟動) - 指數增長探測頻寬上限

• 目標：快速發現瓶頸頻寬
• 增益：gain = 2/ln(2) ≈ 2.89 (高增益)
• 行為：每 RTT 發送量按 gain 指數增長，直到連續 3 個 RTT max_bw 不再增長 (增長 < 25%)
• 退出條件：進入 Drain

2. Drain (排空) - 清空佇列回歸 min_rtt

• 目標：Startup 期間注入管道的額外資料 (in-flight > BDP) 排空
• 增益：gain = 1/2.89 ≈ 0.35 (低增益，發送量 < BDP)
• 行為：讓佇列排空，RTT 下降回 min_rtt
• 退出條件：in-flight ≤ BDP → 進入 ProbeBW

3. ProbeBW (探測頻寬) - 穩態週期性探測 (核心引擎)

• 目標：持續驗證頻寬是否變化、佇列是否堆積
• 增益週期：8 個 RTT 循環 [5/4, 3/4, 1, 1, 1, 1, 1, 1] (即 [1.25, 0.75, 1, 1, 1, 1, 1, 1])
• 機制：
  • 第 1 個 RTT (1.25)：「探測」 - 嘗試多發送 25%，若 max_bw 更新 → 頻寬變大
  • 第 2 個 RTT (0.75)：「排空」 - 少發送 25%，排空第 1 RTT 可能造成的佇列
  • 其餘 6 個 RTT (1.0)：「巡航」 - 維持 BDP 發送量
• 優勢：無丟包也能發現頻寬增長；頻寬下降時 max_bw 自然老化 (10 秒滑動窗口) 自動適應

4. ProbeRTT (探測最小 RTT) - 定期清空管道測真實傳播延遲

• 目標：長期運行中 min_rtt 可能過時 (路由變化、佇列管理改變)
• 觸發：超過 10 秒未更新 min_rtt
• 行為：進入 gain = 0.5 持續 ≥ 200ms (或 1 個 RTT)，發送量僅 BDP/2，強制清空瓶頸佇列
• 退出：取得新 min_rtt → 回 ProbeBW

關鍵創新總結

Linux 核心整合關鍵修改

BBR 實作 cong_control 回呼，核心 tcp_cong_control() 發現演算法註冊此回呼時，完全放手，不再執行傳統 tcp_cwnd_reduction/tcp_cong_avoid 邏輯。這是 BBR 能夠自主控制的制度基礎。