【入門編】HTTP/2におけるヘッダー圧縮(HPACK)の動的テーブル管理 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。インフラやプロトコルの面白さに魅せられて日々パケットを追いかけている、技術ライターの私です。

Webブラウザを開いてページが表示されるまで、裏側では想像もつかない数のリクエストとレスポンスが飛び交っていますよね。その主役であるHTTPプロトコルは、Webの進化とともに「HTTP/1.1」から「HTTP/2」へと進化を遂げました。

HTTP/2の大きな目玉といえば、1本の通信路で複数のやり取りを同時にこなす「マルチプレクシング」ですが、もう一つの隠れたる功労者が 「HPACK（エイチパック）」 によるヘッダー圧縮技術です。

今回は、このHPACKの心臓部である「動的テーブル管理」と、メモリ消費量と圧縮率の切っても切れない関係について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！

—

1. なぜWebの「挨拶（ヘッダー）」はムダが多いのか？

私たちが普段何気なく見ているWebサイト。ブラウザがサーバーに「この画像ちょうだい」「あのページを見せて」とお願いするとき、必ずセットでついてくるのがHTTPヘッダーです。

このヘッダー、実はなかなかの「おしゃべり」です。例えば、以下のような情報が毎回の通信にもれなくついてきます。

ブラウザの種類やバージョン（User-Agent）
アクセス可能な言語（Accept-Language）
接続を維持する設定（Connection）

これらは、いわば手紙を出すときの「送り主のプロフィールや要望」のようなものですが、同じWebサイトを見ている間は、何十回送っても内容はほとんど変わりません。毎回、全く同じ長文のプロフィールを封筒に書いて送っているとしたら……なんだか紙とインクのムダですよね。ネットワークの世界でも同じで、この「毎回同じヘッダーを送る通信量」が、Web表示のスピードを落とす隠れた原因になっていました。

そこで登場したのが、HTTP/2のヘッダー圧縮「HPACK」です。

—

2. 郵便局の「お馴染みさん台帳」に例えるHPACKの仕組み

HPACKがやっていることは、とてもシンプルです。一言で言えば「よく使うフレーズは、お互いに共有した『番号』だけでやり取りしようぜ！」という仕組みです。

これを身近な「郵便配達」に例えてみましょう。

1. 静的テーブル（最初から決まっている略語辞書）

「1番：`method: GET`」「2番：`path: /`」のように、世界中のWebの共通ルールとして、最初から決まっている定番の略語リストです。

2. 動的テーブル（通信の途中で作られる「お馴染みさん台帳」）

ここからが今回の本題です！通信が始まってから、ブラウザとサーバーが「今回のやり取りで、さっきこんな長いヘッダーが出てきたから、次回からはこれを『番号62番』として覚えることにしよう！」と、その場しのぎで作り上げる専用のメモ帳のことです。

例えば、最初に `user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)…` というめちゃくちゃ長い文字列を送ったとします。
サーバーとブラウザは、「よし、この長い文字列を、今回のセッションの『動的テーブルの62番』として登録しよう！」と裏側でこっそり記憶します。

すると、2回目以降のリクエストからは、あの長い文字列を送る代わりに「62番！」とだけ叫べば、サーバー側は「あぁ、あのいつものブラウザね」と一瞬で理解してくれるわけです。すごい省エネですよね！

—

3. 動的テーブルの大きさを決める「SETTINGS_HEADER_TABLE_SIZE」

さて、この便利な「お馴染みさん台帳（動的テーブル）」ですが、無限に大きくできるわけではありません。なぜなら、覚えるための「記憶容量（メモリ）」には限界があるからです。

ここで登場するのが、HTTP/2の接続開始時に必ず交わされる設定値、`SETTINGS_HEADER_TABLE_SIZE`（セッティングス・ヘッダー・テーブル・サイズ）というパラメーターです。

このパラメーターは、「我がサーバー（またはブラウザ）の動的テーブルは、最大で〇〇バイトまで記憶していいですよ」という上限値を相手に伝えるためのものです。

メモリ消費量と圧縮率のトレードオフ（ジレンマ）

ここで、インフラエンジニアの腕の見せ所というか、頭を悩ませるポイントが出てきます。

