はじめに：HTTP/2ヘッダー圧縮の「真の姿」を見誤っていませんか？
こんにちは。ネットワークの裏側でうごめくパケットの息吹を感じ取るのが日課のシニアアーキテクトです。
Web APIの設計や、大規模なインフラのパフォーマンスチューニングに携わっていると、必ずと言っていいほど「HTTP/2の恩恵」に預かります。HTTP/1.1の呪縛であった HOL（Head-of-Line）ブロッキングをマルチプレクシングで華麗に打ち破り、ひとつのTCPコネクション上で無数のリクエストとレスポンスを同時に往復させる――。現代のWebを支える、美しくも力強い仕組みです。
しかし、現場でバリバリとインフラを触るエンジニアから、時々こんな質問を受けます。
「マルチプレクシングで同時並行にリクエストを投げまくっているのに、なぜか特定のエンドポイントだけ想定よりレイテンシーが落ちない。パケットキャプチャを見ると、何やらヘッダー周りで小賢しいやり取りをしているようだが……？」
そう。HTTP/2の高速化の立役者はマルチプレクシングだけではありません。もう一つの主役が、今回深掘りする「HPACK（HTTP/2 Header Compression）」、そしてその心臓部である「動的テーブル（Dynamic Table）」です。
リクエストのたびに送信されていた、あの冗長な `User-Agent` や `Authorization`、Cookieの山。これらをいかにスマートに圧縮し、限られた帯域の王様としてパケットを走らせているのか。RFC 7540およびRFC 7541の仕様の泥臭い現実と、実務で絶対に知っておくべきデバッグの勘所を、一緒に紐解いていきましょう。
—
1. なぜHTTP/2には「HPACK」が必要だったのか？
HTTP/1.1の時代、ブラウザからサーバーへ送られるリクエストヘッダーは、プレーンテキストのまま毎回フルセットで送信されていました。
GET /api/v1/users HTTP/1.1
Host: api.example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36…
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Language: ja,en-US;q=0.9,en;q=0.8
Cookie: session_id=abc123xyz789; _ga=GA1.2.123456789.1234567890
このリクエスト、データ本体（ペイロード）が数バイトの小さなJSONであっても、ヘッダーだけで1キロバイト近くに達することが珍しくありません。
HTTP/2になり、1つのTCPコネクション上で複数のストリームを同時に多重化（マルチプレクシング）できるようになりました。もしHTTP/1.1と同じノリで、並行する数十のストリームのそれぞれにこの巨大なヘッダーを乗せていたらどうなるでしょうか？
「帯域の無駄遣い」どころか、スロースタート直後のTCPウィンドウサイズを瞬時に食いつぶし、かえってレイテンシーを悪化させる本末転倒な事態に陥ります。
そこで考案されたのが、ヘッダー専用の圧縮アルゴリズム「HPACK」です。
—
2. HPACKの核心：静的テーブルと「動的テーブル」の仕組み
HPACKの基本戦略は極めてシンプルです。「すでに送ったことのある文字列や、よく使われる標準的なヘッダーは、長い文字列のまま送らず、小さなインデックス番号に置き換えよう」というアプローチです。
HPACKには、2種類のテーブルが存在します。
1. 静的テーブル（Static Table – RFC 7541 Appendix A）
- あらかじめRFCで定義された、変更不可能な61個のエントリのリスト。
- 例: `(‘:method’, ‘GET’)` はインデックス `2`、`(‘:path’, ‘/’)` はインデックス `4`、`(‘content-type’, ‘application/json’)` はインデックス `31` といった具合に、世界共通の番号が振られています。
2. 動的テーブル（Dynamic Table）
- ここが今回の主役です。
- コネクション（セッション）が確立された後、通信のやり取りの中で新しく登場したヘッダー（キーと値のペア）を、その都度動的に追加・学習していくテーブルです。
動的テーブルのライフサイクル（通信フロー）
言葉だけではイメージしにくいので、クライアントとサーバーの間で動的テーブルがどのように更新されるか、シーケンスのイメージを追ってみましょう。
[Client] [Server]
| |
|— (1) HEADERS: path=/api/data, user-agent=xxx –>|
| クライアントは動的テーブルに新規エントリを追加 |
| 送信データは「インデックス番号」または差分に変換 |
| |
| | サーバーは受信したヘッダーを
| | 同じアルゴリズムで復元し、
| | サーバー側の動的テーブルへ追加
| |
|<-- (2) HEADERS: status=200, cache-control=... ----|
| サーバーも独自の動的テーブルを更新・参照 |
| |
|--- (3) HEADERS: path=/api/data, user-agent=xxx -->|
| 次のリクエストでは、すでに動적テーブルにあるため、 |
| 長大な文字列ではなく「インデックス番号」だけで送信！|
一度通信に登場した `User-Agent` やカスタムヘッダー（例: `X-Request-ID` や認証トークンの一部）は、動的テーブルにインデックス（通常は静的テーブルの62番目以降）として登録されます。
2回目以降のリクエストでは、そのヘッダー名と値を送る代わりに、「動的テーブルのインデックス番号いくつ」というわずか数バイトのデータを送るだけで済むようになります。これが、HTTP/2が「爆速」である隠された理由の1つです。
—
3. メモリを守る防衛線：テーブルサイズ制限と更新アルゴリズム
無限にヘッダーを学習し続けたらどうなるでしょうか？サーバーやクライアントのメモリがいくらあっても足りません。悪意ある攻撃者が毎回異なるランダムなヘッダーを送りつけて動的テーブルを肥大化させ、メモリを枯渇させる「HPACKテーブル爆弾（Memory Exhaustion Attack）」を防ぐ必要があります。
テーブルサイズの制御（SETTINGS_HEADER_TABLE_SIZE）
HPACKでは、動的テーブルの最大許容サイズ（オクテット単位）が厳密に管理されています。
- デフォルトの上限サイズは 4,096オクテット（4KB） です。
- コネクション確立時の初期設定（SETTINGSフレーム）において、サーバー側またはクライアント側から `SETTINGS_HEADER_TABLE_SIZE` を変更して、上限を交渉（通知）することができます。
エントリの追い出し（Eviction Policy）アルゴリズム
動的テーブルの現在サイズが設定された最大サイズを超過した場合、古いエントリから順に自動的に削除（追い出し）されるFIFO（First-In, First-Out）に近い仕組みで制御されます。
1. 新しいヘッダーペアが動的テーブルに追加される。
2. 追加されたペアのサイズ（ヘッダー名と値の長さ、およびHTTP/2のオーバーヘッドである32オクテットを加算したバイト数）が計算される。
3. 動的テーブル全体のサイズが許容最大サイズを超える場合、最も古くから存在するエントリがテーブルからパージ（削除）される。
4. これを、最大サイズ以内に収まるまで繰り返す。
現場のインフラエンジニアとして注意すべきは、「極端に大きなカスタムヘッダーを大量に送受信するWeb API設計にすると、動的テーブルの入れ替え（Churn）が激しくなり、CPUやメモリのキャッシュ効率に悪影響を及ぼす可能性がある」という点です。ヘッダーの肥大化は、HTTP/2であっても百害あって一利なしです。
—
4. 実務で役立つ！検証とデバッグの現場から
理論を頭に叩き込んだところで、実務でのトラブルシューティングや挙動確認に使える具体的な手法を見ていきましょう。
ツール1: `curl` でHTTP/2のヘッダー圧縮を覗き見る
現代の `curl` は非常に優秀です。詳細な通信ログを出力させることで、HTTP/2のフレームやヘッダーがどのように流れているかを確認できます。
–http2 オプションを指定し、-v（詳細出力）と –trace-ascii でパケットの生データに近いログを取得
curl –http2 -v –trace-ascii h2_trace.log https://httpbin.org/get
生成された `h2_trace.log` を開くと、`HEADERS` フレームの中にHPACKによってエンコードされたバイナリデータが流れているのが確認できます。生で読むのは解読作業が必要ですが、「ちゃんとHTTP/2でネゴシエーションできているか」「ALPNで `h2` が選択されたか」を切り分ける第一歩になります。
ツール2: Node.js (Fetch API) や Python での確認
アプリケーションコード側からHTTP/2のコネクションを意識することは稀ですが、リバースプロキシ（NginxやEnvoy）の向こう側でAPIクライアントを実装する際には、コネクションプーリングとHTTP/2の挙動を意識する必要があります。
以下は、Pythonの `httpx` ライブラリ（HTTP/2をネイティブサポート）を使用して、同一セッション内で複数回リクエストを送り、ヘッダー効率の恩恵を受けるコード例です。
必要なライブラリのインストール: pip install httpx[http2]
import httpx
def main():
# httpx.Clientを使うことで、単一のTCPコネクションを維持（コネクションプール）
# http2=True を明示的に有効化
with httpx.Client(http2=True) as client:
url = “https://httpbin.org/headers”
# 共通のカスタムヘッダーを定義
headers = {
“X-Custom-App-Identifier”: “Superduper-API-Client-v1”,
“User-Agent”: “NetworkArchitectBlogBot/1.0”,
}
print(“— 1回目のリクエスト（動的テーブルへの登録が発生） —“)
response1 = client.get(url, headers=headers)
print(f”Status: {response1.status_code}”)
print(response1.json().get(“headers”, {}))
print(
“\n— 2回目のリクエスト（動的テーブルからヘッダーが圧縮される） —”
)
# 同じカスタムヘッダー群を送るため、HPACKの動的テーブルがヒットする
response2 = client.get(url, headers=headers)
print(f”Status: {response2.status_code}”)
print(response2.json().get(“headers”, {}))
if __name__ == “__main__”:
main()
このスクリプトを走らせたとき、2回目のリクエストでは、1回目でサーバー側の動的テーブルに学習された `X-Custom-App-Identifier` などのヘッダーが、インデックス参照（あるいはスマートなハフマン符号化）によってパケットサイズを極限まで削られて流れていきます。
—
5. インフラ運用の現場における「落とし穴」とTips
最後に、長年ネットワークやインフラの現場を渡り歩いてきた私から、HPACKの動적テーブルにまつわる実務的な教訓（Tips）をいくつか授けます。
1. NginxやEnvoyなどのリバースプロキシのバッファチューニング
- バックエンドのマイクロサービス群の前段に置くプロキシ（API Gatewayなど）では、HPACKの動的テーブルサイズ（`http2_max_requests` や `hpack_table_size` などのディレクティブ）のデフォルト値に注意してください。
- クライアントからのヘッダーが異常に大きい、あるいは多数のカスタムヘッダーを乱発するアーキテクチャの場合、プロキシ側で `SETTINGS_HEADER_TABLE_SIZE` の調整が必要になるケースがあります。
2. 「Cookie」の扱いに要注意
- Webアプリケーションで最もヘッダーサイズを肥大化させる張本人は依然として `Cookie` です。
- HTTP/2のHPACKは優秀ですが、Cookieのバリューがリクエストごとに細かく変わる（例: セッションID、トラッキングID、A/Bテストのフラグなどがバラバラに更新される）と、動的テーブルのエントリが頻繁に入れ替わり、キャッシュヒット率（テーブルヒット率）がガタ落ちします。
- API設計の段階で、「本当にそのCookieは毎回必要か？ AuthorizationヘッダーやBearerトークンに一本化できないか」を再検討することが、真のネットワーク最適化につながります。
おわりに
HTTP/2のHPACK、そして動的テーブルの仕組みは、一見すると「プロトコルの奥深くで勝手に動いてくれる黒魔術」のように見えます。しかし、その中身を紐解けば、限られたネットワーク帯域をいかに1バイトでも削って効率的に使うかという、先人たちの泥臭い知恵と工夫の結晶であることが分かります。
「なぜかレイテンシーが改善しない」「プロキシのメモリ使用量がじわじわ増える」。そんなトラブルに直面したとき、パケットの向こう側でうごめく動的テーブルの息吹を思い出してください。きっと、最短で原因を突き止めるための羅針盤になるはずです。
それでは、また次の現場でお会いしましょう。快適なパケットライフを！
コメント