QUIC — Web Protocol Lab

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

クライアントが送るQUIC Initialを含むUDPデータグラム(通常UDP 443、UDPペイロード1200バイト以上)を tcpdump / Wireshark で確認する
connection ID による識別と、条件を満たす場合にIP変更後も継続できる connection migration を理解する
0-RTT 再接続の流れと、安全性・リプレイ耐性を確認すべき理由を理解する
観察する項目: UDP 443 のデータグラム、connection ID、Wireshark フィルタ quic

実装上の制約: Handshake・0-RTT・1-RTTパケットの内容を観測するには、通常SSLKEYLOGFILEによる復号設定が必要です。一方、Initialの鍵はパケット上で見える情報から導出できるため、WiresharkはキーログなしでもInitial内のClientHelloなどを解析できます。

#なぜ UDP の上に作るのか

TCPより更新を展開しやすい: TCPの改良はOSカーネルと中間装置(ファイアウォール、NAT)の対応を伴うことがある。UDP上のユーザー空間実装なら、多くの変更をアプリケーション更新で展開できる。ただし、UDPを制限するネットワークポリシーの影響は受ける。
TCPのHoLブロッキング: TCPは単一のバイトストリームなので、欠落箇所以降のバイトは再送されるまでアプリケーションへ配送されない。QUICはストリームごとに順序を管理するため、ストリームAの欠落がストリームBの順序付き配送を直接止めない。ただし、共有する輻輳制御の影響はコネクション全体に及び得る。
ハンドシェイクの重複: TCP 3-way handshake の後に TLS handshake を重ねると 2〜3 RTT かかる。QUICはトランスポートと暗号のハンドシェイクを統合し 1 RTT にした。
多くの制御情報を保護: パケット番号やACKなども保護し、中間装置が依存できる情報を抑えている(ossification 対策)。長形式ヘッダーのVersion・packet type・connection ID・Lengthなどは観測でき、Initialのペイロードは公開情報から鍵を導出して復号できるため、機密性はない。

#ハンドシェイクと 0-RTT

QUIC 初回接続 — 1 RTT

participants: Client, Server
Client -> Server: Initial packet (ClientHello) [UDP]
Server --> Client: Initial + Handshake (ServerHello, cert, finished)
Client -> Server: Handshake (finished)
note: 1 RTT で暗号化されたコネクション確立
Client <-> Server: 1-RTT packets (application data / streams)

再接続 — 0-RTT でデータを即送信

participants: Client, Server
note: 前回接続時のセッションチケットを保持している
Client -> Server: Initial (ClientHello + session ticket)
Client -> Server: 0-RTT packet (GET / を即座に送信)
Server --> Client: Handshake + 1-RTT (200 OK)
note: 0-RTT はリプレイされ得る。HTTPでは安全なメソッド等に利用を絞る

アドレス検証前の増幅対策: サーバーはクライアントアドレスを検証するまで、受信したバイト数の3倍を超えて送信できません。必要に応じてRetryでreturn routabilityを確認します。1200バイト以上に拡張する要件は、クライアントが送るInitial入りデータグラムと、サーバーが送るack-eliciting Initial入りデータグラムが対象です。このサイズ要件だけで増幅対策が完結するわけではありません。

#Connection ID と connection migration

TCPのコネクションは「送信元IP・ポート・宛先IP・ポート」の4タプルで識別されるため、一般にWi-Fi→モバイル回線の切替でIPが変わると同じコネクションは継続できません。QUICはConnection IDでコネクションを識別し、相手がmigrationを無効化していないなどの条件を満たせば、IPアドレスが変わっても同じコネクションを継続できます(connection migration)。

Connection migration — IPが変わっても継続

participants: Client, Server
Client -> Server: 1-RTT packets (Wi-Fi: 192.0.2.10)
note: クライアントがモバイル回線へ切替 — IPが変わる
Client -> Server: same connection ID (LTE: 203.0.113.55)
Server --> Client: PATH_CHALLENGE (新経路の検証)
Client -> Server: PATH_RESPONSE
note: migrationが許可され、新経路の検証に成功すれば継続する

NAT・ファイアウォール観点: connection migration はステートフルなファイアウォールやNATのセッション管理と相性が悪く、また5タプルでフローを追跡するネットワーク監視では「別フロー」に見えます。QUICのトラブルシュートでは connection ID 単位で追う必要があります。

#ストリームとフロー制御

ストリーム: 1コネクション内に複数の独立したバイトストリーム。双方向/単方向、クライアント起点/サーバー起点で4種類のID空間がある。
独立した配送: ストリームAのデータ欠落はストリームBの順序付き配送を直接止めない。ただし、輻輳制御やコネクション単位のフロー制御は共有する。
フロー制御: ストリーム単位とコネクション単位の2階層(MAX_STREAM_DATA / MAX_DATA)。
信頼性: QUICのパケット番号は、Initial、Handshake、Application Data (0-RTTと1-RTTで共有) の各packet number space内で増加し、失われたパケットの番号を再利用しない。ACKフレームで到達確認し、失われたデータは別の新しいパケットで再送する。

#検証コマンド

curl / ブラウザ

# HTTP/3 経由で QUIC を使う(h3対応curlが必要)
$ curl -v --http3-only https://cloudflare-quic.com/ 2>&1 | head -30

# 実際のQUIC応答を使って疎通を確認する。失敗時は同時にパケットキャプチャする
$ curl -v --http3-only https://cloudflare-quic.com/ -o /dev/null

tcpdump — QUIC パケットのキャプチャ

$ sudo tcpdump -i en0 -n 'udp port 443'
# クライアント送信のInitial入りUDPデータグラムは、UDPペイロード1200バイト以上
# サーバー送信ではack-eliciting Initial入りが同じサイズ要件の対象

# Wireshark で復号したい場合はキーログを出してから起動
$ SSLKEYLOGFILE=$HOME/sslkeys.log /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
# Wireshark: Preferences → Protocols → TLS → (Pre)-Master-Secret log filename に指定

Wireshark フィルタ

# QUIC パケット全体
quic

# Initial パケット(ハンドシェイク開始)のみ
quic.long.packet_type == 0

#観測ポイント

curl	`--http3-only` の結果から、対象ホストがHTTP/3で応答できるかを確認。`--http3` を使う場合は、HTTP/3失敗後の h2 / HTTP/1.1 へのフォールバックと区別する。
DevTools	Protocol 列 `h3`。Chromium系では `chrome://net-export` からネットワークログを取得できる。connection ID やmigration関連イベントが記録・表示されるかは実装とバージョンによる。
Proxy	従来型HTTP CONNECTはTCPトンネルなのでQUICを運べない。この構成ではQUICが使われないことが多い。一方、MASQUE CONNECT-UDPに対応するプロキシならUDPをトンネルできる。
tcpdump / Wireshark	UDP 443 のデータグラムサイズ、connection ID、Version、packet typeを確認する。クライアント送信のInitial入りデータグラムと、サーバー送信のack-eliciting Initial入りデータグラムはUDPペイロード≥1200Bが要件。Initialはキーログなしでも解析可能で、Handshake・1-RTTの詳細には通常キーログが必要。
TLS inspection	QUICの復号・ポリシー制御に対応しない装置では、UDP 443を遮断してTCP上のHTTPへフォールバックさせる構成がある。その場合は、クライアントがタイムアウト待ちで遅延しないかを観測する。

#関連

QUIC 上のHTTPについては HTTP/3 を参照。QUICが解決した課題の背景は HTTP/1.1 → HTTP/2 の流れで追うと理解しやすいです。