HTTP/3はUDP上でQUICを使い、HTTP/2とTCPで起きるトランスポート層のHead-of-Line（HoL）ブロッキングを減らします。ただし、遅延の影響が常に各ストリームだけに閉じるわけではありません。QUICでは各ストリーム内の順序は独立して保たれますが、同じ接続のストリームは混雑制御と接続単位のフロー制御を共有します。IETF RFC 9000 Cloudflareの技術解説（著者 Alessandro Ghedini）

パケットを失ったとき何が変わるか

HTTP/2では一つのTCP接続に複数のリクエストを多重化できます。一方、TCPから見るとデータは一つの順序付きバイトストリームです。途中のバイトが欠けると、その欠落部分が再送されるまで、後から届いたデータをアプリケーションへ渡せません。同じTCP接続に載った別の応答も待たされる場合があります。

HTTP/3では各リクエストにQUICストリームを使います。HTML、スタイルシート、画像を同時に読み込むページで画像ストリームの一部を失った場合、その画像は欠落データの回復を待ちますが、別ストリームのデータは画像のバイト順を待つ必要がありません。これがQUICで減らせるトランスポート層のHoLブロッキングです。Cloudflareのエンジニア Alessandro Ghediniも、ストリームが独立して配信される一方、接続の混雑状態は共有されると説明しています。

したがって「他のストリームは遅延なく届く」とは限りません。接続単位の混雑制御とフロー制御が送信を制限することがあり、損失が激しければ接続全体の進行が遅くなることもあります。QUICの利点は、一つのストリームで欠けたバイトの順序待ちが、それだけで別ストリームすべてを止めない点です。

初回のハンドシェイクと再接続時の0-RTT

QUICはTLS 1.3を接続確立に組み込みます。初回接続では通常、1-RTT段階のアプリケーションデータを送る前にハンドシェイクの往復が必要です。再接続では、以前のセッション情報があり、サーバーが受け入れる場合に限って、最初の送信に0-RTTの早期データを含められます。毎回利用できる機能ではありません。

早期データは別の接続で再生される可能性があります。そのためTLS 1.3は再生されても安全なデータだけを送るよう求め、HTTP/3も0-RTT利用時のリプレイ対策を要求します。RFC 8446の0-RTTとリプレイ対策 RFC 9114のEarly Data

例として、商品一覧の読み取りは重複しても状態を変えない設計にできます。一方、注文作成、クーポンの一回利用、決済は重複実行で副作用が生じる可能性があります。HTTPメソッド名だけで判断しないでください。GETでも実装次第では副作用が起きます。0-RTTを有効にする前に、処理が再生に耐えるか、サーバーが重複要求をどう扱うか、早期データが拒否されたときの動作を確認します。

ネットワークが切り替わるときのConnection ID

QUICのConnection ID（CID）は、現在のIPアドレスとポートだけに接続の識別を依存させないための仕組みです。スマートフォンがWi-Fiから携帯回線へ移ると経路が変わることがあります。両端が新しい経路を検証し、サーバーが移行を扱える場合は既存接続を継続できます。これは対応条件下で再接続の負担を減らす機能で、ダウンロードの中断を必ず防ぐ保証ではありません。Cloudflareのコネクション移行解説

CIDは固定の64ビット・128ビット値ではありません。RFC 9000ではNEW_CONNECTION_IDフレームが運ぶIDの長さを1～20バイトと定め、パケット形式には長さ0のCIDを使う場合もあります。値や長さは接続と実装によって異なります。CIDだけで移行が自動的に成功するわけではなく、経路検証、サーバーの状態・ルーティング、UDP通信の可否も関係します。

運用時に確かめること

  • HTTP/2とHTTP/3を比べるときは、パケット損失率、往復時間、端末、要求サイズを記録します。一つのネットワークでの結果をすべての利用者へ一般化しません。
  • UDPが遮断されたり不安定だったりするネットワークもあります。HTTP/3を確立できない場合、対応する代替経路へ接続できるか実環境で確認します。
  • ストリームの独立性は、接続全体で共有する混雑制御をなくしません。「損失の影響は必ず一つのストリームだけ」と説明しないようにします。
  • 0-RTTは遅延を減らす選択肢であると同時にセキュリティ上の判断です。再生時の影響と重複要求への処理を設計レビューに含めます。

参考資料