HTTP/3 — Web Protocol Lab

#このページで確認できること

Alt-Svc ヘッダーを起点に h2 → h3 へ移行する流れを確認する
curl --http3-only の結果と、TCP上のHTTP/2またはHTTP/1.1の接続結果を比較し、UDP 443の疎通とサーバー側h3対応を切り分ける
プロキシ環境で h2 にフォールバックする挙動と、その理由を理解する
観察するヘッダー/項目: alt-svc、ALPN h3、DevTools の Protocol 列

実装上の制約: h3 対応の curl ビルドが必要です(macOS標準curlは非対応のことが多い)。また本サイト自体は現時点で HTTP/3 配信をしていません。コマンド例は h3 対応の公開ホストを対象にしています。

#HTTP/2 との違い

	HTTP/2	HTTP/3
トランスポート	TCP	QUIC (UDP)
TLS	TCPの上に別レイヤー	QUIC に TLS 1.3 が統合
ヘッダー圧縮	HPACK	QPACK(ストリーム独立性を考慮した再設計)
HoLブロッキング	TCPレイヤーで全ストリームに影響	QUICの異なるストリーム間では回避。QPACK等の依存による待ちはあり得る
接続確立	TCP + TLS を順に確立。TLS 1.3の初回接続は一般に2 RTT	初回1 RTT。再接続時は条件を満たせば0-RTTも可
代表的なHTTPSポート	TCP 443	UDP 443

多重化・ストリーム・疑似ヘッダーといった概念は HTTP/2 から引き継いでいます。フレームの種類と番号は HTTP/2 と互換性がなく、独立した定義です。

#Alt-Svc によるHTTP/3の発見

Alt-Svcをまだ学習していないクライアントは、まず TCP(HTTP/1.1 か HTTP/2)で接続し、レスポンスの Alt-Svc ヘッダーで「h3 も使える」と知らされてから HTTP/3 へ切り替えることがあります。この場合は「初回はh2、2回目以降h3」が観測されます。ただし、キャッシュ済みのAlt-SvcやDNSのHTTPSレコードを使う場合は初回からh3になることもあり、この順序は保証されません。

response header

HTTP/2 200 alt-svc: h3=":443"; ma=86400

Alt-Svc による HTTP/3 への移行

participants: Client, Server
Client -> Server: TCP + TLS (ALPN: h2)
Client -> Server: GET / (HTTP/2)
Server --> Client: 200 OK + alt-svc: h3=":443"
note: クライアントは h3 対応を学習・記憶する
Client -> Server: QUIC handshake (UDP 443, ALPN: h3)
Client -> Server: GET /next (HTTP/3)
Server --> Client: 200 OK (HTTP/3)

DNSでの発見: HTTPS レコード(SVCB, RFC 9460)の alpn="h3" でも通知でき、この場合は初回からHTTP/3で接続できます。dig example.com HTTPS で確認できます。

#ハンドシェイク

HTTP/3 接続確立 — 1 RTT でリクエスト送信開始

participants: Client, Server
Client -> Server: QUIC Initial (ClientHello, ALPN: h3) [UDP]
Server --> Client: QUIC Initial + Handshake (ServerHello, cert)
Client -> Server: Handshake finished
note: 1 RTT で暗号化確立 — TCPの3-wayハンドシェイクは存在しない
Client -> Server: HEADERS frame (GET /) on stream 0
Server --> Client: HEADERS + DATA (200 OK)

TLS 1.3 統合: QUICハンドシェイクの中でTLS 1.3が完了する。TCP接続とTLSを順番に確立する場合より、初回の完全なハンドシェイクに必要な往復数を減らせる。
QPACK: HPACKの後継。動的テーブル更新を専用ストリームに分離して依存を制御する。ただし、動的テーブル参照を待つ blocked stream は設定上存在し、ヘッダー処理が常に非ブロッキングになるわけではない。
0-RTT: 再接続時にハンドシェイク完了前からリクエストを送れる。リプレイされ得るため、HTTPクライアントはGETなどの安全なメソッド、またはリプレイを許容できると判断した処理に利用を制限する必要がある。実際の有効化条件は実装と設定による。

#検証コマンド

curl — HTTP/3 で接続(h3対応ビルドが必要)

# curl が h3 対応か確認(Features に HTTP3 があるか)
$ curl --version | grep -i http3

# HTTP/3 を強制
$ curl -I --http3-only https://cloudflare-quic.com/

# HTTP/3 を先に試し、接続できない場合は以前のHTTP版へのフォールバックも行う
$ curl -v --http3 https://cloudflare-quic.com/ 2>&1 | grep -E 'ALPN|HTTP/3|alt-svc'

出力例 (ヘッダーは時期・接続先で変わる)

HTTP/3 200 alt-svc: h3=":443"; ma=86400 server: cloudflare

環境依存に注意: macOS 標準の curl は HTTP/3 非対応のことが多く、brew install curl 版やdockerイメージが必要です。またUDP 443がネットワークでブロックされている場合、多くのクライアントはTCP上のHTTP/2またはHTTP/1.1へフォールバックします。「HTTP/3が使われない」こと自体に気づきにくいため、Protocol表示とキャプチャを併用します。

#観測ポイント

curl	`--http3-only` が失敗し、同じホストがTCP上のHTTP/2またはHTTP/1.1で応答する場合は、UDP 443の疎通かサーバー側h3対応を候補に切り分ける。`--http2` はHTTP/1.1へフォールバックし得るため、`-v` の交渉結果も確認する。
DevTools	Network の Protocol 列に `h3`。Alt-Svcを初めて学習する環境では、初回の `h2` がリロード後に `h3` へ変わる場合がある。キャッシュやHTTPSレコードにより初回からh3になる場合もある。
Proxy	従来型の明示プロキシのHTTP CONNECTはTCPトンネルなので、そのままではHTTP/3を運べない。この構成ではh2へフォールバックすることが多い。一方、標準化済みのMASQUE CONNECT-UDPに対応するプロキシならUDPをトンネルできる。
tcpdump / Wireshark	フィルタ: `quic`。UDP 443 へのトラフィックと QUIC Initial パケットを確認。SSLKEYLOGFILE で復号すれば `http3` フィルタでフレームも見える。
TLS inspection	QUICを復号しない装置や組織では、UDP 443をブロックしてTCPへフォールバックさせる構成が使われることがある。自組織の方針を確認した上で、フォールバックが意図どおり起きるか、余分な待ち時間がないかを観測する。

#関連

HTTP/3 の土台であるトランスポート層の詳細(connection migration、0-RTT、connection ID)は QUIC のページを参照してください。