TCP BBR
/ BBR: bee-bee-AR /
我們目前遇到的每一個壅塞控制器，都是等到出了事——一個遺失的封包——才退讓。那就像開車要等到刮到路緣才打方向盤閃開。BBR，是 Bottleneck Bandwidth and Round-trip propagation time（瓶頸頻寬與往返傳播時間）的縮寫，採取不同的做法：它不對遺失做反應，而是替路徑建立一個動態的模型，並試圖以恰好「填滿管線卻清空佇列」的速率傳送。它由 Google 開發，並大量用於 Google 自家的服務。
這個模型立基於兩個量測。第一個是瓶頸頻寬：BBR 最近觀察到的最大送達速率，用以估計路徑上最慢那條連結的容量。第二個是它最近看到的最小往返時間，用以估計在沒有佇列堆積時這條路徑的延遲。把這兩者相乘，你就得到頻寬延遲乘積——也就是恰好應該在途、能讓瓶頸保持忙碌而又不在任何緩衝區裡堆積的資料量。BBR 把它的傳送速率調得與估計的頻寬相符，並讓在途資料維持在那個理想值附近，週期性地往上多探一點，看看是否出現了更多頻寬，並偶爾讓佇列排空，以重新量測真正的最小 RTT。
因為 BBR 的目標是讓緩衝區幾乎清空、而非填滿，它能以遠低於基於遺失控制器的延遲，提供高吞吐量——這是對緩衝膨脹的直接打擊——而且它遠不容易被隨機的無線遺失所騙，因為單憑遺失並不會讓它退讓。誠實的提醒：BBR 較早的版本在與 CUBIC 這類基於遺失的流競爭時可能不公平（有時太激進，有時被餓死），而在條件快速變動下把模型估準確實很難。它是一個重要的、基於模型的替代方案——而非一個已塵埃落定、放諸四海皆更優的取代品。
在一條 100 Mbps、最小 RTT 40 毫秒的連結上，BBR 估計恰當的在途量約為 100 Mbps × 0.04 秒 = 0.5 百萬位元組（頻寬延遲乘積）。它把傳送速率調為 100 Mbps，並維持大約那麼多資料在途——填滿管線的同時讓路由器緩衝區幾乎清空，於是即使在全速下，這條連結上每個人的延遲都保持低。
BBR 以估計的瓶頸速率傳送，並讓在途資料維持在頻寬延遲乘積附近，使緩衝區保持清空。
BBR 是基於模型的，而非基於遺失的，這是它在易丟封包或過度緩衝路徑上的強項——但它並非已塵埃落定的贏家。早期 BBR 在與共用連結的 CUBIC 流相處時可能不公平，而在變動條件下調校頻寬／RTT 模型也很難；較新的版本（BBRv2／v3）加入了對遺失與 ECN 的回應來處理這點。把它當成一個有前景的選項，而非最終答案。