HTTP/3とQPACKの深層：UDPの荒野でヘッダー圧縮と戦うアーキテクトたちへ
Webの高速化の歴史は、トランスポート層の足かせを外す歴史だった。TCPの3ウェイハンドシェイク、そしてあの忌々しいヘッド・オブ・ライン・ブロッキング（HoLブロック）。これらを根底から覆すために現れたHTTP/3、そしてその下を支えるQUICは、ついにトランスポート層をUDPベースへと移行させた。
しかし、パケットロスに強いUDPの上でWebを動かすという選択は、新たなパラドックスを生んだ。それが「HTTP/3におけるヘッダー圧縮」、すなわちQPACKの存在だ。
HTTP/2のHPACKは、TCPという「順序が完全に保証された信頼性のあるストリーム」の上で完璧に機能するように設計されていた。だが、パケットが順番通りに届かない、あるいは消失して再送されるQUICの世界でHPACKをそのまま使えばどうなるか？ 答えは地獄のようなヘッド・オブ・ライン・ブロッキングの再来である。
今回は、パケットレベルの挙動、静的・動的テーブルの同期メカニズム、そして現場のインフラエンジニアが知るべきチューニングとセキュリティの境界線まで、QPACKの深層を徹底的に解剖していこう。
—
1. なぜHPACKではダメだったのか？：QUIC世界における構造的矛盾
HTTP/2の命綱の一つが、HPACK（RFC 7541）によるヘッダー圧縮だ。数バイトのインデックスやハフマン符号化を用いることで、冗長なHTTPヘッダー（`User-Agent`や`Cookie`など）を極限まで削ぎ落とし、RTT（往復遅延時間）の無駄を排除してきた。
HPACKの心臓部は「動的テーブル（Dynamic Table）」である。送信側と受信側が全く同一のテーブル状態を共有し、ヘッダーの差分だけをストリームに流し込む。
ここで決定的な前提がある。それは「パケットが送信された順序通りに確実に受信側に届く」というTCPの強烈な保証だ。
もしHTTP/2でパケットAがロスし、パケットBが先に届いた場合、受信側はパケットBのデコードを一時停止し、パケットAの到着を待つ。これがTCP層でのHoLブロックだ。
しかし、HTTP/3のベースであるQUICは、異なるストリーム間の順序依存性を完全に排除している。ストリーム#3でパケットロスが起きても、ストリーム#5は平然と処理されなければならない。
ここで、もしHPACKの動的テーブルをそのまま適用し、ストリーム#3のロスによって動的テーブルの更新順序が狂ったとしよう。ストリーム#5は「まだ届いていない動的テーブルのエントリ」を参照せざるを得なくなり、HTTP/3のトランスポート層がせっかく排除したはずのHoLブロックが、今度はアプリケーション層（ヘッダーデコード層）で盛大に復活することになる。
この矛盾を解決するために生み出されたのが、QPACK（RFC 9204）である。
—
2. QPACKのアーキテクチャ：静的テーブルと「制御ストリーム」の分離
QPACKは、この順序不達のジレンマを解決するために、ヘッダー圧縮の「状態（State）」をデータストリームから切り離し、専用の制御チャネルに隔離するという極めてエレガントなアプローチをとった。
静的テーブル（Static Table）の不変性
QPACKにもHPACKと同様に静的テーブル（RFC 9204 Appendix A）が存在する。例えば、インデックス `0` は `:authority`、`1` は `:method` GET、といった具合にあらかじめ両者でハードコードされた99個のエントリだ。
これらは完全に不変（Immutable）であるため、動的な同期を一切必要としない。パケットがどのような順序で届こうとも、静的テーブルを参照する限り、デコードエラーは絶対に起きない。
動的テーブル（Dynamic Table）と制御ストリーム
問題は動的テーブルだ。動的テーブルは通信の途中で動的にエントリが追加されるため、送信側と受信側で「どのタイミングでそのエントリが有効になったか」を同期しなければならない。
ここでQUICのマルチプレクシングが活きる。QPACKでは、通常のHTTPリクエスト/レスポンスが流れる「リクエストストリーム」とは別に、QPACK専用の双方向制御ストリーム（Encoder Stream / Decoder Stream）を一本確立する。
1. Encoder Stream（送信側 → 受信側）: 送信側（例えばサーバー）が動的テーブルに新しいエントリを追加する指示を流す。
2. Decoder Stream（受信側 → 送信側）: 受信側が「そのエントリを安全に受信し、我が方の動的テーブルにも反映完了したよ」というAcknowledgment（確認応答）を返す。
これにより、リクエストデータ自体には「未確定の動的テーブルの参照」を含めず、安全に処理を進めることが可能になる。
—
3. パケットレベルで見るQPACKのエンコーディング挙動
実際のワイヤーフォーマット（バイト列）がどのように構成されているか、パケットアナライザの視点から紐解いてみよう。
QPACKのヘッダーブロックは、主に以下の3つのプレフィックス情報を持つ。
- Required Insert Count (RIC): このヘッダーブロックをデコードするために、動的テーブルに必要な最小限のエントリ挿入数。
- Delta Base: RICからの相対値として、動的テーブルの「ベース」となる位置を示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Insert Count (8+) |S| Delta Base (7+) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Field Lines… |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
デコードの安全性チェック（Blocking vs Non-Blocking）
受信側がこのヘッダーブロックを受け取ったとき、自身の動的テーブルの挿入回数が、ヘッダーブロックが要求する `Required Insert Count` に達しているかをチェックする。
- 安全（Non-Blocking）: すでに必要なエントリを受信済みな場合、即座にデコードされ、アプリケーション層へ渡る。
- ブロック状態（Blocking）: まだ必要なエントリがEncoder Stream経由で届いていない場合、受信側は当該ストリームの処理を一時停止（ブロック）する。
「あれ？結局HoLブロックが起きているじゃないか」と思った鋭い読者もいるだろう。
しかし、ここがQPACKの真骨頂だ。QPACKでは、設定（SETTINGSフレーム）によって動的テーブルの最大容量（`QPACK_MAX_TABLE_CAPACITY`）を `0` に制限することができる。
動的テーブルの容量を `0` にするということは、すべての動的エントリの作成を禁止し、静的テーブルとリテラル（素の文字列 / ハフマン符号化）のみでヘッダーをやり取りすることを意味する。
これにより、動的テーブルの同期遅延に起因するアプリケーション層のブロックを完全に排除し、純粋な非同期・超高速のパケット処理を実現できるのだ。メモリフットプリントも劇的に削減されるため、高負荷なCDNエッジやAPIゲートウェイでは、あえて動的テーブルを無効化（あるいは最小限に抑制）する設計が広く採用されている。
—
4. 現場のインフラ/セキュリティエンジニアのための実践的チューニング
理論を理解したところで、実務においてHTTP/3とQPACKをどのようにハンドリングすべきか、Nginxや Envoy、そしてLinuxカーネルのパラメータの文脈で実践的な知見を共有しよう。
EnvoyプロキシにおけるQPACK設定のベストプラクティス
モダンなマイクロサービスアーキテクチャの要塞であるEnvoyでは、HTTP/3（QUIC）のリスナー設定において、QPACKの挙動をきめ細やかに制御できる。以下の設定スニペットは、メモリ消費とブロックリスクのバランスを最適化した実践的なものだ。
static_resources:
listeners:
- name: h3_edge_listener
address:
socket_address:
address: 0.0.0.0
port_value: 443
protocol: UDP
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: h3_ingress
http3_protocol_options:
# QPACKの動的テーブル容量を設定
# メモリ逼迫を防ぎ、ブロッキングを避けるためにあえて小さく（あるいは0に近く）設計する
max_dynamic_table_size: 4096
# 同時にブロックを許可するストリーム数を制限し、リソース枯渇攻撃を防ぐ
decoder_table_capacity: 4096
stream_idle_timeout: 30s
route_config:
# ルート設定…
セキュリティ上の脅迫：QPACKリソース枯渇攻撃（CVE-2023-44487の文脈と類似の脆弱性）
HTTP/2のRapid Reset（CVE-2023-44487）が記憶に新しいが、HTTP/3やQPACKのレイヤーでも特有の攻撃ベクトルが存在する。
攻撃者が悪意あるEncoder Streamを大量に送り込み、受信側に巨大な動的テーブルのエントリを次々と生成させ、メモリを枯渇させる（Memory Exhaustion）手法だ。あるいは、わざと `Required Insert Count` を満たさないヘッダーブロックを大量のストリームで並行送信し、受信側のデコーダーをブロック状態に釘付けにしてCPUとメモリリソースを圧迫する。
防御策：
1. 厳格なクォータ制限: `max_dynamic_table_size` や `max_blocked_streams` の値をサーバー側で厳しく制限する。無制限の動的テーブルを許可してはならない。
2. UDPバッファチューニング（Linux Kernel）: QUICはUDPベースであるため、カーネルのUDP受信バッファサイズが不足するとパケットロスが跳ね上がり、QPACKの再送・同期遅延を引き起こす。
`/etc/sysctl.conf` において、以下のカーネルパラメータを最適化しておくことが必須となる。
UDP受信バッファの最大値を拡大し、高スループットなQUICトラフィックのバーストを受け止める
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
デフォルトのバッファサイズも底上げ
net.core.defaul_qdisc = fq
net.core.netdev_max_backlog = 250000
（※ `fq` キューイングディシプリンの適用は、BBR混雑制御アルゴリズムと組み合わせてQUICのペースティングを最適化するためにも極めて有効である。）
—
5. 終わりに：未来のネットワークを見据えて
QPACKというプロトコルは、一見すると「UDPという不安定な荒野で、TCPの快適さを再現しようとする泥臭い試み」に見えるかもしれない。しかし、その内部で繰り広げられているのは、静的・動的テーブルの緻密な状態管理、非同期制御ストリームによるデカップリング、そしてセキュリティとパフォーマンスの極限のトレードオフの最適化に他ならない。
インフラストラクチャの進化スピードは止まらない。HTTP/3、QUIC、そしてQPACKの挙動をパケットレベルで解釈できる能力は、これからのクラウドネイティブ・アーキテクトやセキュリティ・スペシャリストにとって、単なる「知っていると便利な知識」ではなく、障害を切り抜け、極限のパフォーマンスを絞り出すための「生存のための武器」なのだ。
さあ、次世代のパケットが、君のNICを叩く音が聞こえるか？
コメント