パケットの鼓動を聞け：qlogとQUICで暴く次世代Web通信のリアル
ネットワークエンジニアの先輩風を吹かせるわけではないが、現場で「HTTP/3が繋がらない」「なぜかスループットが出ない」という壁にぶつかったとき、君たちはどうする？
従来のTCPであれば、`tcpdump`やWiresharkを開き、SYN/ACKのやり取りを眺め、TCPストリームを再構築して原因を探るのが定石だった。しかし、時代はHTTP/2からHTTP/3、そしてその下層を支えるQUICへとシフトしている。QUICはUDPベースであり、さらにその全ペイロードがTLS 1.3によって暗号化されている。Wiresharkでパケットキャプチャを取っても、見えるのは暗号化されたUDPの塊ばかり。これでは、パケットの「中身」を診察するドクターズ・バッグの中身がすべて鍵付きの金庫に入っているようなものだ。
そこで登場するのが、今回の主役である qlog だ。
QUIC通信の内部で何が起きているのかをイベントベースでJSON（またはJSON Lines）形式に記録し、可視化する。今回は、このqlogを用いてQUICの深淵を覗き込み、実務でのトラブルシューティングに活かす手法を叩き込む。
—
1. QUICとqlogの基本思想：なぜパケットキャプチャだけでは不十分なのか
HTTP/3の最大の革命は、TCPという呪縛からの解放と、UDPをベースにした独自のトランスポート層の実装にある。これにより、TCPのヘッド・オブ・ライン・ブロッキング（HOLブロック）が解消され、コネクションマイグレーション（IPアドレスが変わっても通信が切れない）といった強力な機能が手に入った。
しかし、その代償として、デバッグの難易度が跳ね上がった。
パケットアナライザは「いつ、どのUDPセグメントが飛んだか」は教えてくれるが、以下の疑問には答えてくれない。
- どのストリームIDでデータの欠損が起きたのか？
- 輻輳制御アルゴリズム（CUBICやBBRなど）の内部状態はどう遷移しているのか？
- どのタイミングでACKが遅延し、ロスリカバリーが発動したのか？
ここでqlog（およびその可視化フロントエンドであるqvis）の出番だ。qlogは、QUICの実装（LSQUIC, quiche, picoquic, ngtcp2など）の内部状態をフックし、標準化されたJSONスキーマに基づいてイベントを時系列で吐き出す。いわば、QUICスタックの「ブラックボックス・フライトレコーダー」である。
—
2. qlogフォーマットの仕様とデータ構造
IETFのドラフト（Draft-ietf-quic-qlog）ベースで標準化が進められているqlogは、JSONベースのログフォーマットだ。基本構造は、1つのファイルに複数の「トレース（trace）」が含まれる形になっており、メタデータ、設定、そして膨大な「イベント（events）」の配列で構成されている。
実際のqlogの断片を見てみよう。
{
“qlog_version”: “draft-02”,
“qlog_format”: “JSON”,
“traces”: [
{
“vantage_point”: {
“type”: “server”,
“name”: “nginx-quic-server”
},
“title”: “QUIC Connection Trace”,
“description”: “Debugging HTTP/3 API latency spike”,
“configuration”: {
“time_offset”: 0
},
“event_fields”: [“time”, “category”, “event_type”, “data”],
“events”: [
// コネクション確立の瞬間
[0.000, “transport”, “connection_started”, {
“sw_version”: “quiche-0.19.0”,
“remote_inet”: “192.168.1.50”,
“remote_port”: 54321,
“local_inet”: “10.0.0.1”,
“local_port”: 443
}],
// パケット送信イベント（パケットヘッダーと含まれるフレーム情報）
[1.245, “transport”, “packet_sent”, {
“header”: {
“packet_type”: “handshake”,
“packet_number”: 0
},
“frames”: [
{ “frame_type”: “crypto”, “offset”: 0, “length”: 1200 }
]
}],
// 輻輳ウィンドウ（Congestion Window）の更新イベント
[15.890, “recovery”, “congestion_window_updated”, {
“new_value”: 14720,
“min_value”: 2944,
“reason”: “ack_received”
}]
]
}
]
}
実務で特に注目すべきカテゴリは以下の3つだ。
1. `transport`: パケットの送受信、フレーム（STREAM, ACK, CRYPTOなど）のやり取り。
2. `security`: TLSハンドシェイクの進捗、鍵の導出。
3. `recovery`: 損失検出、RTT（Round Trip Time）の計測、そして輻輳ウィンドウ（CWND）の変動。APIのレスポンスが突発的に遅延する場合、大抵はこの`recovery`カテゴリの中に犯人が隠れている。
—
3. 実践：qlogを出力し、可視化ツールでパケットフローを追う
口で言うだけではエンジニアの信用は勝ち取れない。実際に手を動かして、qlogを出力し、ブラウザでその挙動を視覚化してみよう。
今回は、テスト用として広く使われているRust製のQUIC/HTTP/3ライブラリ `quiche` や、開発環境で手軽にHTTP/3を扱える `curl` を想定したワークフローを解説する。
ステップ1: クライアント/サーバー側でのqlog有効化
多くのQUIC実装では、環境変数や設定ファイルでqlogの出力先を指定できる。例えば、テストクライアントとして `curl`（HTTP/3対応版）や、カスタムのPythonスクリプト（設定による）を動かす際、環境変数をアサインする。
quicheベースのアプリケーションや対応ツールでqlog出力を有効化する環境変数例
export QLOGDIR=/var/log/qlog
これにより、コネクションごとに一意の.qlogファイルが生成される
ステップ2: 生成されたqlogを「qvis」で読み込む
ログファイル（`.qlog` または `.sqlog`）を手に入れたら、パケット解析の最強の相棒であるWebUIツール [qvis (Network Incident Simulator / Sequence Diagram Viewer)](https://qvis.quiclog.cloud/) にアクセスする。
ブラウザの画面に、先ほどの`.qlog`ファイルをドラッグ＆ドロップするだけで、以下のような極めて直感的な情報が視覚化される。
1. シーケンス図（Sequence Diagram）:
クライアントとサーバーの間で、どのパケットがどの順序で飛び交っているか、パケットロスが起きて再送（Retransmission）された瞬間がタイムラインで一目瞭然になる。
2. ボトルネック・グラフ（Multiplexing & CWND）:
ひとつのQUICコネクション上で複数のHTTP/3リクエスト（ストリーム）がどのように多重化され、帯域を奪い合っているか、また輻輳ウィンドウが狭まってスループットが落ちていないかがグラフ化される。
—
4. トラブルシューティングの実務Tips：qlogから何読み解くか？
現場で遭遇する典型的なトラブルと、qlogを用いたアプローチをいくつか伝授しよう。
トラブルA: APIのレイテンシーが「たまに」数秒跳ね上がる（Head-of-Line Blockingの誤解と実態）
「HTTP/3だからパケットロスしても他のストリームは止まらないはずなのに、なぜかAPIの応答が遅延する」という相談を受けたとする。
- qlogからのアプローチ:
`recovery` カテゴリの `packet_lost` イベントと、`transport` カテゴリの `stream_data_blocked` イベントを突合せる。
QUICのトランスポート層ではロスが他のストリームに影響しなくても、HTTP/3のレイヤー（QPACKによるヘッダー圧縮など）で依存関係が発生している場合や、サーバー側のアプリケーションバッファが枯渇している場合、ストリームがブロックされる。qvisのストリームビューで、特定のストリームだけが「Waiting for control stream」状態になっていないかを確認せよ。
トラブルB: モバイル環境でのコネクション切断（Connection Migrationの検証）
ユーザーがWi-Fiからモバイル回線（4G/5G）へ切り替えた瞬間にコネクションが切れるというクレーム。
- qlogからのアプローチ:
`transport` カテゴリの `path_created` や `connection_state_updated` を監視する。正常にコネクションマイグレーションが機能していれば、IPアドレスやポート番号が変わった後も、既存のConnection IDを引き継いでパケット（`packet_sent` / `packet_received`）が継続しているログが確認できる。もしここでハンドシェイクがゼロからやり直されている（= 0-RTTやマイグレーションの失敗）なら、ロードバランサー（L4/L7）側がUDPの経路変更に追従できていない証拠だ。インフラ側のルーティング設定を見直すべきだと即座に判断できる。
—
5. まとめ
ネットワーク技術がどれほど進化し、パケットが暗号化のベールに包まれようとも、エンジニアの手元には常に「内部状態を覗き見る手段」が用意されている。
Wiresharkのパケットキャプチャで途方に暮れる前に、qlogという次世代のレンズを使ってみてほしい。QUICのストリームが織りなす複雑なダンス、輻輳制御アルゴリズムの息づかいが、驚くほどクリアに視えてくるはずだ。
インフラの挙動を完全に支配すること――それこそが、我々ネットワークエンジニアの醍醐味なのだから。
コメント