ChromeでのHTTP/3・QUIC対応はまだまだ進化している — その技術的詳細を公式ブログが解説

12月17日、Chromium Blogで「Chrome を QUIC 化する(Making Chrome QUICer)」と題した記事が公開された。この記事では、HTTP/3 と IETF QUIC における新機能の導入やパフォーマンス最適化について詳しく紹介されている。

以下に、その内容を簡潔にまとめて紹介する。

Chrome は 2020 年 10 月に HTTP/3 ( RFC 9114 ) をデフォルトで有効化して以来、さらにパフォーマンスの向上を図ってきた。HTTP/3 は IETF QUIC (RFC9000) 上で動作しており、HTTP/1 や HTTP/2、さらには Google QUIC と比較しても優位に立つことが示されている。検索や動画再生の待ち時間削減などの改善がすでに得られているが、その後も最適化の取り組みが続けられている。

最近の主な改良点として、HTTP/3 ORIGIN フレーム (RFC 9412) と Server’s Preferred Address (RFC 9000 Section 9.6) の実装がある。これらはともに M131 からデフォルトで有効化されており、2024 年 11 月 19 日に Stable チャネルにリリースされている。

ORIGIN フレーム

あるホスト名向けの接続を確立するとき、サーバ証明書には他の複数のホスト名も含まれている場合が多い。しかしクライアント側では、実際にその接続で別のホスト名向けリクエストを送る前に、当該ホスト名について DNS ルックアップを行い、接続先 IP が一致するかを検証しなければならない。この追加的な DNS 解決が遅延を引き起こすうえ、IP アドレスが一致しないケースがあると、接続の再利用が行われないまま新たな接続を作成してしまう。Chrome の計測では、IP 不一致がなければ 約20%の HTTP/3 接続が不要だった とみられている。

新規接続の確立は、QUIC の 0-RTT（※1）があってもレイテンシやメモリ、CPU 消費の面で負荷が大きい。具体的には以下のような要因がある。

DNS 解決による遅延（Chrome の DNS キャッシュにある場合は緩和される）。
- QUIC ハンドシェイクにおいてクライアントとサーバ双方で複数パケットを送信する必要がある。
TLS で非対称暗号処理を行うため、CPU 負荷が大きい。
- 輻輳制御がデフォルト状態から始まるため、送信量の調整に時間がかかる可能性がある。
0-RTT が失敗する可能性がある。
- 安全ではないリクエストは 0-RTT で送信されない。

加えて、HTTP/3 での優先度制御 (RFC 9218) などの機能も、複数のレスポンスを同時に返す環境下でなければ十分に効果を発揮しない。そこで ORIGIN フレームを用いると、サーバはどのドメインを既存の接続にプールしてほしいかをクライアントに明示できるようになる。これにより DNS ルックアップをスキップしつつ、接続の再利用範囲を制御可能になるのが大きなメリットだ。

※1 0-RTT…0-RTT （ゼロ・ラウンドトリップタイム）とは、QUIC や TLS 1.3 において、再接続時などにクライアントが前回の通信情報を一部再利用し、サーバとのハンドシェイクを事実上スキップしてデータ送信を開始できる仕組みである。初回接続で学習した暗号情報を使って再度のやり取りを省略し、往復回数 (RTT) を削減することで、通信の開始を高速化できるのが特徴。

Server’s Preferred Address

最初にクライアントが接続したサーバのアドレスが常に最適とは限らないケースもある。L4 ロードバランサの背後にあるアドレスや、Anycast を利用している遠方のサーバ経由になっている場合などでは、不要な経路を通ることでレイテンシが増加することがある。

QUIC は TCP のように 4 つ組 (IP とポートの組合せ（※2）) に固定されないため、ハンドシェイク完了後にサーバが異なる IP アドレスへ移行することをクライアントに提案できる。これが Server’s Preferred Address であり、RFC9000 ではサーバがアドレスを変更できる唯一のパターンとして定義されている。

現状では Google のMedia CDNが広くこの機能を用いているが、今後さらに多くのサーバで導入が進む見込みだ。Chrome によるテストでは、この移行が 99% 以上の高確率で成功し、 ラウンドトリップタイム (RTT) が平均して 40～80% 程度削減されている という。

※2 「IP とポートの組合せ」を「4つ組 (4-tuple)」と表現するのは、ネットワーク通信において以下の 4 つの要素をセットで扱うからである。

送信元 IP アドレス (Source IP)
送信元ポート番号 (Source Port)
宛先 IP アドレス (Destination IP)
宛先ポート番号 (Destination Port)

TCP や UDP のセッションを一意に識別する際、これら四つの値がそろってはじめて固有の接続 (フロー) を表すため、「4つ組 (4-tuple)」として表現される。

詳細はMaking Chrome QUICer] を参照していただきたい。