通用面試：如何解釋 BBR 與 CUBIC 的壅塞控制取捨？
題幹與適用情境
服務在高頻寬、長 RTT 或共享鏈路上出現吞吐不足與佇列延遲。團隊想把 Linux TCP 壅塞控制從 CUBIC 改為 BBR，卻擔心與現有流競爭、突發流量與不同核心版本的行為差異。請解釋機制並提出上線方案。
面試官考察重點
- 能否區分壅塞控制、可靠傳輸與應用重試的職責。
- 能否解釋基於丟包的視窗成長與基於頻寬、RTT 估計的發送速率控制。
- 能否識別佇列膨脹、共享鏈路公平性、應用受限與核心實作差異。
- 能否用真實工作負載、尾端延遲與回滾閘門驗證，而不是只看單次吞吐。
回答前要釐清的問題
- 流量是長連線大流、短 RPC，還是應用本身經常處於 app-limited？
- 鏈路瓶頸在哪裡，是否有多個租戶或不同壅塞演算法共享佇列？
- 核心、網卡卸載、佇列規則與可用的 BBR 版本是什麼？
- 目標是吞吐、p99 延遲、成本，還是在丟包網路中保持穩定？
- 是否能按主機、服務或連線比例灰度，並快速恢復原演算法？
30 秒回答框架
CUBIC 主要根據壅塞視窗與丟包回饋調速，成熟且在共享網路中行為可預期；BBR 估計瓶頸頻寬與最小 RTT，嘗試接近頻寬上限同時控制佇列。BBR 可能降低排隊延遲，但公平性、版本與工作負載依賴更強。我會先建立 CUBIC 基線，再按主機灰度 BBR，比較 goodput、p99 RTT、重傳、佇列長度、CPU、不同流的頻寬份額與錯誤率，並準備立即回滾。
分步深入解答
第一步：區分 TCP 的控制面
TCP 負責有序可靠交付，壅塞控制負責根據網路回饋限制發送速率，流量控制負責接收端能力。應用層逾時與重試不能取代壅塞控制；重試反而可能放大壅塞。
第二步：說明 CUBIC 的訊號與取捨
CUBIC 透過壅塞視窗與丟包等訊號判斷網路壅塞，視窗成長函數讓高頻寬長 RTT 鏈路更快恢復。優點是成熟、部署廣、與既有網路設備與調度策略經驗較多；缺點是通常等到丟包後才明顯收縮，可能形成較深佇列。
第三步：說明 BBR 的模型
BBR 用已觀測的交付速率估計瓶頸頻寬，用最小 RTT 估計傳播延遲，並以兩者計算頻寬延遲積來控制發送。它會在探測頻寬與排空佇列之間切換，目標是以較少丟包維持高 goodput。模型會受量測雜訊、應用受限與路徑變化影響。
第四步：討論公平性與佇列風險
不同壅塞演算法共享同一瓶頸時，頻寬份額不一定公平；BBR 版本、參數、佇列管理與流數都會影響結果。若發送速率估計偏高，可能增加佇列延遲。必須觀察每條流的份額與 RTT 分布，不能用總吞吐掩蓋某類流被擠壓。
第五步：設計實驗矩陣
涵蓋短 RPC、長下載、app-limited、不同 RTT、不同丟包率、單流與多流、同演算法與混合演算法。使用固定內容與相同主機基線，記錄 goodput、p50/p99 RTT、重傳、丟包、佇列深度、CPU 與完成時間。
第六步：按主機灰度與回滾
先在隔離環境啟用，再按單一服務、可用區或小比例主機灰度。核心與佇列設定納入版本，發布期間監控異常並自動暫停。若 p99 RTT、錯誤率、頻寬公平性或下游完成時間超過閾值，恢復原演算法並保留對比資料。
第七步：解釋結果邊界
BBR 的收益不能外推到所有路徑、核心與應用。CUBIC 的「成熟」也不代表在每條長 RTT 鏈路上最優。最終選擇應綁定工作負載、網路營運者、佇列管理與業務目標，並定期重測。
高品質示範回答
我會先說明職責：TCP 保證交付，壅塞控制調節發送，應用重試不能取代它。CUBIC 主要用壅塞視窗與丟包回饋，部署經驗成熟，但可能在丟包前累積較深佇列。BBR 根據交付速率估計瓶頸頻寬、用最小 RTT 估計傳播延遲，再以頻寬延遲積控制發送，可能降低排隊延遲，卻更依賴版本、佇列與混合流公平性。上線前我會固定主機與內容建立 CUBIC 基線，涵蓋長流、短 RPC、app-limited、不同 RTT、單流和混合演算法；灰度期間比較 goodput、p99 RTT、重傳、佇列、CPU、完成時間與每流頻寬份額。任何尾端延遲、錯誤率或公平性回歸都觸發自動回滾到 CUBIC。
常見錯誤
- 把 BBR 說成「完全不丟包」或把 CUBIC 說成只看頻寬。
- 用一次 iperf 吞吐結果取代多工作負載實驗。
- 忽略 app-limited 流、混合演算法與佇列管理器。
- 只監控總頻寬，不監控每流公平性與 p99 RTT。
- 修改 sysctl 後沒有確認核心、網卡與佇列設定是否實際生效。
- 沒有小比例灰度與可驗證的回滾路徑。
追問及應對
追問一：BBR 是否一定比 CUBIC 快？
不一定。收益依賴 RTT、頻寬、丟包、佇列、流數與應用是否受限。應先定義目標並用同條件實驗比較，而不是根據演算法名稱下結論。
追問二：為什麼要看最小 RTT？
它近似傳播延遲，幫助區分路徑本身延遲與排隊延遲。若基線被排隊污染，頻寬延遲積與佇列判斷都會偏差。
追問三：混合 BBR 與 CUBIC 會怎樣？
頻寬競爭可能不公平，結果取決於版本、佇列管理、流數與路徑。必須在共享瓶頸上測每流份額、RTT 與丟包，不能只看 BBR 自身吞吐。
追問四：短 RPC 也應該切換嗎？
先確認它們是否長期 app-limited，以及連線複用與握手占比。短請求的收益可能小於設定風險，應按服務灰度而非全局切換。
追問五：如何判斷是壅塞控制導致 p99 變差？
對照同一主機、路徑與應用版本，關聯 RTT、佇列深度、重傳、壅塞視窗與完成時間；同時排除 CPU、TLS、服務端排隊與應用重試變化。
追問六：回滾後還要做什麼？
確認新連線使用原演算法、舊連線是否需要重建，清理灰度設定，保留實驗資料並記錄觸發閾值。若問題來自佇列或核心而非演算法，修復根因後再安排獨立實驗。