HTTP/3とQPACK：パケットロス時代のヘッダー圧縮という難問
おい、最近のWeb API設計やインフラのチューニング現場で、HTTP/3（QUIC）の導入を迫られているエンジニアが急増しているな。いい傾向だ。TCPの呪縛から解放され、UDPベースのQUICが持つ「ヘッドオブラインブロッキング（HoLB）の解消」や「マイグレーション耐性」がいかに強力か、君たちも実務で肌感として分かっていることだろう。
だがな、ここで一つ、ネットワークアーキテクトとしてどうしても語っておかねばならない「魔物」がいる。それがヘッダー圧縮だ。
HTTP/2の時代、私たちはHPACKという素晴らしい発明によって、冗長なHTTPヘッダーを極限まで削ぎ落とし、1つのTCPコネクション上で複数のリクエストを多重化（マルチプレクシング）することに成功した。しかし、そのHPACKの設計思想が、非順序配信（OutOfOrder delivery）を前提とするQUICの登場によって、完全に通用しなくなった。
順序がバラバラに届く世界で、前後のパケットに依存するHPACKの動的テーブルをどう維持するのか？
今回は、その矛盾を華麗に解決したHTTP/3の要――「QPACK」の深淵へ、実務的な視点から案内しよう。
—
1. なぜHPACKではダメだったのか？（HTTP/2からのパラダイムシフト）
まず、敵を知るためにHTTP/2のHPACK（RFC 7541）の弱点を復習しておこう。
HPACKは、静的テーブル（よく使われる共通ヘッダーのリスト）と、通信の進行とともに動的に更新される「動的テーブル（Dynamic Table）」を組み合わせてヘッダーサイズを圧縮する。肝心なのは、「動的テーブルの更新は、送信順序が厳密に保証されたストリーム上で、シーケンシャルに行われなければならない」という点だ。
[HPACKの脆弱性]
HTTP/2 (TCP): パケットA (テーブル追加) → パケットB (追加されたエントリを参照)
※TCPなので必ず順序通りに届き、デコードエラーが起きない。
HTTP/3 (QUIC/UDP): パケットB (参照) が先に着弾！
→ 「え？まだテーブルにそのエントリがないんだけど…」 → デコードストップ（HPACKの限界）
QUICは、パケットロスが発生した際、ロスしたパケットの再送を待たずに他のパケットをガンガン上位層（アプリケーション層）へ渡す（非順序配信）。もしここで従来のHPACKをそのまま使ったらどうなるか？
「ヘッダーのエントリを追加する」というパケットBがロスし、「そのエントリを参照する」というパケットAが先に届いた瞬間、受信側のデコーダーは参照先を見失い、接続全体のストリームが盛大にブロック（ヘッドオブラインブロッキング）されてしまうのだ。「せっかくUDPベースでHoLBを解消したのに、ヘッダー圧縮のせいで意味がなくなった！」という笑えない事態になる。
この致命的な問題を解決するために生み出されたのが、RFC 9204で規定されたQPACKである。
—
2. QPACKの核心：動的テーブル管理と「ブロックメカニズム」
QPACKがHPACKと決定的に違うのは、「エンコーダー（送信側）とデコーダー（受信側）の同期を、完全にリアルタイムに強制しない」という割り切りと、それを支える仕組みだ。
QPACKでは、動的テーブルの更新を管理するために、専用の制御ストリーム（双方向ストリーム）を用いる。そして、順序が狂うことを前提に以下の2つの強力な武器を備えている。
① インセサート（挿入）とラベリング
送信側は、動的テーブルに新しいヘッダーを挿入する際、そのエントリに一意の「インデックス」を振る。そして、そのエントリを参照するヘッダーブロックを送信するときに、「このヘッダーは、動的テーブルのどのインサート状態（何番目まで）を前提としているか」をメタデータとして含める。
② ブロックメカニズム（Blocking）
受信側（デコーダー）は、自分に届いたパケットが「まだ自分の動的テーブルに反映されていない最新のエントリ」を参照している場合、その特定のストリームのデコードを一時的に「ブロック（保留）」する。
重要なのは、HTTP/2とは異なり、ブロックされるのは「その参照依存関係にある個別ストリームだけ」であり、他の無関係なストリームの処理は一切止めないという点だ。
さらに、デコーダーは「ここまでテーブルが更新されたよ」というACK（QPACK Decoder Instruction）を制御ストリーム経由で送信側に送り返す。この往復（Round-Trip）によって、送信側は「受信側がどこまでテーブルを理解しているか」を把握し、必要であれば動的テーブルを安全に縮小していく。
—
3. 通信フロー（シーケンス）のリアルな挙動
実際の通信がどのように行われているか、シーケンスを見てみよう。
[Client / Encoder] [Server / Decoder]
| |
|— (1) QPACK Encoder Instruction ——–>| (動的テーブルにエントリ追加)
| (ストリームID: 制御用) |
| |
|— (2) HEADERS (Stream ID: 4) ———–>|
| (動的テーブルのインデックスを参照) |
| ※もしパケットロスで(1)が遅れても… |
| | — (3) Stream 4だけ一時ブロック
| | (他のStreamは処理継続)
| |
|<-- (4) QPACK Decoder Instruction ---------| (テーブル同期完了のACK)
| ("ここまで反映したよ"と通知) |
| |
| |--- (5) Stream 4のブロック解除・復元完了
この分離された制御構造のおかげで、ネットワークが多少不安定（パケットロスやジッターが多いモバイル環境など）であっても、HTTP/3のパフォーマンスが極限まで維持されるというわけだ。
---
4. 実務で知るべきパラメーターとチューニングの勘所
Webサーバー（Nginx、Envoy、Cloudflareなど）やAPIゲートウェイを運用する際、QPACKに関連する以下のパラメーターを意識する必要がある。
- `SETTINGS_QPACK_MAX_TABLE_CAPACITY`:
動的テーブルに割り当てる最大メモリサイズ（バイト単位）。これを大きくすると圧縮率は上がるが、受信側のメモリ消費が増える。
- `SETTINGS_QPACK_BLOCKED_STREAMS`:
デコーダーが同時にブロックしてもよいストリームの最大数。この数を超えてブロックが発生すると、接続全体がエラー（`QPACK_DECODER_STREAM_ERROR`）として強制切断される。高負荷な環境やモバイル網向けでは、この値を適切にチューニングすることがインフラエンジニアの腕の見せ所となる。
—
5. 実践：HTTP/3とQPACKの世界をコードで体感する
理屈はここまでにして、実際に手を動かしてみよう。
現代の開発環境において、HTTP/3を意識したリクエスト送信やデバッグはどのように行うべきか、実用的なスニペットを紹介する。
A. Python (`httpx` を利用したHTTP/3リクエスト)
PythonでHTTP/3（QUIC）通信を行うには、実験的サポートが充実している `httpx` と `h3` ライブラリの組み合わせが鉄板だ。
import httpx
def fetch_http3_api():
# HTTP/3 (QUIC) を有効化してクライアントを初期化
# ※裏側ではh3ライブラリが使われ、QPACKを用いたヘッダー圧縮・展開が行われています
with httpx.Client(http2=False, http3=True) as client:
try:
url = “https://cloudflare-quic.com/a/h3” # HTTP/3対応のエンドポイント
headers = {
“User-Agent”: “NetworkArchitect-Debug-Client/1.0”,
“X-Custom-Trace-Id”: “trace-xyz-998877″
}
print(f”Connecting to {url} via HTTP/3…”)
response = client.get(url, headers=headers)
print(f”Status Code: {response.status_code}”)
print(f”Negotiated Protocol: {response.http_version}”) # ‘HTTP/3’ が出力されるはず
print(f”Response Headers:\n{response.headers}”)
except httpx.HTTPError as e:
print(f”HTTP/3通信エラーが発生しました: {e}”)
print(“Tips: ファイアウォールでUDP 443番ポートがブロックされていないか確認してください。”)
if __name__ == “__main__”:
fetch_http3_api()
B. cURL (最新のHTTP/3対応ビルド)
インフラの疎通確認には、やはり `curl` が一番早い。ただし、HTTP/3を使うには、`nghttp3` や `ngtcp2`、あるいは `Quiche` バックエンドでビルドされた比較的新しいバージョンが必要だ。
–http3 フラグを指定して強制的にHTTP/3でリクエストを投げる
内部のlibcurlがQUICハンドシェイクを行い、QPACKによるヘッダー処理を実行する
curl –http3 -I https://quic.nginx.org/
詳細な通信ログ（TLSハンドシェイクやネゴシエーションされたALPN）を確認する場合
curl –http3 -v https://cloudflare-quic.com/
インフラ運用のTips:
もし `curl` で `–http3` を指定して `Could not resolve host` や接続タイムアウトになる場合は、大抵 「経路上のルーターやクラウドのセキュリティグループがUDP 443をドロップしている」 か 「サーバー側がALPNで `h3` を返していない」 のどちらかだ。`tcpdump` や `Wireshark` でUDPパケットが流れているかキャプチャして確認してほしい。
—
シニアエンジニアからの現場の教訓
QPACKは、HTTP/2のHPACKが抱えていた「順序への呪縛」を解き放ち、モバイルや劣悪なネットワーク環境下でもWebパフォーマンスを極限まで引き上げるための傑作プロトコルだ。
しかし、動的テーブルとブロックメカニズムという複雑性を内包している以上、アプリケーション層のコードを書く私たちや、インフラを支えるアーキテクトがその挙動（特にパケットロス時の振る舞いやストリームのブロック制限）を理解していないと、いざという時のトラブルシューティングで迷宮入りすることになる。
「なぜこのストリームだけレスポンスが遅延しているのか？」
そう疑ったときは、ぜひこの記事で解説したQPACKの動的テーブルとブロックの概念を思い出してほしい。パケットの向こう側で何が起きているかが見えていれば、どんな障害も怖くないはずだ。さあ、明日からの設計と運用にこの知見をフル活用してくれ。
コメント