HTTP/2 HPACKとハフマン符号化の深層：パケットを極限まで削ぎ落とすプロトコルの美学
インフラエンジニアとして幾多のパケットキャプチャを眺めてきた人間なら誰しも、HTTP/1.1のあの無慈悲なテキストベースのヘッダー重複に歯痒さを覚えたことがあるはずだ。数キロバイトのHTMLを取得するためだけに、数バイトのペイロードの背後に何百バイトもの `User-Agent` や `Cookie`、`Accept-Encoding` が毎度平文で載せて送出される。TCPの初期混雑ウィンドウ（initial congestion window）の制約が厳しい環境において、この「無駄な文字の羅列」は明らかに悪質な帯域の無駄遣いだった。
HTTP/2はこの課題に対し、バイナリフレーミング層の導入と、HTTP/2専用のヘッダー圧縮機構である HPACK（RFC 7541） をぶつけてきた。HPACKは、動的・静的な「インデックス表」を用いて既出のヘッダーをポインタに置き換えるだけでなく、そのポインタすらも指し示せない生データの文字列に対して ハフマン符号化（Huffman Coding） を適用し、ビット単位で限界までパケットサイズを圧縮する。
今回は、このHPACKのハフマン符号化がパケット上でどのように爆発的な効率化をもたらしているのか、その内部アルゴリズムと、プロトコル設計の裏に隠されたエンジニアリングの美学を解き明かしていく。
—
1. 静的ハフマン符号表のメカニズム：なぜ「出現頻度」がすべてなのか
ハフマン符号化の原理はシンプルだ。「出現頻度の高い文字には短いビット列を割り当て、出現頻度の低い文字には長いビット列を割り当てる」。これにより、テキストデータの総ビット数を統計的に最小化する。
HTTP/1.1やHTTP/2でやり取りされるヘッダー名や値（`content-type`, `authorization`, `gzip` など）を世界中のトラフィックから統計的に分析し、RFC 7541のAppendix Bには、256文字の拡張ASCIIセット（0〜255）および終端シンボル（256）に対する固定のハフマン符号表が定義されている。
この符号表が「静的（Static）」である点が非常に重要だ。クライアントとサーバーは、通信のたびに動的な符号表をネゴシエートする必要がない。あらかじめハードコードされた共通の辞書を持っているため、エンコード側もデコード側も、同じビットパターンを即座に復元できる。
パケット内におけるビット演算の現実
ワイヤ上のパケットを `tcpdump` や Wireshark で覗くと、ヘッダーブロック（`HEADERS` フレーム）の中身は次のようなバイナリ列として流れる。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| String Length (7+) | Huffman-encoded Data… ⚙
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ここで先頭の `H` ビットが `1` であれば、それに続く文字列がハフマン符号化されていることを示す。
例えば、文字 `’a’`（ASCII: 0x61）は比較的出現頻度が高いため、符号表では短いビット列に変換される。逆に、制御文字や滅多に使わない記号は長いビット列に変換される。
重要なのは、ハフマン符号化されたデータは 必ずしもバイト境界（8ビットの倍数）で綺麗に終わらない という点だ。そのため、パケットの末尾には「パディング（Padding）」として、終端シンボル（コード 256、すなわち 30ビットの `1` の連続）の余剰分がパディングビット（すべて `1`）として埋め込まれる仕様になっている。デコーダーはこのパディングを適切に切り捨てる実装が要求される。
—
2. 実装の罠：Huffman Decoding木構造の走査とパフォーマンス
プロトコル仕様を理解するだけならRFCを読むだけで十分だが、実際に高スループットなプロキシ（Nginx, Envoy, あるいはCloudflareの自社製プロキシなど）のコードを書く立場になると、ハフマン符号の「デコード処理」がCPUキャッシュと分岐予測に対してどれほどの負荷をかけるか痛感することになる。
単純な実装では、ハフマン符号のビット列を1ビットずつ読み込み、二分木（Binary Tree）を根から葉（Leaf）まで辿っていく。
// 概念的なハフマン復号木のノード構造
typedef struct huffman_node {
uint8_t symbol; // デコードされる実際の文字（葉ノードの場合有効）
uint8_t flags; // 内部ノードか葉ノードかのフラグ
struct huffman_node left; // 0の枝
struct huffman_node right; // 1の枝
} huffman_node_t;
しかし、このビット単位のツリーウォーク（Tree Walking）は、モダンなCPUのパイプライン処理にとって最悪の毒薬だ。データ依存の分岐（Data-dependent branch）が連続するため、CPUの分岐予測が盛大に外し、L1/L2キャッシュミスを引き起こす。数万リクエスト/秒を捌くエッジプロキシにおいて、この非効率なデコード実装は瞬く間にCPU使用率を天井知らずに引き上げる。
高速化のためのルックアップテーブル（LUT）戦略
実用的なプロダクトの多くは、純粋なビット単位のツリーウォークを行わず、ルックアップテーブル（LUT: Lookup Table）方式を採用している。
例えば、一度に8ビット（あるいはそれ以上）のウィンドウを切り出し、あらかじめ展開された巨大なジャンプテーブルを参照することで、一撃で数文字分のデコードを完了させる。メモリ消費量と引き換えにCPUサイクルを劇的に削減する、インフラエンジニアリングの王道的なトレードオフだ。
—
3. 圧縮のトレードオフ：CPUコスト vs 帯域削減、そして「HPACK爆弾」の脅威
「圧縮すればするほど正義」というわけではない。ここにプロトコル設計の深遠な闇と、セキュリティ専門家が身構えるべきポイントがある。
1. 小さなヘッダーに対する逆効果
ハフマン符号化は、文字数が非常に少ない文字列（例えば1〜2文字のヘッダー値）に対して適用すると、逆にデータサイズが膨らむことがある。ハフマン符号のオーバーヘッドやパディングの存在により、生データ（Plain ASCII）のまま送った方が小さかった、というケースが稀によくある。HPACKのエンコーダーは、このコストを動的に計算し、「ハフマン符号化した方がサイズが小さくなる場合のみ」 `H=1` フラグを立ててエンコードする賢さを持っている。
2. 空前の脅威「HPACK Bomb（CVE-2019-9512 等）」
セキュリティの観点において、HPACKの動的テーブルとハフマン符号化の組み合わせは、DDoS攻撃の格好の標的になり得る。これが世に言う 「HPACKヘッダー圧縮爆弾（HPACK Bomb）」 だ。
攻撃者は、極限までハフマン符号化された極小サイズのバイナリ（例えば数十バイト）をサーバーに送りつける。サーバー側のデコーダーがこれを展開すると、数メガバイト、あるいはそれ以上の巨大なヘッダー文字列に膨れ上がる。
サーバーはこの巨大なヘッダーをメモリ上の動的テーブル（Dynamic Table）にバッファしようとし、瞬く間にメモリを枯渇させる（Out of Memory: OOM）。これがHTTP/2実装の脆弱性として猛威を振るった。
対策：リミットの厳格な管理
現代の堅牢なHTTP/2実装（Linuxカーネルのネットワークスタックや、最新のGo言語 `net/http`、NGINXなど）では、以下のような防衛策がデフォルトで組み込まれている。
- `SETTINGS_MAX_HEADER_LIST_SIZE` の厳格な制限: デコード後のヘッダー全体のサイズに上限（通常は数KB〜数十KB）を設け、これを超えた瞬間に `RST_STREAM`（エラーコード: `ENHANCE_YOUR_CALM` または `DATA_OVERFLOW`）を返す。
- 動的テーブルサイズの動的制限: `SETTINGS_HEADER_TABLE_SIZE` を適切に小さく保ち、際限ないメモリ割り当てを防ぐ。
—
4. トランスポート層（TCP/TLS）の最適化とRTT削減の相乗効果
HPACKとハフマン符号化がもたらす恩恵は、単に「転送容量が減る」というケチ臭い話ではない。トランスポート層の振る舞いそのものを劇的に変える。
初期ウィンドウ（Initial Congestion Window: iw10/iw44）への適合
現代のLinuxカーネル（TCPパケットのデフォルト挙動）では、初期混雑ウィンドウとして10セグメント（あるいはそれ以上、TCP BBRや最新のカーネルではさらに大規模）が最初から一気に送信される。
HTTP/1.1の時代、リクエストヘッダーがこの初期ウィンドウのサイズ（約14.6KB）を超過すると、クライアントはサーバーからのTCP ACK（ラウンドトリップ）を待たざるを得なくなり、致命的なRTT（Round Trip Time）の遅延が発生していた。
HPACKとハフマン符号化によってヘッダーサイズが数分の一に圧縮されると、「リクエスト全体の塊が、最初のTCPウィンドウ（あるいはTLSレコードの1フラグメント）の内部に綺麗に収まる」確率が跳ね上がる。
結果として、TCPの遅延確認応答（Delayed ACK）やスロースタートの罠を華麗に回避し、「1往復目（0-RTT / 1-RTT）の通信フェーズでアプリケーション層の処理が完了する」という、極限の低レイテンシを実現できるのだ。
—
5. 実務における検証：Go言語によるHPACK内部挙動の覗き見
理屈はここまでにして、実際にGo言語の標準ライブラリ（`golang.org/x/net/http2/hpack`）を用いて、HPACKのエンコード・デコードがどのように行われているのかをコードベースで確認してみよう。以下のスニペットは、実務のデバッグやプロキシ開発ですぐに流用できる実践的なサンプルだ。
package main
import (
“bytes”
“fmt”
“log”
“golang.org/x/net/http2/hpack”
)
func main() {
// HPACKのバッファとエンコーダーを初期化
var buf bytes.Buffer
enc := hpack.NewEncoder(&buf)
// テスト用のHTTP/2ヘッダー群
// リアルなWebトラフィックを想定したお馴染みのキーと値
headers := []hpack.HeaderField{
{Name: “:method”, Value: “GET”},
{Name: “:path”, Value: “/api/v1/telemetry/metrics”},
{Name: “:authority”, Value: “internal.infra.example.com”},
{Name: “user-agent”, Value: “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36”},
{Name: “accept-encoding”, Value: “gzip, deflate, br”},
}
fmt.Println(“=== [ENCODE PHASE] バイナリへの圧縮・ハフマン符号化 ===”)
for _, h := range headers {
// ヘッダーをエンコード（静的・動的テーブルおよびハフマン符号化が自動適用される）
err := enc.WriteField(h)
if err != nil {
log.Fatalf(“エンコード失敗: %v”, err)
}
fmt.Printf(“Key: %-18s | Value: %-40s\n”, h.Name, h.Value)
}
// 圧縮されたバイナ-リデータの長さを確認
encodedBytes := buf.Bytes()
fmt.Printf(“\n[結果] 圧縮後の生バイナリサイズ: %d バイト\n”, len(encodedBytes))
fmt.Printf(“Hex Dump: %x\n\n”, encodedBytes)
fmt.Println(“=== [DECODE PHASE] バイナリからの復元 ===”)
// デコーダーの初期化（最大4096バイトの動的テーブルサイズを指定）
dec := hpack.NewDecoder(4096, func(f hpack.HeaderField) {
// デコードされたフィールドが1つ完了するたびにコールバックが呼ばれる
fmt.Printf(“Decoded -> Key: %-18s | Value: %s\n”, f.Name, f.Value)
})
// エンコードされたバイナリをデコーダーに流し込む
_, err := dec.Write(encodedBytes)
if err != nil {
log.Fatalf(“デコード失敗: %v”, err)
}
}
このコードを実行すると、冗長な文字列の群れが、わずか数十バイトの洗練されたバイナリフレーミングに凝縮され、完璧に元の構造へと復元される様を目の当たりにできる。プロキシサーバーをスクラッチで実装する際や、通信パケットのディープな解析（Wiresharkのパケット解析結果の突き合わせ）を行う際、この挙動を頭に叩き込んでおくことで、トラブルシューティングのスピードは桁違いに向上する。
—
結び：プロトコルの美しさは「細部」に宿る
HTTP/2のHPACK、そしてその核心をなすハフマン符号化は、単なる「データサイズの削減テクニック」ではない。限られたネットワーク帯域、ミリ秒単位の遅延、そしてCPUキャッシュやメモリ枯渇といったハードウェア制約の狭間で、いかに美しく、かつ強靭にデータを運ぶかという、ネットワークアーキテクトたちの執念の結晶である。
パケットがNICを叩き、カーネルのバッファを抜け、TLSの暗号化の闇を潜り抜け、ハフマンツリーのビット演算を経てアプリケーション層に到達する――その一連の流れを脳内で正確にトレースできるようになったとき、インフラエンジニアとしての視界は、今までよりも確実に一段高いステージへと引き上げられているはずだ。
コメント