QUICの「中身」を覗く：WiresharkでHTTP/3通信を完全復号する現場の技術
ネットワークエンジニアにとって、TCPの時代は「パケットキャプチャ＝通信の全貌が見える」という分かりやすい時代だった。しかし、HTTP/3（QUIC）の登場により、その前提は崩れ去った。UDPの上でTLS 1.3が強固にラップされ、パケットのペイロードは暗号化のベールに包まれている。
Wiresharkでパケットを開いても、見えるのは`Initial`や`Short Header`という無機質なラベルだけ。トラブルシューティングでパケットの中身が見えないというのは、外科医が目隠しで手術をするようなものだ。
今回は、現場のエンジニアがHTTP/3の挙動を正しく理解し、パフォーマンスチューニングやデバッグを行うために必須となる「QUICパケットの復号手順」を、実務的な知見を交えて解説する。
—
なぜQUICの解析には「鍵」が必要なのか
QUICは、接続確立（Handshake）の段階から暗号化を行う。従来のTLSのように「平文でネゴシエーション→暗号化開始」というプロセスではなく、TLS 1.3の鍵交換がパケットヘッダーの裏側で密かに進む。
つまり、Wiresharkがいくら優秀でも、「ブラウザやクライアントが生成した共通鍵」を共有してあげない限り、ペイロードのHTTP/3フレーム（HEADERSやDATA）を覗き見ることはできない。ここで活躍するのが `SSLKEYLOGFILE` という環境変数だ。
—
ステップ1：SSLKEYLOGFILEの準備
クライアント（ブラウザやcurl）に対し、「生成したセッションキーをこのファイルに書き出せ」と命令する。これが解析の第一歩だ。
Linux/macOSの場合
ターミナルで以下のコマンドを実行する。
セッションキーを保存する場所を指定
export SSLKEYLOGFILE=~/sslkeylog.log
この状態でcurlを実行する（HTTP/3を強制指定）
curl –http3 https://example.com -v
Windows (PowerShell) の場合
環境変数をセッション単位で設定
$env:SSLKEYLOGFILE = “C:\temp\sslkeylog.log”
ブラウザ（Chrome/Edge）を起動する際は、この環境変数が有効な状態で起動する必要がある
& “C:\Program Files\Google\Chrome\Application\chrome.exe”
この設定を行うと、通信が発生するたびに `sslkeylog.log` に `CLIENT_RANDOM` から始まるシークレットキーが追記されていく。
—
ステップ2：Wiresharkの設定
次に、Wiresharkに「どの鍵を使ってパケットを解読するか」を教える。
1. [Preferences] (設定) を開く。
2. [Protocols] > [TLS] を選択する。
3. (Pre)-Master-Secret log filename の項目に、先ほど指定した `sslkeylog.log` のパスを入力する。
これだけで、パケットリストの表示が劇的に変わる。それまで `UDP` や `QUIC` としか表示されていなかったパケットが、突然 `HTTP/3` というプロトコルヘッダーを伴って解読されるようになるはずだ。
—
ステップ3：解析で見えてくる「現場の真実」
復号ができたら、まずは以下の3点を確認してほしい。
1. 0-RTT（Zero Round Trip Time）の成否
HTTP/3の最大の売りである0-RTT。Wiresharkで見て、最初の`Initial`パケットの中に`Early Data`が含まれているかを確認する。これが成功していれば、接続確立を待たずに即座にHTTPリクエストが飛んでいるはずだ。もしここで失敗している（再送が頻発している）なら、サーバー側の設定やキャッシュの不整合を疑うべきだ。
2. ストリームの多重化（Multiplexing）
QUICは1つの接続（Connection）の中で複数のストリームを並列処理する。`Stream ID`を追跡し、どのリクエストがどのストリームで処理されているか、ヘッド・オブ・ライン・ブロッキング（HoLB）が発生していないかを確認できる。これはTCPでは決して見えなかった光景だ。
3. コネクションIDの追跡
IPアドレスやポート番号が変わっても、QUICは`Connection ID`で同一セッションを維持する。Wiresharkのフィルタで `quic.connection_id == 0x…` と入力し、クライアントがネットワークを切り替えた（Wi-Fiから4Gへなど）際のマイグレーション処理が正しく行われているかを追跡してみよう。
—
エンジニアへのアドバイス：解析の落とし穴
最後に一つ、現場からのアドバイスだ。
「復号できても、パケットロスがあれば解析は止まる」
QUICはUDPベースであり、パケットが失われた場合、再送制御や暗号化のコンテキストが途切れる可能性がある。Wiresharkで「Decrypted TLS」と表示されているパケットの中に、怪しいフラグや `Out-of-order` の警告がないか注意深く見てほしい。
HTTP/3は強力だが、その分ブラックボックス化しやすい。今回紹介した`SSLKEYLOGFILE`を用いた可視化は、単なるデバッグ手法ではなく、「ネットワークの挙動を自分の手で制御する」ための武器だ。
ぜひ、皆さんの開発環境でも一度試してみてほしい。今まで「速い」としか認識していなかったHTTP/3の、緻密で美しいパケットの舞いが見えてくるはずだ。
コメント