こんにちは！ネットワークの世界へようこそ。インフラエンジニアの主筆ライターとして、日々インターネットの裏側を覗いている私ですが、今回はWebブラウザとサーバーの会話を劇的に変えた「HTTP/3」の裏側、そしてその中でもいぶし銀の働きをする「QPACK（キューパック）」という技術についてお話ししていきます。
「HTTP/2でヘッダーが圧縮できるようになったって聞いたけど、HTTP/3では何が違うの？」
「なんか難しそうな名前が出てきたけれど、私の仕事に関係あるの？」
そんな疑問を持っている方、ご安心ください。難しい英語の仕様書や複雑なビット計算はひとまず置いておいて、まずは身近な「郵便配達」のたとえから一歩ずつ、優しく紐解いていきましょう！
—
1. HTTP/2の「HPACK」が抱えていた、意外なジレンマ
HTTP/2の大きな功績の一つに、「ヘッダー圧縮（HPACK）」があります。
Webブラウザがサーバーにリクエストを送るとき、「私、こういうブラウザで、こういう言語を話せて、クッキーはこれ持ってて……」というお決まりの挨拶（HTTPヘッダー）を毎回たくさん送っていますよね。HPACKは、このお決まりの挨拶を辞書（テーブル）を使って「2番のフレーズね」と、ほんの数バイトに縮めてしまう天才的な仕組みです。
ここで、現実世界の郵便配達を想像してみてください。
あなたは毎日、同じ宛先に「お疲れ様です。いつもお世話になっております。〇〇会社の〜〜です。」という決まり文句の書かれた手紙を何通も送っています。
HTTP/2の世界では、これらを「順番通りにきちん届くトラック」に積んで送っていました。
- 「1通目の手紙で、新しい挨拶の登録番号を教えます」
- 「2番目の手紙で、その登録番号を使った別の手紙を送ります」
トラックが順番通りに走るなら、郵便受けに届くのも当然「1通目 → 2番目」の順番です。だから、サーバー側も「なるほど、1通目で覚えた登録番号ね！」とスムーズに理解できました。
しかし、ここでHTTP/3のベースである「QUIC（キック）」という新しい交通網が登場します。QUICは、車線（UDP）を何本も使って、荷物をバラバラの順番で届ける「非順序配信」の達人です。
もし、郵便配達のトラックが渋滞や別のルートを通って、「2番目の手紙（登録番号を使う手紙）」が「1通目の手紙（登録番号を教える手紙）」よりも先に届いてしまったら、どうなるでしょうか？
サーバー「えっ！？ まだ登録番号を教えてもらってないのに、‘2番のあれ’って言われても、何のことだかさっぱり分からないよ！！（パニック）」
これが、HTTP/2のHPACKをそのままHTTP/3で使おうとしたときに起きてしまう大問題、「ヘッド・オブ・ライン・ブロッキング（先頭ブロック問題）」の正体です。この問題を解決するために生まれたのが、今回主役の「QPACK」なのです。
—
2. QPACKはどうやってこの問題を解決するの？
一歩ずつ理解していきましょう！
QPACKがやったことは非常にシンプルで、かつ頭の良い工夫です。それは、「届く順番がバラバラになっても困らないように、通信の仕組みをちょっと変えた」ということです。
QPACKには、大きく分けて以下の2つの工夫が盛り込まれています。
1. 「静的テーブル（最初から決まっている辞書）」の活用を増やす
2. 「動的テーブル（後からやり取りして覚える辞書）」専用の別レーン（制御用ストリーム）を作る
動的テーブルの「ブロックメカニズム」という魔法
特に面白いのが、動的テーブル（会話の途中で新しく覚える略語）の管理方法です。
QPACKでは、まだ届いていない「辞書の登録おしらせ（参照）」より先にデータが届いてしまった場合、サーバーは慌てふためくのをやめました。代わりに、こう言います。
「おっ、まだおしらせの手紙が届いてないな？ じゃあ、その手紙が届くまで、この荷物はちょっと待合室（ブロック）で待機させておこう！」
そして、遅れていた「登録のおしらせ手紙」が無事に到着した瞬間、待合室で待っていた荷物が一斉に「よし、解禁だ！」と処理されます。
これにより、パケットがどんなにバラバラの順番で届いても、データの整合性が綺麗に保たれるようになったのです。
—
3. 開発者・インフラエンジニアの視点：僕たちは何を意識すればいい？
「なるほど、郵便の仕組みが変わったのは分かったけど、実際にアプリを作ったりインフラを構築したりする時、何か気にする必要はあるの？」
そう思ったあなたは素晴らしいエンジニアの勘をしています！
実は、Webサーバー（NginxやEnvoy、CloudflareなどのCDN）や、HTTP/3対応のクライアントライブラリを使う際、このQPACKが裏でうまく動くように「パラメータのチューニング」が必要になるシーンがあります。
例えば、Nginxなどの設定ファイルや、HTTP/3を実装するコードのイメージを覗いてみましょう。
【Nginxやリバースプロキシのチューニングイメージ】
QPACKが裏側でどれくらいの「待合室（バッファ）」を用意するかを決める設定例です
http {
# 動的テーブルの最大サイズ（サーバーがどれくらい過去のやり取りを覚えているか）
# 値を大きくしすぎるとメモリを消費し、小さすぎると圧縮率が下がります
http3_qpack_dynamic_table_size 4096;
# 順番が狂ったときに、待合室でどれくらい同時に待たせて良いかの制限（ストリーム数）
http3_qpack_blocked_streams 100;
}
実務でのプチトラブルと対策
インフラの現場でHTTP/3（QUIC/QPACK）を有効化した際、たまに以下のような現象に出会うことがあります。
- 「なんだか特定のリクエストだけレスポンスが妙に遅い気がする……」
- 「クライアントとサーバーの間で、QPACKのバッファサイズ（容量）の認識がズレてエラーになる」
大容量のファイルをやり取りしたり、複雑なAPIリクエストを大量に投げたりする環境では、このQPACKの「動的テーブルのサイズ」や「待合室のキャパシティ（Blocked Streams）」のデフォルト値が足らず、意図せずウェイト（待機）が発生してしまうことがあるのです。
もしパフォーマンスチューニングを行う際は、
- サーバー側のメモリと相談しながらテーブルサイズを適切に確保する
- クライアント・サーバー間のSETTINGSフレーム（初期化の握手）で交わされるQPACKパラメータの値をログやパケットキャプチャ（Wiresharkなど）で確認する
といったアプローチが、プロとしての腕の見どころになります！
—
まとめ
今回は、HTTP/3を支える陰の主役「QPACK」の仕組みについて、郵便配達の例えを交えながら解説しました。
- HPACKの弱点: 順番が狂うと、辞書の登録待ちでフリーズしてしまう。
- QPACKの解決策: 届く順番がバラバラなQUIC（HTTP/3）に合わせて、「待合室（ブロックメカニズム）」を作り、スマートに荷物を受け渡せるようにした。
ネットワークのプロトコルは、一見すると無機質なルールの積み重ねに見えますが、その背景には「どうすればより速く、確実データを届けられるか」という先人たちの知恵と工夫（まるで人間社会のロジスティクスそのもの！）が詰まっています。
今回の記事が、皆さんの日々の開発やインフラ運用のモヤモヤを晴らす小さなきっかけになれば嬉しいです。
それでは、また次回のテック解説でお会いしましょう！
コメント