TCP BBR

偶然聞き慣れない単語を目にしたので、TCP BBRについて調べてみました。主に動画とブログの内容をまとめたものとなります。 概要 TCP BBRは2016年に論文が公開されたTCPの問題点を解消するためのアルゴリズムです。主に回線の状況が悪い時に効果を発揮するものです。実は、1974年に最初の仕様が公開されたTCPですが、現代の様な大量のトラフィックを想定しておらず、幾つか使用上の問題を抱えています。 TCPの課題 1. 検知の遅延 ネットワークの混雑を検知にパケットロスを利用しています。このためネットワーク混雑の結果としてパケットロスが発生しこれを検知して初めて対応する形式でした。既に実害が発生してからの対応となるため、その間の利用効率は高くありません。 2. 非効率な輻輳制御 また、TCPは複数ユーザの利用を念頭におき指数バックオフ(再送タイムアウトが連続する場合、タイムアウト値を2倍にする機能)を実装していますが、仮に単一ユーザからのアクセスが全てだとすると、この影響で帯域の利用効率は半減してしまいます。 TCP BBRによる解決 検知の遅延に対し、TCP BBRはネットワークの混雑を直接監視します。これにより対応に至るまでのタイムロスを低減します。これによりTCPで低減していた利用効率は改善されます。 また、TCP BBR上ではアルゴリズムもより正確に調整され、結果的に同じネットワークをより効率的に利用できます。 参考欄に提示したブログ内で紹介されたテストにおいては、同一ネットワークで従来の2倍以上の帯域が出ていました。 そして嬉しいことに TCP BBRはクライアントサイドに依存したテクノロジーではなく、サーバーサイドの対応のみで実現することができます。OSのカーネルがサポートされているのであれば、BBRをサポートするようフラグを設定するだけです。 更にGoogle Front End (GFE)は TCP BBRに対応しているため、この背後に存在するサービス(Cloud LB等)は既に対応済みです。 まとめ 現在、HTTPの通信内容をバイナリベースとした HTTP/2や HTTP/2を基盤としてBody部分(従来踏襲)に軽量な ProtocolBuffersを適用した gRPCの採用が進んでいますが、そのベースとなるL4のプロトコルは依然としてTCPです。例えば、HTTP/2は平常時では高速ですが、一定のパケットロスを発生させるとHTTP/1と遜色ない性能に低下してしまうというシミュレーション結果もあるそうです。これは依然としてTCP上の問題が残っていることを意味します。 TCPの枠組みから外れた QUICベースの HTTP/3が普及すれば TCPの諸問題は消えてなくなるでしょうが、それまでの間、TCP BBRを意識して設計するのも悪くないかも知れません。 参考 [Blog] https://medium.com/google-cloud/tcp-bbr-magic-dust-for-network-performance-57a5f1ccf437 [Paper] https://research.google/pubs/pub45646/ https://www.youtube.com/watch?v=2nefATBHs1o