BBR
Googleが開発した、TCPなどで使われる輻輳制御アルゴリズム。経路の帯域と遅延の推定をもとに送信ペースや受信確認前のデータ量を調整し、帯域の有効利用と遅延の抑制を目指す。
イマシルちゃんの解説
ネットワークにデータを送りすぎると、途中の機器にたまって待ち時間が延びるんだ。
BBRは、こうした混雑を抑えながら回線を活用するための輻輳制御アルゴリズムだよ。
TCPなどで使われ、相手から届く受信確認を手掛かりに経路の状態を調べるんだ。
見積もるのは、経路の一番狭い部分で1秒間に運べる量を示すボトルネック帯域だよ。
データを送って受信確認が戻るまでの最短の時間、最小RTTも調べるよ。
その結果に合わせて、送るペースや受信確認を待つデータ量を調整するんだ。
回線を使い切りつつ、余計な待ち時間を増やさないことを目指しているの。
この解説はわかりやすかったですか?
より深い解説
定義
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が最短経路を計算するアルゴリズム(ダイクストラ法) |
実際の試験ではここに出る!全1問
ネットワークスペシャリスト
- 午前Ⅱ