HTTP/2 HPACKの深層：パケットを極限まで削ぎ落とすバイナリ錬金術
Webの歴史を振り返るとき、私たちは常に「レイテンシー」という目に見えない壁と戦ってきた。HTTP/1.1時代、リクエストのたびに送信される数キロバイトのCookieやUser-Agent、無数のリクエストヘッダーは、光速の物理法則に逆らうかのようにネットワーク帯域を蝕み、TCPのスロースタートの足かせとなっていた。
「同じヘッダーを、なぜ毎回の通信で律儀に全文送信しているのか？」
この根源的な問いに対するHTTP/2の回答が HPACK である。単なる汎用圧縮アルゴリズム（GzipやBrotliなど）の適用ではない。HTTPヘッダーの構造的特徴――すなわち「ほとんどのヘッダーフィールドは、リクエスト間で変化しないか、変化しても限られたパターンである」という特性――に特化し、コンテキストを共有するステートフルな辞書ベースの圧縮機構こそがHPACKの真髄だ。
今回は、パケットのバイナリ表現、TLSハンドシェイクとの密接な関係、そして実運用でエンジニアの頭を悩ませるセキュリティの罠（HPACK Bomb）まで、プロトコルの深淵を覗いてみよう。
—
1. 静的テーブルと動的テーブル：ステートフルな辞書の正体
HPACKの圧縮効率の高さは、送信側と受信側が同期した「テーブル（辞書）」を保持するというステートフルな設計に由来する。このテーブルは、あらかじめ定義された固定の 静的テーブル（Static Table） と、通信の進行に伴って動的に構築される 動的テーブル（Dynamic Table） の2階層で構成される。
静的テーブル（Static Table）の不変の美学
RFC 7540およびRFC 7541（HPACK仕様）において、静的テーブルには頻出するHTTPヘッダー（例: `:method: GET`, `:path: /`, `scheme: https`, `accept: /` など）が `1` から `61` までのインデックスでハードコードされている。
例えば、リクエストヘッダーに `:method: GET` を含める場合、HPACKは文字列の `”GET”` やキーの `”:method”` を一切送信しない。ただ1つのバイト（インデックス `2` を示すバイナリ表現）を流すだけで、受信側は静的テーブルを参照して即座にヘッダーを復元する。これ以上の効率化を物理的に達成することは不可能に近い。
動的テーブル（Dynamic Table）と双方向同期の妙
静的テーブルに載らないカスタムヘッダー（例: `authorization: Bearer token…` や特定の `cookie`）はどう扱うのか？ ここで登場するのが動的テーブルだ。
動的テーブルは、コネクションが確立された後、個々のHTTP/2ストリームを流れるヘッダーブロックを処理するたびにエンコーダーとデコーダーの両方で逐次更新されていく。
1. エンコーダー側: 新しいヘッダーフィールド（例: `x-custom-tracking-id: uuid-1234`）を発見すると、それを動적テーブルの先頭（Index 62以降）に追加し、そのインデックス番号または名前＋値のペアをフレームに載せて送信する。
2. デコーダー側: 送信されたバイナリをデコードする過程で、まったく同じアルゴリズムに従って自身の動的テーブルを更新する。
ここで重要なのは、エンコーダーとデコーダーの動的テーブルの「状態（State）」が完全に一致していなければならないという点だ。もしパケットロスや順序逆転（TCPのレイヤーでは防がれるが、HPACKのコンテキスト管理において）で状態が乖離すると、デコードエラー（`COMPRESSION_ERROR`）が発生し、HTTP/2コネクション全体が容赦なくRST_STREAMまたはGOAWAYで切断される。
—
2. パケットレベルの解剖学：プレフィックスと可変長整数
HPACKのバイナリ表現をWiresharkなどでキャプチャすると、その緻密なビット演算の美しさに感嘆する。HPACKはバイト境界（Byte Boundary）を無視し、ビット単位（Bit-packing）でフィールドをパッキングする。
ここで多用されるのが、RFC 7541のセクション5.1で定義されている 「Nビット・プレフィックス整数（Integer Representation）」 だ。
0 1 2 3
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|?|?|?|?|?|?|?|?| <- プレフィックス部（例: 上位4ビット）と残りの値
+-+-+-+-+-+-+-+-+
|X| 値の続き (1) | <- 値がプレフィックスに収まらない場合の拡張バイト
+-+-+-+-+-+-+-+-+
|0| 値の続き (2) | <- 最上位ビット(MSB)が0になるまで継続
+-+-+-+-+-+-+-+-+
例えば、インデックスを表現する際、プレフィックスが5ビット（最大値 `31`）の場合、インデックスが `31` 未満であれば1バイトのまま表現できる。しかし、インデックスが `32` を超える場合、5ビットすべてを `1`（`11111`）で埋め、次のバイト以降に実際の値を可変長整数としてエンコードしていく。この手法により、頻繁に使われる小さなインデックスは極限まで短縮され、大きな数値も破綻なく表現できる。
さらに、文字列リテラル（テーブルに登録されていない新規のキーや値）を送信する際には、ハフマン符号化（Huffman Coding） が適用される。
静的に定義されたハフマンツリーを使用し、出現頻度の高い文字（スペースや小文字のアルファベットなど）には短いビット列を、頻度の低い文字には長いビット列を割り当てることで、文字列全体のサイズを平均して30%〜50%削減している。
—
3. トランスポート層およびTLSハンドシェイクとの最適化
HPACKの効率を最大化するためには、その基盤となるTCPおよびTLSの挙動を深く理解し、インフラストラクチャレベルで適切にチューニングを行う必要がある。
TLS 1.3とHTTP/2のシナジー
HTTP/2は平文（H2C）でも動作するが、実質的にはすべての主要ブラウザがTLS上のHTTP/2（ALPNによるネゴシエーション）を強要している。
ここで重要になるのが TLS 1.3の0-RTT（Zero Round Trip Time Resumption） との組み合わせだ。
初回接続以降、クライアントは前回のセッションチケットを用いて、TLSハンドシェイクの完了を待たずに暗号化されたHTTP/2リクエスト（Early Data）を送信できる。このとき、HPACKの初期動的テーブルサイズはデフォルトで4096バイトに設定されているが、サーバー側で適切な初期ウィンドウサイズやセッションパラメータを管理していなければ、0-RTTでの動的テーブルの不整合リスクが高まる。インフラエンジニアとしては、OpenSSL/BoringSSLやNginx/Envoyなどのプロキシレイヤーで、TLSセッションキャッシュの分散共有（Redis等を用いたSession Ticket Keyの同期）を確実に行う必要がある。
LinuxカーネルのTCPバッファとパケロス耐性のジレンマ
HTTP/2のマルチプレクシングは、1本のTCPコネクション上で無数のストリームを多重化する。これはHTTP/1.1のHead-of-Line（HoL）ブロック問題を解決した一方で、「TCPレイヤーのHoLブロッキング」という新たなトレードオフを生んだ。
1つのTCPセグメントが途中でドロップすると、その背後にあるすべてのHTTP/2ストリームの到着が、再送パケットが届くまで完全に停止する。
したがって、HPACKでヘッダーサイズを削ってパケット数を減らすこと（あるいはMTUサイズ内にリクエストを収めること）は、パケットロス発生時のレイテンシー悪化を最小限に抑える上で極めて重要な意味を持つ。
プロダクション環境のLinuxサーバー（Ubuntu/RHELなど）では、以下のsysctlチューニングを施し、TCPの初期挙動を最適化することが定石となっている。
/etc/sysctl.d/99-http2-network-tuning.conf
TCP初期輻輳ウィンドウ（initcwnd）を10に拡大し、スロースタートを加速する
（クラウド環境のデフォルトでは既に大きいことが多いが、明示的に確認）
BBR混雑制御アルゴリズムの有効化（パケットロスに強いスループットを実現）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
TCPウィンドウの自動チューニング範囲の最適化
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
TCP Keepaliveの調整（アイドルコネクションの維持と切断検知の高速化）
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
—
4. 悪夢の脆弱性「HPACK Bomb」とセキュリティ対策
HPACKの設計における最大のダークサイド、それが HPACK Bomb（CVE-2019-9514など） に代表されるメモリ枯渇攻撃だ。
攻撃のメカニズム
HPACKの動的テーブルは、デコーダー側にメモリを消費させる。悪意あるクライアントが、極限までハフマン符号化された「わずか数バイトの非常に小さなヘッダーフレーム」を送りつけてきたとする。
しかし、その中身を展開（解凍）すると、数メガバイト、あるいは数ギガバイトにも及ぶ巨大なヘッダーフィールドの嵐となる。
デコーダーは、この膨大なヘッダーを処理するために動的テーブルを急速に拡大させ、サーバーのメモリを瞬く間に食いつぶす。結果として、サービス拒否（DoS）状態に陥る。これがHPACK Bombの恐るべき手口だ。
実務における防御策とパラメーターチューニング
この脆弱性やリソース枯渇を防ぐため、現代のHTTP/2実装（Nginx, Envoy, Goの `net/http` など）では、動的テーブルのサイズやヘッダーの最大長に対して厳格な制限を設けている。
例えば、NginxやEnvoyの設定ファイルでは、以下のようなディレクティブで防御壁を構築する。
NginxにおけるHTTP/2およびHPACK関連のセキュリティ・リソース制限の例
http {
# 1つのリクエスト内で処理するヘッダーの合計サイズの最大値（デフォルトは1m等だが厳しく制限を推奨）
large_client_header_buffers 4 8k;
# HTTP/2接続全体で許容する動的テーブルの最大サイズ（クライアントからの指示を上書き・制限する）
# 過度に大きなメモリ割り当てを防ぐ
http2_max_field_size 4k;
http2_max_header_size 32k;
# 同時ストリーム数の制限（過剰なマルチプレクシングによるリソース枯渇を防止）
http2_max_concurrent_streams 128;
}
アプリケーションレイヤー（Go, Node.js, Rustなど）で独自にHTTP/2サーバーを実装・運用する場合も、必ず `SETTINGS_MAX_DYNAMIC_TABLE_SIZE` を適切にハンドリングし、受信するヘッダーの累積サイズにハードリミットをかける実装が不可欠となる。
—
5. まとめ：パケットの細部に宿るアーキテクチャの美学
HPACKは、単に「HTTPヘッダーを小さくする便利な仕組み」ではない。
ネットワークの物理的な帯域幅、トランスポート層（TCP/TLS）のステート、そしてアプリケーション層のメモリ管理という、複数のレイヤーが緻密に噛み合った「システム工学の結晶」である。
インフラアーキテクトやテックリードとして私たちが向き合うべきは、単にクラウドのマネージドサービスで「HTTP/2を有効にする」というチェックボックスを外すことではない。パケットがどのようにバイナリに変換され、カーネルのバッファを揺らし、プロキシのメモリ空間に展開されているのか――その一連のライフサイクルを頭の中で完全にトレースできる解像度を持つことこそが、障害に強く、極限まで最適化された堅牢なWebインフラを作り上げる唯一の道なのである。
コメント