HTTP/3とは
HTTP/3は、QUICを利用し、接続確立や通信切り替えの改善を図ったHTTPの版です。HTTP/3（Hypertext Transfer Protocol Version 3／ハイパーテキスト・トランスファー・プロトコル・バージョン・スリー）で、エイチティーティーピー・スリーと読みます。
HTTPのメソッド、URL、状態コード、フィールド、キャッシュなどの意味はHTTP/1.1・HTTP/2と共通です。転送にはTCPではなくQUICを使い、HTTPメッセージをHTTP/3フレームとしてQUICストリームへ載せます。
HTTP/3の中心は単なる版番号更新ではなく、HTTP/2で一つのTCPバイト列へ集めていた複数交換を、回復単位の分かれたQUICストリームへ移したことです。
要求ストリームと、接続を支える単方向ストリームを使い分ける
一つの双方向QUICストリームでHEADERSとDATAを交換する
SETTINGSやGOAWAYなどを、各方向一つの制御ストリームで運ぶ
送信側が動的表を更新する命令を、専用単方向ストリームで送る
復号側が処理済み挿入数やストリーム取消を送り返す
許可された場合に、サーバーが資源応答を単方向ストリームで送る
ストリーム順序、損失回復、フロー・輻輳制御、TLS認証を担う
HTTPの意味は変えず、QUICストリームへフレームを対応付ける
要求ストリームでは、HEADERSフレームが疑似ヘッダーと通常フィールドを、DATAフレームがHTTP内容を運びます。メソッド、スキーム、オーソリティー、パスはHTTP/2と同様に疑似ヘッダーとして表現されます。
QUIC STREAMフレームとHTTP/3 DATAフレームは別の層です。一つのHTTP/3フレームが複数QUICパケットへまたがることもあります。解析では、UDPデータグラム、QUICパケット、QUICフレーム、HTTP/3フレーム、HTTPメッセージを順に分けます。
QPACKは、別ストリームの損失で全要求が止まる問題を抑える
QPACK（キューパック）はHTTP/3のフィールド圧縮方式です。静的表と動的表を使う点はHPACKに似ていますが、表の更新指示を専用ストリームへ分け、QUICのストリーム独立性へ合わせています。
受信側にまだ届いていない動的表エントリーをヘッダーブロックが参照すると、その要求ストリームは復号を待つことがあります。SETTINGS_QPACK_BLOCKED_STREAMSで同時に待たせてよい数を合意します。HTTP/3は順序待ちを完全になくすのではなく、待ち合わせの範囲を制御し、独立要求へ広がりにくくする設計です。
TLS 1.3はQUICへ統合され、HTTP/3だけを平文で動かす方式はない
HTTP/3は、TLS 1.3を組み込んだQUIC接続上で動きます。サーバー証明書を検証し、ALPNでh3系列を合意します。HTTP/2のように通常のTLSレコードをTCP上へ重ねる構造ではありません。
0-RTTでは以前の接続情報を使って早期要求を送れる場合がありますが、再送されても安全な要求かを判断します。HTTPメソッドが冪等でも、認証状態、レート制限、サーバー実装を含めた受け入れ方針が必要です。
最初の接続では、サーバーがHTTP/3対応先を知らせることがある
同じHTTPS URLでも、クライアントが最初からHTTP/3の接続先を知るとは限りません。HTTP応答のAlt-Svc（オルト・サービス）フィールドや、DNSのHTTPSリソースレコードなどで、同じオリジンを提供するQUIC接続先を知ります。
クライアントは証明書が元のオリジンへ有効かを確認し、通知先を勝手な別サイトとして信頼しません。アドレス変更やポート変更があっても、URL表示とオリジンの権限境界は維持されます。
UDPが通らないときは、HTTP/2などへ戻して利用を継続する
企業ネットワーク、古いNAT・ファイアウォール、通信事業者の一部経路でUDPが遮断・制限される場合があります。HTTP/3だけを待ち続けると表示が遅くなるため、クライアントは過去の到達結果を記録し、TCP上のHTTP/2などと適切に競合・フォールバックします。
評価では「h3になったか」だけでなく、初回・再訪、UDP不通、回線切替、損失、証明書更新、フォールバックまで測る必要があります。HTTP/3対応は、常にHTTP/2より速いという宣言ではありません。
仕様の確認資料：RFC 9114「HTTP/3」、RFC 9204「QPACK」、RFC 7838「HTTP Alternative Services」