ACM紙TCP BBRの導入に開口図1エントリポイントBBRアルゴリズムを説明するために、：
- なぜTCP輻輳制御アルゴリズムに基づいて、現在のパケットロス検出はまた、スペースを最適化？
- BBR最適化アルゴリズムの限界はどこ？
図1
私は全体の夜の時間を費やしたこのチャートを理解するために、それは、機内のデータは、それが簡単に議論し合うようになって、簡略化されている私は、すべての基本的な概念を再検討し、私はTCP RTT、帯域幅のために以下の定義を議論作ら物理的な直感が、それは最終的な結論には影響を与えません。
議論を簡単にするために、最初のシンボルの形で導入。我々はAからの送信データBの端部にTCPエンドを使用する場合、AとBとの間のネットワーク・リンクは複雑で動的であるが、我々は、いくつかに、ネットワークBにAを想像することができるブラックボックスのリンク、これを以下の物性値を有するリンク：
- RTprop：最小遅延のB端にA端からの光信号（実際には遅延2回、それは往復であるが、議論されていないので）、物理的な距離に応じて
- BtlBwは：BリンクにAにおいて、ボトルネック帯域幅と呼ばれる最も遅いリンク帯域幅の期間に依存するの帯域幅は、光ファイバの厚さのために考えられます
- BtlBufSizeは：BリンクにAでは、各ルータは独自のキャッシュを持っており、キャッシュの容量、ボトルネックのキャッシュサイズ
- BDP：データビットとの和を保存することができます（ルータキャッシュを除く）全体の物理リンク、BDP = BtlBw * RTprop
唯一の物理属性は、実際には、我々が最もTCPの本質を懸念している2つのリンクがあり、十分ではありませんでした。
- T（遅延）：BにAからのデータは、図2に対応する、実際の遅延であるラウンドトリップ時間（実際には、片道時間、2倍であるRTT、議論に影響を及ぼしません）。
- R（帯域幅）：実際のデータ伝送帯域幅、図2に対応する送達速度（厳密には対応し、Tと同じ等価簡略化しません）。
私は長いったらしい一人です：帯域幅（吐出流量）と私たちの直感を定義したTCP BBRプロトコルは、次のように定義され、同じではありません。
帯域幅=データ/時間が長いために受信ACKから送り出さ
私たちの本能がある：ネットワークケーブルを介してデータの速度
直感の好意を想像するには、我々はTの代わりに、RTTを使用し、代わりに配信率のRを使用して、以下のすべての概念を簡略化し、してくださいノートと同じです！
さらに、定量次にコンセプトを導入し、T及びRを分析するために：
- Dは： - 、直感想像ため機内データに対応するB（BY Aが発行されたが、データが受信されなかったから、私は意図的にその元の定義-A-が発行された修飾されたが、B ACKが返されたデータを受信していませんこの結論には影響しません）
上記の定義では、それは自然な次の3つの式があります。
- T> = RTprop、すなわち、実際の遅延は最小の遅延が等しくするよりも常に大きいです
- R <= BtlBw、すなわち、実際の帯域幅のボトルネック帯域幅は常に以下であります
- R = D / T
図3は、上記の式から求めることができます。
- T / S> = 1 / BtlBw
- R / S <= 1 / RTprop
図2は、2つの型の2傾き（スロープ）の起点です。
上記の議論では、我々はより簡単に理解し、図の下半分の物理的意味の上半分をマッピングすることができます。
図の上半分。
- ビットデータは、全体リンク（BDP）の物理的なリンク容量に送信されていない前に、図青の水平線の上半分に対応し、制限伝送遅延がRTpropある超え
- 物理容量のデータは、全体のリンクを充填するとき、ルータはに相当する、データのストア・ビットにキャッシュを有効にするために始める長くリンク全体を、伝送遅延が生じることはそうと、物理的限界RTprop逸脱、上昇し始めます緑色斜線の傾き= 1 / BtlBw片
- ルータキャッシュフィル（BDP + BtlBufSize）は、全体のリンクが失われた開始データ、1 / BtlBwとき消失スラッシュ、図中の赤色の点線に対応する上半。
図の下半分。
- 徐々に上昇することが観察され、そして5帯域幅の上昇率が決定され、すなわち、傾き= B側のデータ帯域幅よりもビットデータが全部リンク（BDP）の物理的なリンク容量に送信されていない前図青斜線の下半分に対応する1 / RTprop、
- 物理容量のデータは、全体のリンクを充填するとき、ルータはデータの格納ビットにキャッシュを有効にするために開始したが、B側の観測帯域幅に影響を与えない、この帯域幅の制限は、図クロスピース緑色BtlBwに対応する、BtlBwありますライン
- ルータキャッシュフィル（BDP + BtlBufSize）、全体のリンクは、データ開始を失っているが、B側の観測帯域幅制限またはBtlBw、図の赤半分に点線対応する場合。
したがって、あなたは、これら二つの質問に答えることができます。
- なぜTCP輻輳制御アルゴリズムに基づいて、現在のパケットロス検出はまた、スペースを最適化？
パケットロスがアルゴリズムは常にBDP + BtlBufSizeは現代大きいキャッシュ内のルータので、この状態を機内に到達するデータの量に基づいて検出するので、ヒトに対応する物理リンクは、データ伝送遅延となるように、細長いですRTTが大きいことが、大規模な。
- BBR最適化アルゴリズムの限界はどこ？
BBRはもはや基づいてパケットロスを検出するためのアルゴリズムが、RTTは、その物理的限界RTpropの近くに、それによって、伝送遅延、TCPの加速度の目的を低減するように、BDPとRTpropを推定するための努力ではありません。
だからここでは一般的BBRとパケットロス検出アルゴリズム？BtlBw： - 彼らは、リンクの帯域幅は、その物理的限界になる傾向にしようとしています。
ボトルネックルータキューにBBRベースのアルゴリズムは、空で、最も直接的な影響はRTTの大幅な減少である、あなたははるかに高いBBRよりも赤い線CUBIC RTT下の図に見ることができます：
パケットロスがないためと、BBR伝送速度が劇的に増加していますが、図のグラフは、CDFからCDF累積確率分布関数を挿入明確CUBICほとんどを見ることができます少ない特定の接続のとおりです。
リンクの切り替えが発生した場合は、新しいボトルネック帯域幅リットルの大きなまたはどのように小さなあなたが？BBRは、定期的に次のようにこのサイクルがある1.25,0.75,1,1,1,1、新しいボトルネック帯域を検出しようとします。
1.25 BBRは、飛行中に多くのパケットを送信しようとする試みを行いますと、バックログキューを作成した場合、キュー0.75がリリースされます。図ではTCPリンクの最初の送信が10Mbpsのであるが、より高速なネットワークへの第二20スイッチが存在BBR 1.25による40MBPSは、すぐに最初の40秒で、より大きな帯域幅を発見して、最大10Mbpsにスイッチバックリンクリンク、2秒RTTが急速にBBRは、伝送速度を低下増加するので、BBRの変換サイクルpacing_gainおかげでうまく機能していることが分かります。
pacing_gainサイクルの更なる利点は、異なる初期速度が発電を開始した後に接続され、TCPリンク帯域幅が示されているように、均等の急速な複数の共有させることができることである過大評価BDPキューバックログにより、BBR以前の接続の意志で急速に最終的にバックログキューは、RTTで生成されていないいくつかのサイクルにわたって伝送速度を減少させることで同じなので、その平衡平均帯域幅のリンク5：
我们再来看看慢启动阶段，下图网络是10Mbps、40ms，因此未确认的飞行字节数应为10Mbps*0.04s=0.05MB。红色线条是CUBIC算法下已发送字节数，而蓝色是ACK已确认字节数，绿色则是BBR算法下的已发送字节数。显然，最初CUBIC与BBR算法相同，在0.25秒时飞行字节数显然远超过了0.05MB字节数，大约在 0.1MB字节数也就是2倍BDP：
大约在0.3秒时，CUBIC开始线性增加拥塞窗口，而到了0.5秒后BBR开始降低发送速率，即排空瓶颈路由器的拥塞队列，到0.75秒时飞行字节数调整到了BDP大小，这是最合适的发送速率。
当繁忙的网络出现大幅丢包时，BBR的表现也远好于CUBIC算法。下图中，丢包率从0.001%到50%时，可以看到绿色的BBR远好于红色的CUBIC。大约当丢包率到0.1%时，CUBIC由于不停的触发拥塞算法，所以吞吐量极速降到10Mbps只有原先的1/10，而BBR直到5%丢包率才出现明显的吞吐量下降。
CUBIC造成瓶颈路由器的缓冲队列越来越满，RTT时延就会越来越大，而操作系统对三次握手的建立是有最大时间限制的，这导致建CUBIC下的网络极端拥塞时，新连接很难建立成功，如下图中RTT中位数达到 100秒时 Windows便很难建立成功新连接，而200秒时Linux/Android也无法建立成功。
BBR算法的伪代码如下，这里包括两个流程，收到ACK确认以及发送报文：
function onAck(packet)
rtt = now - packet.sendtime
update_min_filter(RTpropFilter, rtt)
delivered += packet.size
delivered_time = now
deliveryRate = (delivered - packet.delivered) / (delivered_time - packet.delivered_time)
if (deliveryRate > BtlBwFilter.currentMax || ! packet.app_limited)
update_max_filter(BtlBwFilter, deliveryRate)
if (app_limited_until > 0)
app_limited_until = app_limited_until - packet.size
这里的app_limited_until是在允许发送时观察是否有发送任务决定的。发送报文时伪码为：
function send(packet)
bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin
if (inflight >= cwnd_gain × bdp)
// wait for ack or retransmission timeout
return
if (now >= nextSendTime)
packet = nextPacketToSend()
if (! packet)
app_limited_until = inflight
return
packet.app_limited = (app_limited_until > 0)
packet.sendtime = now
packet.delivered = delivered
packet.delivered_time = delivered_time
ship(packet)
nextSendTime = now + packet.size / (pacing_gain × BtlBwFilter.currentMax)
timerCallbackAt(send, nextSendTime)
pacing_gain便是决定链路速率调整的关键周期数组。
BBR算法对网络世界的拥塞控制有重大意义，尤其未来可以想见路由器的队列一定会越来越大。HTTP3放弃了TCP协议，这意味着它需要在应用层（各框架中间件）中基于BBR算法实现拥塞控制，所以，BBR算法其实离我们很近。理解BBR，我们便能更好的应对网络拥塞导致的性能问题，也会对未来的拥塞控制算法发展脉络更清晰。
