前言

在最初介紹 QUIC 優點時有提到 QUIC 實現在 user space 的其中一個優點是擁塞控制時，比起 TCP 實現在 kernel space 有更高的靈活性，在開發或者根據場景調整不同的策略都比 TCP 來的靈活，這兩天就來花一點篇幅講一下 BBR(Bottleneck Bandwidth and Round-trip propagation time) 這個 2016 才被 google 發表的擁塞控制演算法，在 google 的實驗中，被證實可以有效提高整體的網路吞吐量，以擁塞控制演算法長久的發展歷史來看，BBR 也能說是非常新的演算法。

Linux kernel v4.9 版本以後也將 BBR 移植到了 kernel 內部，用戶可以手動選擇自己偏好的擁塞控制演算法，可以用 sysctl net.ipv4.tcp_available_congestion_control 查看自己系統目前支援的演算法

ngtcp2 中目前支援四種擁塞控制演算法: reno, cubic, bbr, bbrv2

目前 ngtcp2 默認的演算是 cubic，不過也可以手動調整成 bbr

簡介

BBR 在設計理念上與之前的前輩們有所不同，像是大名鼎鼎的 Reno, Cubic 這些擁塞控制演算法都是基於丟失的擁塞控制，他們認為丟失的發生就代表整個線路發生了壅塞，這套設計理念其實效果還不錯，至少從 1980 年開始陸續開發的幾個演算法都沒有什麼大缺點。

但基於丟失的演算法在 1980 年代發展時幾乎所有的網路都是有線網路，那時候丟失跟擁塞發生幾乎可以劃上等號，但近代由於行動網路的發展，網路頻寬也不同以往，這時候的丟失跟壅塞的發生不一定是相等的，行動網路的封包丟失也有可能是傳送發生錯誤導致，像是訊號不好等等，所以 BBR 的設計上就沒有採用丟失封包 = 壅塞的理念。