HTTP/3とQUIC — 知星図

概要

HTTP/3 は、HTTP の最新メジャーバージョンで、2022年に標準化されました。最大の特徴は、インターネットの信頼性を30年以上支えてきた TCP を使わないことです。代わりに、UDP の上に「QUIC（クイック）」という新しいトランスポートプロトコルを構築し、その上で HTTP を動かします。HTTP/3 とは「QUIC の上に載せ替えた HTTP」であり、この2つはほぼセットで語られます。

QUIC は、TCP が担っていた再送・順序保証・輻輳制御（ネットワークの混雑に応じた送信量の調整）を UDP の上でゼロから作り直し、さらに TLS 1.3 による暗号化をプロトコル自体に組み込んでいます。Google 検索や YouTube、主要な CDN はすでに HTTP/3 で配信しており、モバイル回線のような不安定なネットワークほど恩恵が大きい設計です。

なぜ生まれたか

HTTP/2 は1本の TCP 接続に多数のストリームを多重化しましたが、2つの限界が残りました。1つ目は接続確立のコストです。TCP のハンドシェイクで1往復、その上の TLS のハンドシェイクでさらに1往復以上と、データを送り始める前に複数回の往復（RTT）が必要でした。地球の裏側のサーバなら往復1回だけで数百ミリ秒かかります。2つ目が TCP レベルの HOL（Head-of-Line）ブロッキングです。TCP は「バイト列を順番どおり届ける」層なので、パケットが1つ失われると、無関係なストリームのデータまで再送を待って足止めされます。

どちらの問題も原因は TCP そのものにありますが、TCP は OS のカーネルや世界中のネットワーク機器に実装が焼き付いており、仕様を変えても普及までに何十年もかかります。そこで Google は発想を転換し、「ほぼすべての機器が素通しする UDP の上に、ユーザー空間のソフトウェアとして新しいトランスポートを作れば、アプリの更新だけで進化させられる」と考えました。これが QUIC で、Google での大規模実験を経て IETF が標準化し、その上の HTTP が HTTP/3 と名付けられました。

詳細

接続確立 — ハンドシェイクの統合と0-RTT

TCP+TLS では「まず TCP で接続し、次に TLS で鍵を合意する」という2段構えのため、初回接続では合計2〜3往復してからやっとリクエストを送れました。QUIC はトランスポートのハンドシェイクと TLS 1.3 の鍵交換を1つに統合し、初回でも1往復でリクエスト送信まで到達します。

さらに一度接続したことのあるサーバへの再接続では「0-RTT」が使えます。前回の鍵情報を再利用して、接続確立を待たずに最初のパケットへリクエストを同梱してしまう仕組みです。ただし 0-RTT のデータは攻撃者に再送（リプレイ）される恐れがあるため、GET のような冪等なリクエストに限定するのが原則です。

ストリームごとの独立再送 — HOLブロッキングの解消

QUIC では、ストリームの概念を HTTP 層ではなくトランスポート層が直接持ちます。パケットロスが起きたとき、再送を待つのは失われたデータを含むストリームだけで、他のストリームのデータは届いた順に先へ進めます。TCP のように「接続全体のバイト列」として順序を保証しないため、1つの欠落が全体を止める TCP レベルの HOL ブロッキングが構造的に消えるのです。なお、順序がストリーム単位になったことで HTTP/2 の HPACK がそのまま使えず、ヘッダ圧縮は QPACK という改良版に置き換えられています。

コネクションマイグレーション — 接続がIPアドレスに縛られない

TCP の接続は「送信元と宛先の IPアドレスとポートの組」で識別されるため、スマートフォンが Wi-Fi からモバイル回線に切り替わると接続は必ず切れました。QUIC は接続を「コネクションID」という乱数で識別するので、ネットワークが変わって IP アドレスが変わっても同じ接続を継続できます。移動しながら使うモバイル端末で動画やダウンロードが途切れない、QUIC ならではの体験改善です。

普及状況と落とし穴

ブラウザは Chrome・Firefox・Safari のすべてが対応済みで、大手 CDN 経由なら設定だけで有効化できます。一方で実務上の注意点もあります。まず、企業ネットワークや一部のファイアウォールは UDP の443番ポートを遮断していることがあり、HTTP/3 は「必ず使える」前提にできません。このためサーバは HTTP/2 のレスポンスヘッダ（Alt-Svc）や DNS の HTTPS レコードで「HTTP/3 も話せます」と広告し、クライアントは失敗したら TCP にフォールバックする、という段階的な仕組みで運用されます。設計上、TCP 側の経路は常に残しておく必要があるのです。

また、QUIC はカーネルではなくユーザー空間で動くため、TCP に比べて CPU 負荷が高くなりがちで、通信内容がほぼすべて暗号化されていることから、従来 TCP のヘッダを見て行っていたネットワーク監視やトラブルシューティングの手法が使えないという運用面の変化もあります。「速くなった代わりに、見えなくなり、少し重くなった」— このトレードオフを理解した上で、レイテンシとロス率の高い回線のユーザーが多いサービスから恩恵を刈り取っていくのが現実的な導入方針です。