こんにちは！インフラの世界へようこそ。ネットワークスペシャリストの私です。
日頃からWebサイトを見たり、APIを叩いたりするときに何気なく使っている「HTTP」ですが、その裏側では、通信をより速く、より安全にするための技術革新が日夜行われています。前世代のHTTP/2では「HPACK（エイチパック）」という仕組みでヘッダーを圧縮していましたが、最新のHTTP/3では、それをさらに進化させた「QPACK（キューパック）」という技術が使われています。
「名前が似ていて、なんだか難しそう……」と思いましたか？ 大丈夫です！一歩ずつ、私たちの身近な例えを交えながら優しく紐解いていきましょう。
—
そもそも、なぜHTTPのヘッダーを圧縮するの？
Webサイトにアクセスするとき、ブラウザ（注文者）とサーバー（お店）の間でたくさんのメッセージが飛び交います。このメッセージの本体（データ）を送る前に、必ず「おまけ情報（HTTPヘッダー）」がくっついてきます。
- 「私はGoogle Chromeです」
- 「日本語のページが欲しいです」
- 「こんなクッキーを持っています」
これらは通信をする上でとても大切な情報なのですが、毎回の通信で毎回このおまけ情報をフルサイズで書いて送っていると、郵便配達のバッグがすぐにパンパンになってしまいますよね。
そこでHTTP/2では、「お決まりのフレーズは辞書を使って番号だけでやり取りしよう！」というHPACKという圧縮の仕組みが生まれました。例えば、「`user-agent: Mozilla/5.0…`」という長い文字列を、辞書の「番号：42」に置き換えて送るイメージです。これにより、通信が劇的に速くなりました。
—
HTTP/3の「QPACK」で、何が変わったの？
「じゃあ、HTTP/2のHPACKで十分じゃないか！」と思いますよね。しかし、HTTP/3の土台となっている新しい通信規格「QUIC（クイック）」の世界では、HPACKのままでは都合が悪い問題が発生してしまいました。
それを理解するために、ちょっとした郵便配達のたとえ話をしてみましょう。
郵便配達のたとえ話：HPACKの限界とQPACKの挑戦
想像してください。あなたは今、たくさんの手紙（HTTPリクエスト）を同時に送ろうとしています。
- HPACKのやり方（厳格な順番待ち）
辞書には「今、何番まで登録したか」という順番が厳密に決まっています。
あなたが手紙1、手紙2、手紙3を同時にポストへ投函しました。しかし、ネットワークの混雑で、手紙3が一番先にサーバーに届いてしまいました。
サーバーはこう言います。「あれ？まだ手紙1と手紙2が届いていないから、手紙3に書かれている『辞書の何番』の意味が分からないぞ！ 手紙1と手紙2が届くまで、処理をストップしよう……」
これが、ネットワークの世界でいう「ヘッド・オブ・ライン・ブロッキング（先頭ブロック問題）」です。せっかく手紙3が早く着いたのに、前の手紙を待たされて全体のスピードが落ちてしまうのです。
- QPACKのやり方（柔軟なチームワーク）
これじゃいかん！ということで登場したのがQPACKです。
QPACKは、手紙がバラバラの順番（順序不同）で届いても困らないように工夫されています。サーバー側に「あ、手紙3が先に届いたね。手紙1と手紙2がまだだけど、今回は特別にこの専用のメモ用紙（プレフィックス等）を見て意味を推測するよ！」という賢い救済ルールを持たせたのです。
これにより、QUICが持つ「パケットが多少前後して届いても大丈夫！」という素晴らしい強みを、ヘッダー圧縮の領域でも100%活かせるようになりました。
—
QPACKの動的テーブル管理を覗いてみよう
QPACKには、大きく分けて2つの「辞書（テーブル）」があります。
1. 静的テーブル（Static Table）
- 最初から世界共通で決まっている辞書です（「よく使われるお決まりのヘッダー名や値の組み合わせ」が何十個も登録されています）。これはもう書き換わりません。
2. 動的テーブル（Dynamic Table）
- 通信をしている最中に、そのサイト独自のカスタムヘッダーなどをその都度追加していく辞書です。
実際のやり取りのイメージ
例えば、あなたが何度も同じWebサーバーにリクエストを送るとします。
[クライアント] ──(カスタムヘッダー: X-My-App-Version: 1.2.3)──> [サーバー]
初回は長い文字列として送りますが、サーバーとクライアントの間で「この長い文字列は、これからは動的テーブルの『番号：68』として覚えようね！」というアイコンタクト（同期）を行います。
ここでポイントなのが、「相手がその番号を本当に覚えたか確信が持てなくても、見切り発車で番号を送ってもいい」というQPACKの優しさです。もしサーバー側でまだ辞書が更新しきっていなくて「番号68って何だっけ？」となった場合でも、QPACKの仕組みを使えば安全にリカバリーできるようになっています。
—
現場のエンジニアが知っておくべきポイントとデバッグのコツ
私たちが日常のインフラ構築やアプリケーション開発で、直接QPACKのソースコードをゴリゴリ書くことはほとんどありません。NginxやEnvoy、あるいはCloudflareなどのCDN、そしてGoやNode.jsなどのモダンなHTTP/3ライブラリが、内部でよしなに処理してくれます。
しかし、トラブルシューティングの現場ではこの知識がモノを言います。例えば、ブラウザの開発者ツール（ネットワークタブ）や、パケットキャプチャツール（Wiresharkなど）でHTTP/3の通信を覗き見したとき、次のような挙動に出会うことがあります。
WiresharkなどでHTTP/3（QUIC）のqpackストリームを解析する際のイメージ
Frame 4: 124 bytes on wire
QUIC Packet: STREAM Frame (Stream ID: 4)
QPACK Encoder Stream:
- Insert With Name Reference (Index: 22, Value length: 5)
- Value: “secret-token-xyz”
QPACK Decoder Stream:
- Section Acknowledgement (Inserts: 1)
もし、サーバーとクライアントの間でQPACKの動的テーブルの同期がうまくズレてしまうと、ブラウザ側でエラー（例：`HTTP_3_DECOMPRESSION_FAILED` のようなエラーコード）が発生し、ページが真っ白になったり読み込みが無限ループしたりします。
そんなときは、以下のポイントを確認してみてください。
1. プロキシやロードバランサーのバージョン確認
- HTTP/3やQPACKの仕様は非常に複雑なため、古いリバースプロキシを使っていると、動態テーブルの管理バグを踏むことがあります。ミドルウェアは常に最新の安定版にアップデートしましょう。
2. Qpack Settingsのチューニング
- HTTP/3の接続開始時（SETTINGSフレーム）には、お互いに「動的テーブルのサイズを最大いくつまで許容するか（`SETTINGS_QPACK_MAX_TABLE_CAPACITY`）」などを交渉します。もしメモリがカツカツな環境であれば、この動的テーブルサイズを小さめに設定してメモリリークを防ぐ配慮も実務では重要になります。
—
まとめ
いかがでしたでしょうか？
- HPACKは順序が命の「真面目な優等生」だったけれど、順番がバラバラになるQUICの世界では少し窮屈だった。
- QPACKは、手紙が前後して届いても賢く解釈できる「柔軟なチームプレイヤー」として生まれ変わり、HTTP/3の高速性を下支えしている。
ネットワークの世界は、一見すると難解なアルゴリズムの塊に見えますが、こうして「郵便配達の仕組み」に例えてみると、先人たちのエンジニアリングの美しさと泥臭い工夫が見えてきてワクワクしてきますよね。
今日の知識が、あなたのインフラ学習や日々の開発のちょっとしたスパイスになれば嬉しいです。それでは、また次回の技術解説でお会いしましょう！
コメント