BBR
Googleが開発したTCPの輻輳制御アルゴリズム。経路のボトルネックの帯域と、往復の伝搬遅延（RTT）を測定し、その結果から送信の速さを決める。パケットの損失ではなく、帯域と遅延の推定をもとに制御する点が特徴。
イマシルちゃんの解説
これまでのTCPは、「パケットがなくなった＝道が混んでる！」って考えて、送る量を減らしていたんだ。
でも、それだと、道がいっぱいになるまで詰め込んでから、慌ててブレーキをかけることになっちゃう。
BBRは、「この道の一番狭いところは何台通れるかな？」「行って帰ってくるのに何秒かかるかな？」を、こまめに測るんだ。
そのちょうどいい量だけ送るから、渋滞を起こさずに、速く送れるんだよ！
より深い解説
定義
BBR（Bottleneck Bandwidth and Round-trip propagation time）は、2016年にGoogleが発表したTCPの輻輳制御アルゴリズムである。Linuxのカーネルに実装され、YouTubeやGoogleのサービスで使われている。QUICでも利用されている。
従来の方式との違い
| 損失ベースの方式（Reno、CUBICなど） | BBR | |
|---|---|---|
| 混雑の判断材料 | パケットの損失 | ボトルネックの帯域とRTTの測定値 |
| 送信量の増やし方 | 損失が起きるまで増やし続ける | 推定した帯域と遅延から、ちょうどよい量にする |
| ルータのバッファ | いっぱいになるまで使う（遅延が増える） | なるべくためない（遅延が小さい） |
| 損失が多い回線 | 損失のたびに送信量を大きく減らし、速度が出ない | 損失だけでは減らさないため、速度を保ちやすい |
従来の方式は、ルータのバッファがあふれてパケットが捨てられるまで送る量を増やすため、大きなバッファを持つ機器では、キューに大量のパケットがたまり、遅延が大きくなる（バッファブロート）という問題があった。
考え方：最適な動作点
ネットワークに送り込んでおくべきデータの量の目安は、次の帯域遅延積（BDP）である。
送り込むべきデータの量 = ボトルネックの帯域 × 往復の伝搬遅延（RTT）これより少ないと回線を使い切れず、多いとルータのキューにたまって遅延が増える。BBRは、帯域とRTTの最小値を継続的に測定して、この最適な量に近づけるように送信の速さ（ペーシング）を調整する。
動作の段階
| 段階 | 内容 |
|---|---|
| STARTUP | 送信量を急速に増やして、利用できる帯域を探す |
| DRAIN | STARTUPでキューにたまった分を減らす |
| PROBE_BW | 推定した帯域で送りつつ、ときどき少し多く送って、帯域が増えていないかを探る |
| PROBE_RTT | 一時的に送信量を減らし、キューが空の状態での最小のRTTを測り直す |
課題
初期のBBR（v1）は、損失ベースの方式と同じ回線を共有したときに帯域を多く取りすぎる、損失が多くても送り続けてしまう、などの公平性の問題が指摘された。これらを改善したBBRv2、BBRv3が開発されている。
名前の似たアルゴリズムとの区別
| 名前 | 分野 | 内容 |
|---|---|---|
| BBR | TCPの輻輳制御 | 帯域とRTTから送信の速さを決める |
| HMAC | 暗号 | 共通鍵とハッシュ関数によるメッセージ認証コード |
| RSA | 暗号 | 素因数分解の難しさに基づく公開鍵暗号 |
| SPF計算（Shortest Path First） | ルーティング | OSPFが最短経路を計算するアルゴリズム（ダイクストラ法） |