HTTP/2 HPACKの真髄：ハフマン符号化でヘッダーの「無駄な贅肉」を削ぎ落とす技術
こんにちは。ネットワークの現場で幾度となくパケットキャプチャを開き、数バイトのオーバーヘッドに泣かされ、そして笑ってきたシニアエンジニアです。
前回のHTTP/1.1からHTTP/2への進化において、私たちは「マルチプレクシング」という強力な武器を手に入れました。1本のTCPコネクション上で複数のリクエストとレスポンスを同時に流せるこの仕組みは、Webの表示速度を劇的に改善しました。しかし、忘れてはならないもう一つの主役がいます。それがHPACK（HTTP/2 Header Compression）です。
「たかがHTTPヘッダーの圧縮だろう？」と侮るなかれ。User-AgentやCookie、Authorizationといった文字列の羅列は、実はリクエストボディすら持たない小さなAPIリクエストにおいて、通信量の大部分を占める「隠れた肥満の原因」です。HTTP/2はこのヘッダーの肥満を解消するためにHPACKを導入し、その中核技術として「ハフマン符号化（Huffman Coding）」を採用しました。
今回は、このハフマン符号化がHTTP/2の内部でどのようにデータを圧縮し、私たちのWeb APIやインフラ通信を高速化しているのか、パケットの挙動や実務でのデバッグ手法を交えて徹底的に解説します。
—
1. なぜHTTP/2にヘッダー圧縮が必要なのか？
HTTP/1.1の時代、ブラウザは1つのドメインに対して最大6つ程度のTCPコネクションを張り、リクエストごとに膨大なテキストベースのヘッダーを送信していました。CookieやUser-Agentは毎回のリクエストで全く同じ内容を送信し続けており、これは帯域の大きな無駄でした。
HTTP/2ではコネクションが1つに統合された（単一のTCPコネクションの多重化）ため、ヘッダーの重複送信を排除する仕組みが急務となりました。そこで登場したのがHPACKです。
HPACKは大きく分けて2つのアプローチでヘッダーを小さくします。
1. 静的・動的テーブル（Static / Dynamic Table）: 既出のヘッダー名や値をインデックス番号（整数）に置き換える。
2. ハフマン符号化（Huffman Coding）: 文字列そのものの文字頻度に基づき、出現頻度の高い文字には短いビット列を、低い文字には長いビット列を割り当ててバイナリサイズを極限まで削る。
今回はこの後者の「ハフマン符号化」に焦点を当てます。
—
2. ハフマン符号化の仕組みとRFC 7541の静的ハフマンテーブル
ハフマン符号化のアルゴリズム自体は情報理論の古典ですが、HTTP/2（RFC 7541）において特筆すべきは、「すべてのHTTP/2実装が共有する、固定の静的ハフマン符号表（Static Huffman Table）」があらかじめ定義されているという点です。
固定テーブルの強みとエンコードの裏側
通常、ハフマン符号化を行う際は、送信するデータごとに文字の出現頻度をカウントし、その都度「ハフマン木」を構築してデータと一緒に相手に送る必要があります（動的ハフマン符号）。しかし、HTTP/2の設計者たちはこう考えました。
> 「WebのHTTPヘッダーで使われる文字（アルファベット、数字、記号）の出現傾向なんて、世界中どこでも大体同じだろ？」
この慧眼に基づき、RFC 7541のAppendix Bには、ASCII文字や制御文字など256個のシンボルに対して、あらかじめ最適化されたビットパターン（最大30ビット超）の固定テーブルが焼き込まれています。
これにより、送信側は木を構築するオーバーヘッドなしに、単にテーブルをルックアップして文字列をビット列に置換するだけで済むのです。受信側も同じテーブルを持っているため、受け取ったビット列を迷うことなく元の文字列に復元（デコード）できます。
具体例：文字サイズはどう縮むのか？
例えば、ヘッダー値によく登場する文字列 `”www.example.com”` を考えてみましょう。
通常のASCIIエンコード（1文字＝8ビット固定）であれば、15文字なので `15 × 8 = 120ビット（15バイト）` 必要です。
しかし、HPACKのハフマン符号表では、出現頻度の高い `’w’` や `’e’`、 `’.’` には数ビット（2〜5ビット程度）の非常に短いコードが割り当てられています。これらを緻密にパッキングしていくと、この文字列はおよそ 70ビット強（約9バイト） まで圧縮されます。約40%の削減です。これが数万回、数百万回と行われるAPI通信において、どれほどのネットワーク帯域節約になるかは想像に難くありません。
—
3. 通信フロー：HPACKエンコード・デコードの裏側
実際の通信において、HPACKで圧縮されたヘッダーは、HTTP/2のフレーム構造の中にどのように格納されているのでしょうか。シーケンスとデータ構造を見てみましょう。
[Client (HTTP/2 Client)] [Server (HTTP/2 Server)]
| |
|— 1. HEADERSフレーム送信 (HPACK圧縮済み) ——->|
| (Hフラグ=1: ハフマン符号化適用) |
| (:path, :method, custom-tokenなど) |
| |– 2. HPACKデコード
| | (静的/動的テーブル参照 ＋
| | ハフマン復号)
| |
|<-- 3. HEADERS / DATAフレームレスポنس -------------|
| |
パケットレベルでは、HTTP/2の `HEADERS` フレームのペイロード部に、HPACKのバイト列が入ります。
ハフマン符号化が適用されている文字列の先頭バイトには、Hビット（Huffman Bit = 1）というフラグが立ちます。これにより、受信側は「この値はハフマン符号化されているから、デコードが必要だ」と瞬時に判断します。
—
4. 実務で役立つ！HTTP/2 & HPACKの確認・デバッグ手法
現場のエンジニアにとって最も重要なのは、「本当に意図通りに効率的な通信が行われているか」「プロキシやCDNが正しくHTTP/2を処理しているか」を確認するスキルです。
ここでは、Pythonと`curl`コマンドを用いて、実際のHTTP/2通信とヘッダーの振る舞いを確認・検証する方法を紹介します。
実装例1: Python (h2ライブラリ) による低レイヤー通信の観察
HTTP/2のコネクションやフレームをプログラムから直接制御・観察したい場合、Pythonの`h2`ライブラリが強力です。以下のコードは、HTTP/2クライアントとしてリクエストを送り、ヘッダーがどのように構築されるかの一端を示しています。
必要なライブラリ: pip install h2 hpack hyper-h2
import h2.connection
import h2.config
import socket
import ssl
def send_http2_request():
# 接続先の設定（例: nghttp2.org等のHTTP/2対応サーバー）
server_host = “nghttp2.org”
server_port = 443
# TLSコンテキストの設定（HTTP/2にはALPNによるnegotiationが必須）
ctx = ssl.create_default_context()
ctx.set_alpn_protocols([‘h2’])
# ソケット接続の確立
with socket.create_connection((server_host, server_port)) as sock:
with ctx.wrap_socket(sock, server_hostname=server_host) as ssock:
# H2コネクションの初期化
c_config = h2.connection.H2Configuration(client_side=True)
conn = h2.connection.H2Connection(config=c_config)
conn.initiate_connection()
ssock.sendall(conn.data_to_send())
# 送信ヘッダーの定義（擬似ヘッダーを含む）
# HPACKのエンコーダーが自動的にインデックス化やハフマン符号化を適用します
headers = [
(‘:method’, ‘GET’),
(‘:path’, ‘/httpbin/headers’),
(‘:authority’, server_host),
(‘:scheme’, ‘https’),
(‘user-agent’, ‘NetworkArchitect-H2-Client/1.0’),
(‘accept’, ‘application/json’),
]
# ストリームID 1 でHEADERSフレームを生成・送信
stream_id = 1
conn.send_headers(stream_id, headers, end_stream=True)
ssock.sendall(conn.data_to_send())
print(“[+] HTTP/2 リクエストを送信しました。HPACKにより最適化されています。”)
# レスポンスの簡易受信ループ
while True:
data = ssock.recv(65535)
if not data:
break
events = conn.receive_data(data)
for event in events:
if isinstance(event, h2.events.ResponseReceived):
print(f”\n[+] レスポンスヘッダー受信 (Stream ID: {event.stream_id}):”)
for k, v in event.headers:
print(f” {k.decode(‘utf-8’)}: {v.decode(‘utf-8’)}”)
outdata = conn.data_to_send()
if outdata:
ssock.sendall(outdata)
if __name__ == “__main__”:
send_http2_request()
実装例2: `curl` によるHTTP/2とヘッダー詳細のダンプ
実務のトラブルシューティングにおいて、最も手軽で確実なのは `curl` を用いたデバッグです。`-v`（verbose）オプションや `–http2` オプションを駆使して、HTTP/2が正しくネゴシエートされているかを確認します。
–http2 オプションを指定して、HTTP/2での通信を強制しつつ詳細ログを出力する
curl -v –http2 https://nghttp2.org/httpbin/get
【出力の見方のポイント】
1. TLSハンドシェイク時に ALPN が “h2” を選択していることを確認する
ALPN, server accepted to use h2
2. 送信されるリクエストヘッダーがHTTP/2の擬似ヘッダー(:method, :pathなど)に変換されていることを確認する
> GET /httpbin/get HTTP/2
> Host: nghttp2.org
> User-Agent: curl/7.81.0
> Accept: /
さらに深く、パケットレベル（HPACKのバイナリやハフマン符号化された実データ）まで覗き見たい場合は、`nghttp` コマンド（`nghttp2` パッケージに含まれるツール）や、おなじみ Wireshark を使用します。
WiresharkでのデバッグTips:
1. ブラウザや `curl` の通信をPCAPでキャプチャする。
2. 秘密鍵（TLS Session Key）をWiresharkに読み込ませて復号（TLS Decryption）を有効にする。
3. プロトコルフィルタに `http2` と入力する。
4. `HEADERS` フレームを選択し、Detailペインで HPACK のテーブルインデックスやハフマンエンコードされたセグメントがどのように展開されているかを確認する。
—
5. 現場の教訓：HPACKとハフマン符号化を意識したAPI設計のベストプラクティス
最後に、インフラエンジニアやAPIアーキテクトとして、このHPACKの特性を踏まえた「現場で役立つ設計の知見」をいくつか共有します。
1. カスタムヘッダーの乱用に注意する
HPACKの「動態テーブル」は、コネクションごとに送受信された新しいヘッダーをキャッシュします。もしリクエストごとに毎回異なるランダムなカスタムヘッダー（例: `X-Request-ID` など）を巨大な値で送り続けると、動的テーブルの領域がすぐに埋まり、古いエントリが追い出されてキャッシュヒット率が下がります。動的テーブルのサイズ（SETTINGS_HEADER_TABLE_SIZE）の肥大化にも注意が必要です。
2. 頻出するヘッダー名は小文字で、かつ静的テーブルを意識する
HTTP/2の仕様上、ヘッダー名はすべて小文字でなければなりません。また、よく使われるヘッダー（`content-type`, `cache-control` など）はすでにHPACKの静的テーブルに登録されているため、文字列としてではなく1バイトのインデックスとして流れます。無駄な独自カスタムヘッダーを増やすより、標準的なヘッダーを適切に使う方が圧倒的に効率的です。
3. gRPC（HTTP/2ベース）における効果
マイクロサービス間で多用される gRPC も底層は HTTP/2 です。頻繁にやり取りされるメソッド名やパラメータのメタデータは HPACK によって強烈に圧縮されています。「gRPCはなぜJSON/RESTより速いのか」の理由の大きなピースの一つが、このハフマン符号化を含むヘッダー圧縮にあることを覚えておいて損はありません。
—
おわりに
HPACKのハフマン符号化は、普段私たちが何気なくブラウザやAPIクライアントから叩いているリクエストの裏側で、ネットワークの物理的な限界に挑む地味ながらも極めて洗練された技術です。
「なぜこのエラーが起きるのか」「なぜこのレイテンシーが発生するのか」を突き詰めていくと、必ずこうしたプロトコルの基本原理に行き着きます。パケットのバイナリの向こう側にあるアルゴリズムの息吹を感じながら、ぜひ明日のインフラ設計やAPI開発に活かしてみてください。
それでは、また次回のネットワーク深掘り記事でお会いしましょう！
コメント