はじめに：HTTP/2の裏側でうごめく「記憶」の正体
こんにちは。ネットワークのパケットを長年追い続けていると、プロトコルの進化がいかに人間の知恵の結晶であるかを思い知らされます。HTTP/1.1の「毎度おなじみの長大なUser-AgentやCookieを、毎リクエストごとに律儀にプレーンテキストで送り続ける」という無駄なオーバーヘッド。あれを何とかしようと立ち上がったのがHTTP/2であり、その通信効率の心臓部こそが、今回深掘りするHPACK（Header Compression for HTTP/2）です。
HTTP/2のマルチプレクシング（多重化）がどれほど優秀でも、ヘッダーサイズが大きければTCPウィンドウはすぐに枯渇し、パケットの往復（RTT）に足を引っ張られます。特にマイクロサービスアーキテクチャ全盛の今、無数のリクエストが飛び交う環境では、ヘッダー圧縮の挙動を理解しているかどうかが、Web APIのレイテンシを数ミリ秒、あるいはそれ以上削り出すための分かれ道になります。
今回は、そのHPACKのなかでも最も動的かつ厄介であり、かつ強力な「動的テーブル（Dynamic Table）」の仕組みにスポットを当てます。RFC 7541の仕様の読み解きから、実務でのメモリ管理、そしてトラブルシューティングの勘所まで、現場の視点で徹底的に解説していきましょう。
—
1. 静的テーブル vs 動的テーブル：HPACKの基本構造
HPACKによるヘッダー圧縮は、一言で言えば「辞書引き」です。送信側と受信側が同じ辞書（テーブル）を共有し、ヘッダーのフィールド名や値そのものを送る代わりに、「辞書の何番目」というインデックス番号を送受信します。
この辞書は2つに分かれています。
1. 静的テーブル（Static Table）
- RFC 7541で定義された、変更不可能な61個の事前定義エントリ。
- `:method: GET`（2番）や `:path: /`（4番）など、Webで頻繁に使われる定番のペアが網羅されています。世界中のどのHTTP/2実装でも共通です。
2. 動的テーブル（Dynamic Table）
- 今回の主役です。 通信セッション（コネクション）の開始時は空ですが、リクエストやレスポンスが流れるたびに、新しく登場したヘッダーペアを追加（学習）していく可変長のテーブルです。
動的テーブルのライフサイクルとFIFOの原則
動的テーブルは、コネクション確立後に動的に成長します。新しいヘッダーフィールド（例: `custom-tracking-id: abc-12345`）がリクエストに含まれると、送信側はそれを動的テーブルの先頭（インデックス 62以降）に追加し、以降のパケットではそのインデックス番号を送信します。
ここで重要なのは、動的テーブルがFIFO（先入れ先出し）のキュー構造でありながら、インデックスの付番は「新着ほど若い番号（上）」になるという点です。
新しいエントリが追加されると既存のエントリは押し出され、最終的にテーブルの容量制限を超えた古いエントリは容赦なく破棄（Eviction）されます。
—
2. メモリ消費量制限の仕様と「SETTINGS_HEADER_TABLE_SIZE」
インフラエンジニアやバックエンドエンジニアにとって最も頭を悩ませるのが、この動的テーブルが消費するメモリの管理です。無限にヘッダーを記憶させていけば、サーバーのメモリはあっという間に枯渇してしまいます。
そこでRFCでは、動的テーブルの最大サイズを厳密にコントロールする仕組みが用意されています。
サーバー・クライアント間のネゴシエーション
1. 初期状態: 動的テーブルのデフォルトの最大サイズは 4,096オクテット（4KB） です。
2. SETTINGSフレームによる変更:
コネクション確立時のSETTINGSフェーズにおいて、受信側（通常はサーバー、またはクライアント）は、`SETTINGS_HEADER_TABLE_SIZE` というパラメーターを用いて、「私の動的テーブルは最大で〇〇バイトまで許容するよ」と相手に通知します。
3. エントリサイズの計算式:
動的テーブルに格納される1つのエントリのサイズは、単なる文字列の長さではありません。RFC 7541によれば、以下の計算式で求められます。
$$\text{エントリサイズ} = \text{名前のオクテット数} + \text{値のオクテット数} + 32$$
（※末尾の「32」は、データ構造のオーバーヘッドを考慮したパディング的な固定値です）
実務でのトラブル：テーブルサイズ超過と「Dynamic Table Size Update」
送信側（例えばクライアント）は、受信側が通知した `SETTINGS_HEADER_TABLE_SIZE` 以下のサイズに自分の動的テーブルを収める義務があります。もし受信側が途中から「メモリが厳しいのでテーブルサイズを2KBに縮小してくれ」と要求した場合、受信側は Dynamic Table Size Update という専用の制御指示をHPACKの先頭に挿入し、自身の動的テーブルを切り詰めます。
現場のデバッグでよくあるのが、「プロキシやロードバランサー（Nginx, Envoy, AWS ALBなど）とバックエンドのアプリケーション間で、このテーブルサイズの解釈や上限設定がミスマッチを起こし、RST_STREAM（エラーコード: COMPRESSION_ERROR）で接続が強制切断される」という現象です。
—
3. 通信フロー：パケットの中で何が起きているのか？
文字だけではイメージしにくいので、実際にHTTP/2の HEADERS フレームが流れるときのシーケンスと、HPACKのエンコード結果のイメージを見てみましょう。
[Client] [Server / Proxy]
│ │
│ ──(1) TCP Handshake & TLS Handshake (ALPN: h2) ───────────> │
│ │
│ ──(2) SETTINGS Frame (SETTINGS_HEADER_TABLE_SIZE: 4096) ──> │
│ <──(3) SETTINGS Frame (Ack) ─────────────────────────────── │
│ │
│ ──(4) HEADERS Frame (Stream #1) ──────────────────────────> │
│ – :method: GET (静的: #2) │
│ – :path: /api/v1/users (新規 -> 動的テーブル追加 #62) │
│ – user-agent: MyApp/1.0 (新規 -> 動的テーブル追加 #63) │
│ │
│ ──(5) HEADERS Frame (Stream #3) ──────────────────────────> │
│ – :method: GET (静的: #2) │
│ – :path: /api/v1/users (動的インデックス: #62 を使用!) │ <-- ここで圧縮効く！
│ - user-agent: MyApp/1.0 (動的インデックス: #63 を使用!) │
│ │
Stream #1の初回リクエストでは、パスやUser-Agentが文字列としてエンコードされつつ、動的テーブルに書き込まれます。
続くStream #2（図では#3）では、同じヘッダー群がたった数バイトのインデックス参照に置き換えられ、ネットワーク帯域を極限まで節約して流れていくわけです。
—
4. 実装・検証：Pythonとcurlで動的テーブルの挙動を覗き見する
百聞は一見にしかず。実際にHTTP/2通信を行い、ヘッダー圧縮の恩恵やデバッグ手法を確認してみましょう。
① `curl` を使ったHTTP/2通信の詳細トレース
現代の `curl` は優れたHTTP/2クライアントです。`-v`（verbose）オプションや `–http2` を使って、実際にどのようなフレームがやり取りされているかを確認できます。
HTTP/2を強制しつつ、詳細な通信ログ（ヘッダー含む）を標準エラー出力に出力
curl –http2 -v https://httpbin.org/get \
-H “X-Custom-App-Header: SuperService-v1” \
-H “X-Session-Token: token-xyz-98765”
インフラエンジニアのTips:
本番環境のロードバランサーやAPI Gateway（EnvoyやNginx）のアクセスログで、リクエストヘッダーのサイズ（$bytes_sent や %I %O など）を観察してみてください。同じコネクションを使い回すKeep-Alive（HTTP/2では単一コネクション上のマルチプレクシング）環境下で、2番目以降のリクエストのヘッダーサイズが劇的に小さくなっていることが確認できます。
② Python（`h2` ライブラリ）によるHPACK動的テーブルのシミュレーション
Pythonの低レベルHTTP/2ライブラリである `h2` を使うと、HPACKのエンコーダー/デコーダーが動的テーブルをどのように操作しているかをプログラム的に確認できます。
以下のコードは、同じカスタムヘッダーを2回送信した際に、動的テーブルを通じてサイズが圧縮される様子を模したものですギミックです。
必要なライブラリのインストール: pip install h2
from h2.hpack import HPackEncoder, HPackDecoder
def simulate_hpack_compression():
# エンコーダーとデコーダーの初期化（デフォルトテーブルサイズ: 4096バイト）
encoder = HPackEncoder()
decoder = HPackDecoder()
# 送信したいヘッダーのセット
headers_first_request = [
(“:method”, “GET”),
(“:path”, “/data”),
(“:authority”, “api.example.com”),
(“x-internal-tracking-id”, “uuid-12345-abcde”) # 動的テーブルに学習されるヘッダー
]
print(“— 1回目のリクエスト（初回：動的テーブル未登録） —“)
encoded_1 = encoder.encode(headers_first_request)
print(ジ インデックス/文字列化されたエンコードデータサイズ: {len(encoded_1)} バイト)
# デコーダー側でデコード（同時にデコーダー側の動的テーブルも更新される）
decoded_1 = decoder.decode(encoded_1)
print(f”デコード結果: {decoded_1}”)
print(“\n— 2回目のリクエスト（同一ヘッダー：動的テーブルからインデックス参照） —“)
headers_second_request = [
(“:method”, “GET”),
(“:path”, “/data”),
(“:authority”, “api.example.com”),
(“x-internal-tracking-id”, “uuid-12345-abcde”) # 2回目も同じヘッダー
]
encoded_2 = encoder.encode(headers_second_request)
print(f”エンコードデータサイズ: {len(encoded_2)} バイト (サイズが劇的に縮小！)”)
# デコード
decoded_2 = decoder.decode(encoded_2)
print(f”デコード結果: {decoded_2}”)
if __name__ == “__main__”:
simulate_hpack_compression()
このスクリプトを実行すると、2回目のエンコード結果のバイト数が1回目よりも明らかに小さくなることがわかります。これが、HPACKの動的テーブルがもたらす省フットワークな世界です。
—
5. 現場のトラブルシューティング：HPACK関連のエラーと向き合う
最後に、実務で遭遇しがちなHPACK起因のトラブルとその切り分け手法を共有しておきます。
よくある障害: `COMPRESSION_ERROR`
- 症状: クライアントからリクエストを送った際、サーバー（または途中のリバースプロキシ）から突然 `RST_STREAM` が返され、エラーコードに `COMPRESSION_ERROR`（HTTP/2エラーコードの `0x9`）が記録される。
- 原因の多く:
1. テーブルサイズの同期ズレ: クライアント側とサーバー側の動的テーブルの最大サイズ解釈がおかしくなり、クライアントが大きすぎるインデックスを参照してしまった。
2. 不正なハフマン符号化: HPACKではヘッダーの圧縮にハフマン符号化が使われますが、パケットの破損や実装のバグにより、デコード不可能なビット列が送り込まれた。
- デバッグのアプローチ:
- `tcpdump` や Wireshark でパケットをキャプチャし、HTTP/2の `SETTINGS` フレーム（特に `SETTINGS_HEADER_TABLE_SIZE` の値）が正しく交わされているかを確認します。
- EnvoyやNginxを使用している場合は、デバッグレベルのログ（`–log-level debug` など）を一時的に有効にし、HPACKのデコード失敗に関する警告が出ていないかを精査します。
—
おわりに
HTTP/2のHPACK動的テーブルは、普段私たちが意識することなく、Webの高速化を裏で支えている静かなる功労者です。しかし、その内部で「メモリ制限の管理」「インデックスの同期」「FIFOによるエントリの入れ替え」といった緻密なステート管理が行われていることを知るだけで、トラブルシューティングの視野は一気に広がります。
ネットワークの挙動に行き詰まったときは、パケットを分解し、プロトコルが交わした「記憶のやり取り」に思いを馳せてみてください。きっと、バグの原因を見つけ出すための鮮やかな糸口が見つかるはずです。
それでは、また次のパケット解析の旅でお会いしましょう。
コメント