こんにちは。ネットワークの底流で蠢くパケットの息吹を感じるたび、この仕事のロマンに酔いしれてしまうシニアネットワークエンジニアの私だ。
これまで幾度となく、Webサービスのパフォーマンスチューニングの現場に立ち会ってきた。データベースを最適化し、CDNを導入し、フロントエンドのコードを削りまくってもなお、なぜかAPIのレスポンスがスループットの壁に阻まれる――そんな現場で、パケットキャプチャを開いて我々が最後にたどり着く聖域が、「HTTP/2の内部構造」である。
今回は、そのHTTP/2における隠れた主役、いや、電送効率を極限まで高めるための密かなる立役者「HPACK（HTTP/2 Header Compression）におけるハフマン符号化」について、実務的な視点を交えて徹底的に紐解いていこう。
教科書通りのRFCの丸暗記ではなく、現場のトラブルシューティングやAPI設計にどう直結するのか、泥臭い実例とともに解説する。コーヒーでも片手に、しばし技術の深淵に付き合ってほしい。
—
なぜHTTP/2ヘッダー圧縮（HPACK）が必要だったのか
HTTP/1.1の時代、数々のWebエンジニアを泣かせてきた最大のボトルネックは何だったか？ そう、「Cookie汚染」を含む冗長なHTTPヘッダーの肥大化だ。
1回あたりのリクエストはわずか数百バイトであっても、CookieやUser-Agent、Authorizationヘッダーなどが毎度プレーンテキストで往復する。これが数メガバイトの画像や数十のAPIコールと並行して発生すると、往復遅延時間（RTT）の大きさと相まって、TCPのウィンドウ制御をジリジリと圧迫していった。
「よし、ヘッダーを圧縮しよう！」——そこで登場したのがHTTP/2のHPACK（RFC 7541）である。
HPACKは、以下の2つのアプローチでヘッダーを極限まで圧縮する。
1. インデックス付きヘッダーリスト（Static/Dynamic Table）: すでに送信したヘッダー（例: `:method: GET` や `content-type: application/json`）をテーブルに登録し、次回からは小さなインデックス番号（整数）だけでやり取りする。
2. ハフマン符号化（Huffman Coding）: テーブルに載っていない未知のヘッダー名や値について、出現頻度の高い文字に短いビット列を割り当て、全体のバイト数を物理的に削り取る。
今回は、この後者の「ハフマン符号化」の深層へとダイブする。
—
ハフマン符号化のメカニズム：RFC 7541の静的テーブルが生んだ「可変長ビット」の魔法
ハフマン符号化の基本原理はシンプルだ。「よく使われる文字には短いビットを、滅多に使われない文字には長いビットを割り当てる」。モールス信号やZIP圧縮と同じ思想である。
しかし、HTTP/2のHPACKにおいて特筆すべきは、「RFC 7541のAppendix Bで定義された静的なハフマン符号表」が全クライアント・サーバー間でハードコード（共通共有）されている点だ。
符号化のリアルな挙動
例えば、APIのカスタムヘッダーとして `X-Request-ID` という文字列を送るとしよう。
通常のASCII（UTF-8）であれば、1文字＝1バイト（8ビット）なので、 `X-Request-ID` は 11文字 × 8 = 88ビット（11バイト）を消費する。
しかし、HPACKのハフマン符号表を通すと、高頻度で出現する文字（例えば小文字の `e` や `t` など）には数ビットのコードが割り当てられているため、ビット列がグッと圧縮される。
ここで、インフラエンジニアとして絶対に知っておくべき「パディングの罠」がある。
ハフマン符号化されたビット列は、必ずしも「8ビットの倍数（バイト境界）」で綺麗に終わるとは限らない。そのため、ビット列の末尾には「すべて1（全ビットが1）」のパディングが隙間を埋めるためにパッキングされる。
> 実務のTips:
> パケット解析（Wireshark等）でHTTP/2のHEADERSフレームを覗いたとき、ハフマン符号化された値の先頭ビットが `1`（HフラグがON）になっているのを確認できるはずだ。もし自前でHTTPクライアントを実装したり、プロキシの挙動をデバッグしたりする際、このパディングのパース処理を誤ると `COMPRESSION_ERROR`（HTTP/2のエラーコード: 0x9）を食らってコネクションが強制切断される。覚えておいて損はない。
—
通信の裏側：HPACKとハフマン符号化のシーケンス
HTTP/2のコネクション確立後、実際にリクエストヘッダーがどのように流れていくのか、そのシーケンスを追ってみよう。
[Client] [Server/API Gateway]
| |
|— 1. SETTINGS (HPACKの動的テーブルサイズ通知等) —————–>|
|<-- 2. SETTINGS (ACK) -----------------------------------------------|
| |
|--- 3. HEADERS Frame (ストリームID: 1) ----------------------------->|
| └─ :method: GET (静的テーブル: インデックス 2) |
| └─ :path: /api/v1/users (静的テーブル + ハフマン符号化) |
| └─ x-custom-token: abc123xyz (新規ヘッダー -> 動的テーブル追加) |
| |
|<-- 4. HEADERS Frame (ストリームID: 1) / DATA Frame -----------------|
| └─ :status: 200 (静的テーブル: インデックス 8) |
| └─ content-type: application/json (静的テーブル) |
クライアントがリクエストを送る際、HPACKのコンテキスト（Encoder/Decoder）が双方で同期される。
初めて登場する文字列（例えば動的なAPIトークンやUUID）はハフマン符号化されてバイト数が圧縮された上で送信され、同時にサーバー側の「動的テーブル（Dynamic Table）」にキャッシュされる。
2回目以降のリクエストでは、その動的テーブルを指し示すインデックスを送るだけで済むため、ハフマン符号化ですら不要になり、オーバーヘッドは極限までゼロに近づく。
—
実務で使える！検証・デバッグコードと設定例
理論を頭に入れたところで、日々の開発やインフラ運用で直面するシチュエーションに応じた具体的なコードと設定を見ていこう。今回は「Python」「cURL」「Nginx」の3つのアプローチを用意した。
1. Python (HTTP/2対応ライブラリ `h2` / `httpx`)
モダンなPythonアプリケーションからHTTP/2 APIを叩く際、HPACKのエンコード/デコードはライブラリがブラックボックスとして処理してくれる。しかし、挙動を監査したいときは `httpx` が便利だ。
import httpx
def fetch_api_with_http2():
# HTTP/2を強制してAPIエンドポイントにリクエストを送信
# 内部的にHPACK（ハフマン符号化含む）が適用され、ヘッダーが圧縮されて送信されます。
url = “https://http2.golang.org/reqinfo”
# クライアントの初期化（HTTP/2を有効化）
with httpx.Client(http2=True) as client:
headers = {
“user-agent”: “MyCustomApiClient/1.0.0”,
“x-api-signature”: “sha256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855″
}
response = client.get(url, headers=headers)
print(f”ステータスコード: {response.status_code}”)
print(f”使用されたプロトコル: {response.http_version}”) # “HTTP/2” が出力されることを確認
print(“レスポンスボディ:”)
print(response.text)
if __name__ == “__main__”:
fetch_api_with_http2()
2. cURLによるHTTP/2通信の強制とヘッダー確認
インフラの疎通確認や、プロキシ（EnvoyやNginx）の挙動テストには `curl` が一番の相棒だ。`-v` オプションをつけて、HTTP/2のネゴシエーションと送受信ヘッダーを丸裸にしよう。
!/bin/bash
–http2 オプションを指定して、強制的にHTTP/2でリクエストを飛ばす
-v でTLSハンドシェイク、ALPN（h2）、HEADERSフレームのやり取りをデバッグ出力
curl -v –http2 “https://http2.golang.org/reqinfo” \
-H “X-Debug-Environment: staging-cluster-01” \
-H “X-Trace-Id: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d”
【実務メモ】
出力結果の ” Using HTTP/2, stream 1″ や
“> GET /reqinfo HTTP/2” の表示を確認することで、
正しくHTTP/2（＝HPACKが有効な通信）で行われていることが分かります。
3. Nginx リバースプロキシの設定例
API GatewayやフロントエンドのNginxでHTTP/2を受け付ける際の設定だ。Nginxはバックエンドとの通信（HTTP/1.1など）とフロントエンドとの通信（HTTP/2）の間で、HPACKのデコード/エンコードをよしなにやってくれる。
server {
listen 443 ssl http2; # HTTP/2を有効化（nginx 1.25.1以降は listen 443 ssl; + http2 on;）
server_name api.example.com;
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
# 推奨されるモダンなTLS設定
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# HPACKの動的テーブルサイズを最適化（デフォルトは4096だが、メモリとCPUのトレードオフで調整）
# ※nginxのコア設定では直接変更できない場合もあるが、Workerプロセスやバッファサイズを適切に取るのが定石
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;
location / {
proxy_pass http://backend_upstream;
proxy_http_version 1.1;
# クライアントからのHTTP/2ヘッダーをバックエンドに引き渡す際の注意点
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
—
トラブルシューティング：現場でハマる「HPACKの闇」
最後に、シニアとして後輩たちに伝えておきたい「現場で本当にあった怖い話（トラブル事例）」を共有しよう。
ある大規模API基盤のリニューアル案件で、特定の巨大なカスタムヘッダー（JWTや複雑なメタデータを含む）を送信したところ、一部のクライアントからのリクエストが `RST_STREAM` で弾かれる現象が発生した。
原因をWiresharkで追うと、サーバー側のHPACKデコーダーが `SETTINGS_HEADER_TABLE_SIZE` の制限を超えた動的テーブルの更新を検知し、安全のためにコネクションをブツ切りにしていたのだ。
対策
1. 動的テーブルサイズの調整: クライアントとサーバー間でネゴシエーションされる `SETTINGS_HEADER_TABLE_SIZE` の値が乖離していないか確認する。
2. 不要なカスタムヘッダーの削減: ハフマン符号化があるとはいえ、数キロバイトもある巨大なJSONをそのままヘッダーに載せる設計自体がHTTP/2の思想（ボディに載せるべき）に反している。API設計の段階で、ヘッダーは必要最小限のメタデータに絞るべきだ。
—
おわりに
HTTP/2のHPACK、そしてハフマン符号化は、私たちが普段何気なく叩いているAPIの裏側で、ネットワーク帯域を1バイトでも削り取ろうとする先人たちのエンジニアリングの結晶である。
この仕組みを深く理解しているか否かで、パフォーマンスチューニングの引き出しの数、そして障害発生時の原因究明のスピードが圧倒的に変わってくる。
今日の帰宅時、ふとスマホで叩くAPIの裏側を流れるパケットに思いを馳せてみてほしい。きっと、いつもとは少し違った景色に見えるはずだ。
それでは、次のインフラの海原でまた会おう。健闘を祈る！
コメント