HTTP/3

HTTP/3 とは

HTTP/3 は、2022 年 6 月に RFC 9114 として公開された HTTP のメジャーバージョンである (2026 年 8 月時点で最も新しい版)。メソッド・ステータスコード・ヘッダーといったセマンティクスは HTTP/1.1 や HTTP/2 と共通で、置き換わったのは下を支えるトランスポートである。TCP + TLS の代わりに QUIC (UDP の上に構築された、暗号化を内蔵するトランスポート) を使うことで、接続確立に要する往復回数を減らし、TCP 層で起きていたヘッドオブラインブロッキングを取り除く。

HTTP/1.1 → HTTP/2 → HTTP/3

3 つの版を貫く軸は「多重化をどの層に置くか」である。HTTP/1.1 は多重化を持たず、並列化はブラウザが複数の TCP 接続を張ることで代用していた。HTTP/2 は多重化をアプリケーション層に持ち込んだが、土台の TCP が 1 本の順序付きバイト列であるという制約は残った。HTTP/3 は多重化をトランスポート層である QUIC 側へ下ろし、その制約自体を外している。

観点	HTTP/1.1	HTTP/2	HTTP/3
トランスポート	TCP	TCP	QUIC (UDP)
多重化	なし (パイプライン)	ストリーム多重化	ストリーム多重化
HoL ブロッキング	あり	TCP 層で発生	TCP 層では発生しない
接続確立	TCP + TLS (2〜3 RTT)	TCP + TLS (2〜3 RTT)	0〜1 RTT
ヘッダー圧縮	なし	HPACK	QPACK

接続確立の RTT は前提付きの値である。HTTP/3 の 1 RTT は初回接続、0 RTT は以前に接続したことのあるサーバーへの再接続を指す。HTTP/2 側の 2 RTT は TLS 1.3、3 RTT は TLS 1.2 の場合に対応する。

QUIC プロトコル

QUIC は、Google の Jim Roskind による初期設計を出発点に IETF の作業部会が標準化したトランスポートプロトコルである。コア仕様は 2021 年 5 月に RFC 9000 として公開された。RFC 9000 は謝辞で設計がこの初期案に大きく由来すると記しており、参照されている初期案の文書は 2013 年 12 月付である。

HTTP/2:  [HTTP/2] → [TLS 1.3] → [TCP] → [IP]
HTTP/3:  [HTTP/3] → [QUIC (TLS 1.3 内蔵)] → [UDP] → [IP]

QUIC の主な特徴:

• 0-RTT 接続: 以前に接続したサーバーへは、ハンドシェイクの最初のパケットにアプリケーションデータを同乗させられる (ハンドシェイクが無くなるのではなく、完了を待たずに送れるという意味である)
• 独立したストリーム: 1 つのストリームでパケットロスが起きても他のストリームに影響しない (HTTP/2 の TCP 層 HoL ブロッキングを解消)
• コネクションマイグレーション: IP アドレスが変わっても (Wi-Fi からモバイル回線への切り替え等) 接続を維持

0-RTT で送ったデータには再送攻撃の余地が生まれる。攻撃者が最初のパケットを捕まえて後から再送すると、サーバーが同じリクエストを二度処理しかねない。RFC 9114 は 0-RTT を使う場合に RFC 8470 の緩和策を適用することを必須としており、サーバー側の手段は 3 つある。early data を受け付けない、TLS ハンドシェイクの完了まで HTTP としての処理を遅らせる、425 (Too Early) を返してクライアントに送り直させる、のいずれかである。クライアントは 425 を受け取ったら通常のリクエストとしてやり直す。どこまで再送を許容できるかは対象リソースの性質で決まり、それを判断できるのはオリジンサーバーだけである。

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

TCP はアプリケーションに 1 本の順序付きバイト列を渡す。そのため 1 つのセグメントが失われると、後続のバイトが既に届いていても、失われた分の再送が完了するまでアプリケーションへ渡せない。HTTP/2 は多重化をこの 1 本の上で行うため、ロスと無関係なストリームのデータまで待たされる。QUIC はストリームごとに順序と再送を管理するので、ロスの影響はそのストリームの中に閉じる。

HTTP/2 (TCP):
  ストリーム A: [パケット1] [パケット2:ロス] → 全ストリーム待機
  ストリーム B: ブロック
  ストリーム C: ブロック

HTTP/3 (QUIC):
  ストリーム A: [パケット1] [パケット2:ロス] → A だけ再送待ち
  ストリーム B: 正常に進行
  ストリーム C: 正常に進行

モバイル回線やパケットロスが多い環境で特に効果が大きい。

ただし解消されるのは TCP 層のヘッドオブラインブロッキングであって、順序保証そのものが消えるわけではない。同一ストリームの中では順序が保たれるため、1 つの大きなレスポンスを受信している途中でロスが起きれば、そのレスポンスは再送を待つことになる。

AWS での対応状況

CloudFront は HTTP/3 に対応しており、ディストリビューションのサポート対象 HTTP バージョンの設定で明示的に有効化する (2026 年 8 月時点)。ビューワー側の条件は TLS 1.3 と SNI への対応で、HTTP/3 の利用自体に追加料金はかからない。コネクションマイグレーションにも対応するため、ビューワーがネットワークを切り替えても接続は維持される。

注意したいのは、効果が及ぶ範囲がビューワーとエッジの間に限られる点である。CloudFront からカスタムオリジンへのリクエスト転送は HTTP/1.1 で行われる。つまり HTTP/3 で改善するのは配信経路の前半だけで、オリジンまで含めて置き換わるわけではない。

ALB のリスナーが扱えるプロトコルは HTTP と HTTPS で、HTTP/2 は HTTPS リスナーがネイティブに対応する (2026 年 8 月時点)。UDP の上で動く HTTP/3 をリスナーで直接受けることはできないため、HTTP/3 をエンドユーザーへ届けたい構成では CloudFront を前段に置くのが現実的な選択になる。

主要ブラウザ (Chrome、Firefox、Safari、Edge) は HTTP/3 に対応済みである (2026 年 8 月時点)。

HTTP/2 からの移行

HTTP/3 は HTTP/2 と同じセマンティクスを使うため、アプリケーションのコードを書き換える必要はない。ただし設定を入れれば全員が HTTP/3 で来るわけではないので、2 点は押さえておきたい。

1 点目は発見の仕組みである。クライアントは最初から HTTP/3 が使えると知っているわけではないため、サーバーは Alt-Svc レスポンスヘッダー (HTTP/2 の接続なら ALTSVC フレーム) で同じオリジンに HTTP/3 のエンドポイントがあると広告し、クライアントは次の接続からそちらへ移る。TLS ハンドシェイクで使う ALPN トークンは h3 である。なお HTTP/3 は平文の http URI への直接アクセスには使えない。

2 点目は UDP が通らない経路である。ファイアウォールや途中の機器が UDP の 443 番を落とす環境では QUIC の接続確立に失敗する。RFC 9114 はこの場合クライアントが TCP ベースの HTTP を試みるべきと定めており、実際のブラウザもそのように振る舞う。したがって HTTP/3 を有効にしても、HTTP/2 の経路は残したままにしておく前提で設計する。

導入効果の判断基準は単純である。モバイルからのアクセス比率が高い、パケットロスや遅延の大きい回線が多い、1 ページで取得するリソース数が多い、という条件が重なるほど効きやすい。逆に低ロスの社内ネットワークが主で、リクエスト数も少ないサイトでは体感差はほとんど出ない。