說是tcp擁塞控制，其實也不是，歸根到底bbr是協議無關的擁塞控制演算法，quic也使用。quic當道，低延遲，高效，適配http2，應用層易部署；而bbr發布前，也已經在google和youtube證明了其在吞吐和延遲上優良的效能，只服務端部署，完美適配需要下行高吞吐低延遲的場景。
基於丟包的擁塞控制演算法，來說標準tcp擁塞控制存在的問題。標準tcp將網路丟包的原因歸結為擁塞，而忽略鏈路錯誤造成的丟包，這在高速網路環境中是不可取的。而傳統的擁塞控制演算法為了保證其公平性，採用了「加性增乘性減」（aimd）擁塞控制思想，一旦丟包發生，視窗便被大幅度減少，這使得在存在丟包的高速環境中，即使理論頻寬再大，實際頻寬最終只能收斂到乙個小值。
另一點，關於網路中的bufferbloat問題（緩衝區膨脹，tcpip卷一中有相關解釋）。現代網路中間裝置（路由器、防火牆）為解決流量突發問題（短時收速率大於傳送速率），都存在較大的流量快取功能，快取佇列的增加將導致報文rtt變大。傳統擁塞控制演算法因不具備主動探測能力，為了獲取最大頻寬，將不斷增大視窗大小直至網路快取飽和，所以它的收斂狀態是乙個網路快取飽和的狀態，這使得報文延遲巨大。即使在視窗不大的情況下，因為傳統演算法並不對傳送速率做限制，所以小的視窗狀態下仍可能因為突發流量使網路快取飽和。
上圖展示了rtt、傳送速率和傳送資料大小的關係：
下面看一下bbr對標準tcp問題的解決方式：
當頻寬增加一倍時，因為bbr的probe_bw階段會週期性的嘗試探測更多頻寬，每個週期為8個往返時間，每個週期增長1 / 4，所以，如果頻寬從10mb增長到20mb，那麼需要約3個週期，使頻寬收斂至增長後的頻寬大小。可以看到，20s時，因為頻寬的增長使連線探測到更大的頻寬，所以之後的幾個rtt內，bw的增長使inflight不斷的膨脹，最終在約3個週期後達到最大頻寬收斂。
當頻寬減小一半時，因為頻寬的計算使用一段滑動視窗時間內最大值的原因，bbr使用的頻寬值並沒有直接減小，所以在40s時，因為傳送速率過大緩衝區膨脹，造成inflight和rtt激增。當滑動視窗移動，頻寬縮減後的頻寬測量值成為計算值之後，重新計算的cwnd小於inflight，這才使網路流量被排空，網路逐漸收斂。
因為probe_bw狀態增益係數的存在，會使得大流不斷出讓頻寬給小流，最終達到乙個公平狀態。
同時，因為新流的加入，會使得網路佇列開始被填充，這將造成已有連線在一段時間內都無法測量到最小rtt，從而進入probe_rtt狀態。在這個狀態中，cwnd會被設定為4個mss，這將使得網路被排空，而已有大流連線排空的資源，將會被新流共享並最終收斂，這就是bbr的公平性。
[1]neal cardwell, yuchung cheng, c. stephen gunn, soheil hassas yeganeh, van jacobson.bbr: congestion-based congestion control.
[2]dog250.來自google的tcp bbr擁塞控制演算法解析.
[3]dog250.google』s bbr tcp擁塞控制演算法的四個變速引擎.
tcp擁塞控制演算法 WebRTC擁塞控制原理解析
webrtc包含三種擁塞控制演算法，gcc bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack sack，輸出為擁塞視窗 congestion window 傳送速度 pacing rate bbr是怎樣運用到udp，甚至運用到實時流 傳輸之上的？拜讀一下在webrt...
TCP協議 擁塞控制演算法
網路擁塞控制演算法 tcp的擁塞控制主要原理依賴於乙個擁塞視窗來控制，在之前我們還討論過tcp還有乙個對端通告的接收視窗用於流量控制。視窗值得大小就代表能夠傳送出去的但還沒有接收到ack的最大資料報文段，顯然視窗越大那麼資料傳送的速度也就越快，但是也有越可能使得網路出現擁塞，如果視窗值為1，那麼就簡...
TCP擁塞控制 慢開始與擁塞避免演算法
計算機網路中的頻寬 交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是乙個全域性性的過程，和流量控制不同，流量...