HTTP/2 HPACKの奥義：ハフマン符号化がもたらす「1バイトの美学」と極限のパケット最適化
ウェブの高速化において、私たちは长らくHTTP/1.xの「テキストベースの冗長性」という呪縛に苦しんできた。毎リクエストごとに送信される数キロバイトのCookie、User-Agent、Acceptヘッダー。これらはTLSハンドシェイクが完了し、TCPのスロースタートという物理的制約をようやく抜け出した初期の輻輳ウィンドウ（Cwnd）の貴重な領域を、無慈悲に侵食し続けてきた。
HTTP/2はこのボトルネックを打破するため、バイナリフレーミング層を導入し、さらにヘッダー領域の圧縮機構としてHPACK（RFC 7541）を実装した。HPACKの心臓部には、静的・動的テーブルによるインデキシングと、文字単位の頻度ベースの圧縮であるハフマン符号化（Huffman Coding）が存在する。
今回は、このHPACKにおけるハフマン符号化のパケットレベルでの挙動に焦点を当て、単なる「データ量の削減」にとどまらない、TCPバッファ、TLSハンドシェイク、そしてHTTP/2特有の脆弱性（Rapid Reset等につながるコンテキスト管理）との深い相関関係を、インフラアーキテクトの視点から紐解いていこう。
—
1. なぜHPACKに「ハフマン符号化」が必要なのか？
HPACKの基本思想はシンプルだ。「既知のヘッダーはインデックス番号に置き換え、未知のヘッダーや動的値はそのまま送る」。しかし、世の中のすべてのCookieの値やカスタムヘッダーをあらかじめ静的テーブルに登録しておくことは不可能である。ここで「動的値の文字列自体をどうやって削るか」という問題に直面する。
ここで登場するのが、RFC 7541の付録Bに定義された静的ハフマン符号表である。
文字の出現頻度に応じた可変長コードを割り当てるハフマン符号の原則に基づき、HPACKでは英語のアルファベット、数字、記号の出現確率を統計的に分析し、頻出する文字（例: `e`, `t`, `a` や小文字のアルファベット、スラッシュ、ピリオドなど）には短いビット列を、出現頻度の低い文字には長いビット列を割り当てている。
静的ハフマン符号の構造的特徴
- バイト境界の不一致: ハフマン符号化されたデータは、必ずしも8ビット（1バイト）の境界で区切られるとは限らない。連続した文字のビット長が不規則であるため、パケット上のバイナリ表現ではビット単位のシフト演算が必要になる。
- パディングのルール: 符号化データの末尾がバイト境界に満たない場合、パディングとして「1」のビット列が埋め込まれる。受信側は、パディングに含まれる「1」の連続をデコード時に無視する仕様になっている（ただし、末尾のパディングが規定の最大長を超える、あるいはすべて「0」であるなどの不正なパディングは、HPACKデコーダーのエラー＝接続断（RST_STREAM / PROTOCOL_ERROR）を引き起こす）。
—
2. パケットレベルの挙動：文字列がバイナリに変換される瞬間
実際に、HTTP/2のヘッダー値がどのようにハフマン符号化され、ワイヤー上で流れるのかを追ってみよう。
例えば、ヘッダー値としてよく使われる文字列 `custom-key: value` のうち、値部分の `value` という文字列をハフマン符号化することを考える。
RFC 7541の静的符号表によると、各文字のハフマンコードは以下のようになる（※実際のビット長とコードは仕様書に基づく）。
- `v`: 5ビット
- `a`: 5ビット
- `l`: 5ビット
- `u`: 5ビット
- `e`: 5ビット
これらが連結され、さらにHPACKのLiteral Header Field表現（インデックスなし、値のみハフマン符号化）を示すプレフィックス（通常は1バイト目の上位ビット `0F` などの制御ビット）と共に、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Header Index / Literal Flag| Length (Huff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Huffman Encoded Data… |
+—————————————————————+
このバイナリ圧縮により、平文であれば5バイト（40ビット）消費していた文字列が、最適化されたビット列によって大幅に圧縮され、初期輻輳ウィンドウ（Cwnd = 10 などのパケットサイズ）の制約下において、複数のリクエストヘッダーを1つのTCPセグメントに高密度にパッキングすることが可能になる。
—
3. トランスポート層（TCP）とTLSハンドシェイクへの相乗効果
HPACKのハフマン符号化がもたらすメリットは、単に「転送容量が減る」というレイアプリケーション層の話だけではない。トランスポート層、ひいてはTLS層の挙動に直接的な好影響を与える。
1. TCPスロースタートの呪縛からの解放
新しいTCPコネクションが確立された直後、輻輳ウィンドウ（Cwnd）は小さく制限されている（初期ウィンドウサイズは通常10セグメント＝約14.6KB程度）。
もし複数のAPIリクエストを同時に発行するSPA（Single Page Application）やマイクロサービス間通信において、HTTPヘッダーの総量がこの初期Cwndを超過すると、TCPの追加のラウンドトリップ（RTT）が発生し、レイテンシが跳ね上がる。
ハフマン符号化によってヘッダーサイズを20%〜30%削減できることは、まさに「初期Cwndの枠内にすべてのリクエストヘッダーを収め切り、追加のRTTを発生させない」ための決定的な防衛線となる。
2. TLSレコード分割攻撃（BEAST / CRIME）への耐性とコンテキスト保護
TLS層における暗号化（TLS 1.2以前のCBCモード等）では、平文の長さがパディングによって推測されるサイドチャネル攻撃の危険性があった。HTTP/2のHPACKは、すべてのヘッダーを単一のバイナリコンテキスト（HPACK動的テーブル）でシリアライズするため、TLSレイヤーでのパディング挙動と相まって、上位プロトコル特有の既知平文攻撃（CRIME攻撃のHTTP/2版など）に対する防御機構としても機能する。
—
4. セキュリティの急所：ハフマンデコード処理におけるDoS脆弱性
インフラアーキテクトやセキュリティ専門家として最も警戒しなければならないのは、「ハフマンデコード処理に起因するリソース枯渇（CPU Exhaustion / DoS）」である。
ハフマン符号は木構造（Prefix Tree）を用いてデコードされる。悪意あるクライアントが、以下のような細工をしたHPACKヘッダーブロックを送りつけてきたらどうなるだろうか？
1. 極端に長いハフマン符号の羅列: デコード後の文字列長に対して、ワイヤー上の圧縮データが極端に膨れ上がり、CPUがデコード木を辿るループ処理に長時間拘束される（Zip BombのHTTP/2版）。
2. 不正なパディング: パディング部分に「0」が予期せぬ形で含まれている、あるいはパディングが規定のバイト境界を超えている場合、デコーダーのステートマシンが異常終了したり、例外処理でCPUサイクルを消費したりする。
NginxやEnvoy等のプロキシにおける制限値チューニング
モダンなリバースプロキシやAPIゲートウェイでは、このリスクを回避するためにHPACKのデコード制限を厳格に設けている。例えば、Envoy Proxyの設定では以下のようなパラメータで防御を行う。
Envoy ProxyにおけるHTTP/2およびHPACKの耐障害・セキュリティチューニング例
static_resources:
listeners:
- name: ingress_http2
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
codec_type: HTTP2
http2_protocol_options:
# 動的テーブルの最大サイズを制限し、メモリ枯渇を防ぐ
max_dynamic_table_size: 4096
# 受信可能なヘッダーの最大長を制限（ハフマンデコード時のCPUスパイクを防ぐ）
max_header_size: 16384
# 同時ストリーム数を制限し、リソースの濫用を防止
max_concurrent_streams: 100
特に `max_dynamic_table_size` やデコードされる非圧縮ヘッダーの最大長（`max_header_size`）を適切に制限しないままデフォルト運用することは、Slowloris攻撃の進化系であるHTTP/2 Rapid Reset（CVE-2023-44487）と並び、インフラストラクチャに対する致命的な脆弱性を残す原因となる。
—
5. Linuxカーネルとソケットバッファの最適化（実務での勘所）
最後に、HPACKで圧縮されたデータがLinuxカーネルのネットワークスタックをどのように通過し、アプリケーションに渡されるのか、そのチューニング指針に触れておこう。
HTTP/2通信では、1つのTCPコネクション上で多重化（Multiplexing）が行われるため、単一のソケットバッファに多様なストリームのフレームが混在する。
1. TCPバッファ（rmem / wmem）のサイジング
HPACKによってヘッダーサイズが小さくなるとはいえ、高トラフィックな環境ではカーネルのソケットバッファがボトルネックになる。
/etc/sysctl.conf におけるネットワークバッファの極限チューニング例
高スループットなHTTP/2プロキシサーバー向け
TCP受信バッファの最小、デフォルト、最大値（バイト単位）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
輻輳制御アルゴリズムに BBR を採用し、RTTと帯域の限界を引き出す
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
ハフマン符号化によってパケットあたりの情報密度が上がっているため、BBRのような帯域と遅延ベースの輻輳制御と組み合わせることで、パケットロスに対する耐性とスループットの最大化を同時に達成できる。パケットロス発生時に冗長なヘッダーデータで帯域を無駄に消費しないというハフマン符号化の特性は、BBRの帯域推定精度向上に対しても間接的に寄与しているのだ。
—
結びにかえて
HPACKのハフマン符号化は、単なる「データ圧縮のアルゴリズム」ではない。
それは、トランスポート層の物理的制約（TCPスロースタート、RTT）を突破し、暗号化通信の安全性を担保しつつ、プロキシサーバーのCPUとメモリリソースの境界線上でギリギリの攻防を繰り広げる、極めて洗練されたネットワークの芸術である。
インフラエンジニアやテックリードが日頃構築・運用するKubernetesのIngress Controller、API Gateway、そしてサービスメッシュの背後では、まさにこの「1バイトの美学」がミリ秒単位のレイテンシ削減を生み出している。この仕組みの深部を理解し、適切なパラメータチューニングとセキュリティ対策を施すことこそが、真に堅牢で高速な次世代ネットワークインフラを築く唯一の道なのである。
コメント