テーブルサイズを大きくした場合（例：65,536バイト＝64KBなど）
メリット: たくさんの長いヘッダーを記憶できるため、圧縮率が跳ね上がり、ネットワークを流れるデータ量が減って通信が高速になります！
デメリット: サーバーやブラウザが、接続（ストリーム）ごとに「お馴染みさん台帳」を維持するためのメモリ消費量が増加します。アクセスが何万件も来ると、メモリが圧迫されてサーバーが悲鳴を上げる原因になります。

テーブルサイズを小さした場合（例：0バイト、あるいは小さめの値）
メリット: メモリの消費を最小限に抑えられます。リソースがカツカツなIoTデバイスや小規模なサーバーには優しく安全です。
デメリット: すぐに台帳がいっぱいになって古い記憶が消えてしまう（追い出される）ため、同じヘッダーを何度も送り直すことになり、圧縮率が下がって通信効率が悪化します。

まさに、「記憶力を上げるために脳のメモリーをたくさん使うか、物忘れしやすくなってメモ用紙を節約するか」のトレードオフですね。

—

4. 実務での設定例とデバッグの視点

では、実際の現場ではどのようにこの設定と付き合っているのでしょうか。
例えば、NginxやNode.js、Go言語などでHTTP/2サーバーを構築する際、この動的テーブルの上限サイズをチューニングすることがあります。

以下は、イメージしやすいように設定値の概念をコード風に表現したものです（※実際のミドルウェアの設定ファイルやコードにそのまま貼り付けるものではありませんが、考え方は共通です）。

// HTTP/2 サーバーの設定例（概念モデル）
const http2ServerOptions = {
// 動的テーブルの最大サイズを 4096バイト（4KB）に指定
// デフォルト値は通常 4096バイトですが、環境やメモリ事情に合わせて調整します
settings: {
headerTableSize: 4096,

// その他の参考設定
maxConcurrentStreams: 100, // 同時ストリーム数の上限
initialWindowSize: 65535 // フロー制御のウィンドウサイズ
}
};

【インフラエンジニアの現場メモ】
大規模なAPIサーバーなどで「メモリ使用量がやけに多いな？」と感じたときは、
この headerTableSize が無駄に大きく設定されていないか疑うことがあります。
逆に、モバイル向けの配信基盤などでは、端末側のメモリ事情やバッテリー消費を
考慮して適切なサイズに制限することがパフォーマンス向上につながります。

トラブルシューティングの現場から

ネットワークのパケットキャプチャツール（Wiresharkなど）や、ブラウザの開発者ツール（Networkタブ）を眺めていると、時々次のような疑問に出会うことがあります。

> 「あれ？さっきまで綺麗に圧縮されていたはずのヘッダーが、急に生データ（非圧縮）で流れているぞ？」

これは、動的テーブルのサイズ制限に達したことで古いデータが上書きされて消えてしまったり、サーバー側から `SETTINGS_HEADER_TABLE_SIZE` の変更通知（更新）が飛んできて、テーブルが一度リセットされたりしたときによく起こる現象です。

HPACKは、送信側と受信側で「まったく同じテーブルの中身」を完全に同期していなければ、文字化けならぬ「ヘッダー解読ミス」を起こしてしまいます。そのため、テーブルの管理は非常に厳密に行われており、この同期の仕組みこそがHTTP/2の安定性を支えているスパイスなのです。

—

5. まとめ：バランス感覚が光るHPACKの世界

今回は、HTTP/2のヘッダー圧縮（HPACK）における「動的テーブル管理」について紐解いてみました。

HPACK は、お互いの「お馴染みさん台帳（動的テーブル）」を使って、ムダなヘッダーの繰り返し送信を防ぐ技術。
`SETTINGS_HEADER_TABLE_SIZE` は、その台帳の大きさを決める重要なパラメーター。
メモリ消費量（コスト） と 圧縮率（スピード） はトレードオフの関係にあり、システムの規模や目的に合わせたバランス調整が大切。

普段何気なく使っているWebブラウザの裏側では、こうした「記憶と節約のバランス」が絶妙なチームワークで行われているのを知ると、なんだかパケットたちが愛おしくなってきますよね。

それでは、また次回のネットワーク探訪でお会いしましょう！一歩ずつ、確実に知識を広げていきましょうね。