HTTP/3が求められる背景

Webの通信プロトコルは、HTTP/1.0からHTTP/1.1、HTTP/2と進化を遂げてきた。そして今、HTTP/3が急速に普及しつつあります。Google、Cloudflare、Metaをはじめとする大手テック企業がすでにHTTP/3を本番環境で採用しており、2024年時点でWebトラフィック全体の約30%がHTTP/3で通信されているとされます。本記事では、HTTP/3とその基盤ですQUICプロトコルの仕組みを、エンジニアの視点から解説します。

TCP時代の限界

HTTP/2はHTTP/1.1の多くの課題を解決した。ヘッダー圧縮、サーバープッシュ、ストリームの多重化など、革新的な機能が導入された。しかし、HTTP/2にはTCPに起因する根本的な問題が残されていた。

ヘッドオブラインブロッキング

HTTP/2はアプリケーション層で複数のストリームを多重化するが、トランスポート層ではすべてのストリームが単一のTCPコネクション上に載っています。TCPはパケットの順序保証を行うため、あるパケットが失われると、後続のすべてのパケットがそのパケットの再送を待たなければなりません。これがTCPレベルのヘッドオブラインブロッキングです。

たとえば、画像、CSS、JavaScriptの3つのリソースを同時にダウンロードしています場合、CSSのパケットが1つ失われただけで、まったく関係ない画像やJavaScriptのデータも受信が停滞します。HTTP/2のストリーム多重化の恩恵が、TCP上では十分に発揮されないのです。

接続確立のオーバーヘッド

TCPの接続確立には3ウェイハンドシェイクが必要で、最低1RTT（ラウンドトリップタイム）がかかる。さらにTLSハンドシェイクが加わると、TLS 1.2では追加で2RTT、TLS 1.3でも追加で1RTTが必要になります。モバイル環境などRTTが大きい場合、この接続確立のレイテンシが体感速度に大きく影響します。

QUICプロトコルとは何か

QUIC（Quick UDP Internet Connections）は、Googleが開発し、IETFで標準化されたトランスポート層プロトコルです。UDPの上に構築されており、TCPの課題を根本的に解決する設計となっています。

QUICの主要な特徴は以下の通りです。

• UDP上に構築：OSのカーネルに依存せず、ユーザー空間で実装できるため、進化が速いです
• 暗号化の標準装備：TLS 1.3が組み込まれており、平文通信は存在しません
• ストリーム単位の制御：パケットロスの影響がストリームごとに独立しています
• 接続確立の高速化：最短0-RTTでのデータ送信が可能
• コネクションマイグレーション：IPアドレスが変わっても接続を維持できます

ヘッドオブラインブロッキングの解消

QUICの最も重要な改善点は、ストリーム単位での独立したフロー制御です。QUICでは各ストリームが独自のパケット順序を管理するため、あるストリームでパケットロスが発生しても、他のストリームには影響しません。

先ほどの例で言えば、CSSのパケットが失われてもCSSの受信だけが遅れ、画像やJavaScriptは問題なく受信を継続できます。これにより、パケットロスが発生しやすいモバイル環境や不安定なネットワークで、HTTP/2と比較して大幅なパフォーマンス改善が期待できます。

0-RTT接続確立の仕組み

QUICでは、初回接続でも1RTTでハンドシェイクとTLSネゴシエーションを同時に完了できます。TCPの場合、TCPハンドシェイクの後にTLSハンドシェイクが必要だったが、QUICではこれらを統合しています。

さらに、過去に接続したことのあるサーバーに再接続する場合、0-RTTでのデータ送信が可能です。最初のパケットにアプリケーションデータを含めることで、ハンドシェイクの完了を待たずにデータ送信を開始できます。

ただし、0-RTTにはリプレイ攻撃のリスクがあるため、冪等なリクエスト（GETなど）にのみ使用すべきだという点は理解しておく必要があります。

コネクションマイグレーション

TCPコネクションは、送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポートの4つの組み合わせで識別されます。そのため、スマートフォンがWi-Fiからモバイル回線に切り替わると、IPアドレスが変わるためにTCPコネクションが切断され、再接続が必要になります。

QUICではコネクションIDという識別子を使ってコネクションを管理するため、IPアドレスが変わっても同じコネクションを継続できます。モバイルユーザーにとっては、ネットワークの切り替え時にも途切れることなくWebページを閲覧できるという大きなメリットがあります。

HTTP/3の構造

HTTP/3は、QUICの上に構築されたアプリケーション層プロトコルです。HTTP/2の機能の多くをQUICのトランスポート層に委譲したことで、プロトコル自体はシンプルになっています。

HTTP/2のストリーム多重化はQUICのストリーム機能で実現され、フロー制御もQUIC層が担当します。HTTP/3固有の機能としては、QPACKと呼ばれるヘッダー圧縮方式があります。これはHTTP/2のHPACKを改良したもので、QUICのストリーム独立性と整合するように設計されています。

実環境での効果と課題

HTTP/3の効果が最も顕著なのは、パケットロスが発生しやすい環境です。モバイル通信、新興国のネットワーク、混雑したWi-Fi環境などで、HTTP/2に対して明確なパフォーマンス優位性が確認されています。

一方で、低レイテンシで安定した有線接続環境では、HTTP/2との差は小さいです。また、導入にあたってはいくつかの課題もあります。

• ファイアウォールとの互換性：UDPベースのため、UDPをブロックするネットワーク機器では通信できません。多くの実装ではHTTP/2へのフォールバック機能を備えています
• CPU負荷：QUICはユーザー空間で実装されるため、カーネル空間で動作するTCPと比較してCPU負荷が高い傾向があります
• デバッグの難しさ：すべての通信が暗号化されるため、パケットキャプチャによるトラブルシューティングが困難になります。qlogという専用のロギング形式が策定されています
• 中間装置の対応：ロードバランサーやCDNなどの中間装置がQUICに対応しています必要があります

今後の展望

HTTP/3の普及は着実に進んでおり、主要なCDN、Webサーバー、ブラウザがすでに対応しています。QUICの仕組みはHTTP以外のプロトコルにも応用が広がっており、DNS over QUICやWebTransportなど、新しいユースケースも登場しています。

筆者としては、新規のWebサービス構築においてHTTP/3対応を標準とすることを推奨します。CDNを利用しています場合は、設定を有効にするだけで対応できるケースがほとんどです。プロトコルの進化を理解した上で、適切にインフラ設計に活かしていくことが、現代のエンジニアに求められるスキルでしょう。