HTTP/2の「記憶術」！HPACK動的テーブルで通信を爆速にする仕組みを解剖する
こんにちは！ネットワークの世界へようこそ。
Webブラウザでページを開くとき、実は裏側では膨大な数の「おしゃべり」がパケットという単位で行われています。
HTTP/1.1の時代は、毎回毎回「私の名前は〇〇、OSは××、言語は△△……」と、同じ自己紹介を律儀に繰り返していました。でも、これってすごく非効率ですよね。そこで登場したのがHTTP/2の秘密兵器、HPACK（ヘッダー圧縮）です。
今回は、その中でも特に賢い「動的テーブル（Dynamic Table）」という仕組みを、郵便配達に例えて紐解いていきましょう！
—
1. 毎回同じことを書くのは「無駄」！
例えば、あなたが遠く離れた友達に毎日手紙を送るとします。そのたびに封筒に自分の住所や名前をフルネームで書くのは面倒ですよね？
HTTPの世界でも同じです。`User-Agent`（使っているブラウザの情報）や`Cookie`（認証情報）などのヘッダーは、一度送ったら次は変わらないことがほとんどです。
そこでHPACKは考えました。
「一度教えた情報は、お互いの頭の中にメモしておいて、次は『さっきのあれ！』って呼べばいいんじゃない？」
これが「動的テーブル」の正体です。
—
2. 郵便局の「共通ノート」作戦
この動的テーブルは、ブラウザ（送信側）とサーバー（受信側）の両方が持っている「共通のノート」のようなものです。
1. 初回： ブラウザが「`User-Agent: Mozilla/5.0…`」という長い情報を送る。
2. 記憶： サーバーは「よし、これを『1番』としてノートに書いておこう」と記録。
3. 次回： ブラウザは「`1`」とだけ送れば、サーバーはノートの1番を見て「ああ、Mozillaだね！」と理解する。
これだけで、何百バイトもあるヘッダーが、たった数バイトの数字に圧縮されるんです。これがHTTP/2が高速である大きな理由の一つです。
—
3. ノートが一杯になったらどうする？（LRUアルゴリズム）
ここで一つ問題が発生します。ノートのページ数は無限ではありません。通信が長引くと、すぐにノートはパンパンになってしまいますよね。
ここで登場するのがLRU（Least Recently Used）アルゴリズムというルールです。
これは「最近使われていない古い情報から、消しゴムで消していく」という、非常に効率的な断捨離ルールです。
- 「昨日使ったばかりの情報」は重要だから残す。
- 「先週から一度も参照されていない情報」は、新しい情報を書くために消す。
この仕組みがあるおかげで、通信相手が変わっても、常に「今まさに必要な情報」だけがテーブルに並ぶようになっているのです。
—
4. 実践：設定値とエンジニアの視点
インフラエンジニアとしてこの仕組みを意識する場合、サーバー設定などで「テーブルのサイズ」を調整することがあります。
例えば、NginxなどのWebサーバーでは以下のような設定でこの「ノートの大きさ」を決めます。
HTTP/2のHPACK動的テーブルのサイズ設定
メモリに余裕があれば大きくすると圧縮効率が上がります
http2_max_field_size 4k; # 一つのヘッダーの最大サイズ
http2_chunk_size 8k; # 一度に処理するデータの塊
もし、この値を極端に小さく設定するとどうなるでしょう？
ノートが小さすぎてすぐに情報が消えてしまい、せっかくの圧縮機能が活かせず、結果として通信速度が低下してしまいます。逆に大きくしすぎると、サーバーのメモリを圧迫してしまいます。
現場の知恵：
一般的なWebサイトであればデフォルト値で問題ありませんが、ヘッダーに巨大なCookie（認証トークンなど）を詰め込むような特殊なアプリケーションの場合、この「テーブルサイズ」を調整することでパフォーマンスが改善することがあります。
—
まとめ：ネットワークは「思いやり」でできている
HTTP/2のHPACK動的テーブルは、単なるデータの圧縮技術ではありません。
「相手の手間を省くにはどうすればいいか？」という、通信プロトコル設計者たちの優しさと工夫が詰まった仕組みなんです。
- 動的テーブル： 通信中に学習して、情報を短縮する「共通ノート」。
- LRU： 古い情報を自動で入れ替える「賢い断捨離」。
次にブラウザでWebサイトを開くとき、裏側で「さっきのあれ！」というやり取りが行われているのを想像してみてください。ネットワークの世界が、少しだけ身近に感じられるはずですよ。
それでは、また次回の技術探訪でお会いしましょう！
コメント