【入門編】HTTP/3におけるQPACKヘッダー圧縮の仕組み – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの裏側を覗き見るのが大好きなエンジニアの皆さん。

今日は、現代のWeb通信の要である「HTTP/3」の、さらにその奥深くにある「QPACK（キューパック）」という技術についてお話しします。

「HTTP/3は速い」というのは聞いたことがあっても、なぜ速いのか？特に「ヘッダー圧縮」という地味だけど重要なプロセスで、一体何が起きているのかを理解している人は意外と少ないものです。

今日は、難しい専門用語は一旦置いておいて、身近な「郵便配達」に例えながら、一緒に紐解いていきましょう！

—

Webサイトを表示するとき、ブラウザはサーバーに対して「このページをちょうだい！」とリクエストを送ります。その際、送るデータは「中身（本文）」と「付箋（ヘッダー）」に分かれています。

この付箋には、「私はChromeを使っています」「日本語のページがいいです」「クッキーはこれです」といった細かい情報がびっしり書かれています。

実は、この付箋、毎回ほとんど同じ内容なんです。毎回同じことを書き直して送るのは、紙の無駄ですし、配達員（ネットワーク）も疲れてしまいますよね。そこで、「一度送った情報は、お互いの辞書に登録して、次回からは番号だけでやり取りしよう！」というのが「ヘッダー圧縮」の基本です。

—

HTTP/2では「HPACK」という仕組みが使われていました。これは非常に優秀でしたが、一つだけ「渋滞」の原因になる弱点がありました。

例えば、荷物が2つ（AとB）同時に届くとします。Aの付箋を解読するための辞書情報がもし遅れて届いてしまうと、Bの付箋も「Aの辞書情報が来るまで待機！」とストップしてしまうのです。

まるで、前の人が窓口でモタモタしているせいで、後ろの列全員が待たされる行列のような状況。これが、HTTP/2でたまに発生する「先頭のブロックによる停滞（Head-of-Line Blocking）」という問題です。

—

そこで登場したのが、HTTP/3で使われるQPACKです。

QPACKのすごいところは、「順番待ちをしなくてもいい」という点です。

郵便配達に例えると、こんな感じです。

QPACKは、辞書情報が揃っていない状態でも、ヘッダーを解釈できるように工夫されています。たとえパケットがバラバラの順番で届いても、各ストリーム（荷物の流れ）が独立して動けるようになったおかげで、通信が圧倒的にスムーズになったのです。

—

エンジニアとして実務に携わると、パケットキャプチャツールなどで通信を見る機会があるかもしれません。例えば、ブラウザからサーバーに送られるヘッダー情報は、内部ではこんなイメージで変換されています。

実際のパケット内では、こんな風にインデックス番号に変換されます
辞書（Dynamic Table）のイメージ

1. :method: GET -> 番号 2 に割り当て
2. :path: /index.html -> 番号 20 に割り当て
3. user-agent: Chrome/120 -> 番号 55 に割り当て

次回からはこの番号だけで通信します
送信されるデータ例：
[ 2, 20, 55 ]
たったこれだけの情報量で、元の長いヘッダーを復元できるのです！

もし皆さんがWebサーバーの設定（NginxのHTTP/3設定など）を行う場合、このテーブルサイズを調整することがあります。

Nginxの設定例
http {
# QPACKで使用する「動的テーブル」のサイズ設定
# 大きすぎるとメモリを食い、小さすぎると圧縮効率が落ちる
http3_qpack_table_size 4096;
}

この「4096」という数字は、辞書をどれくらい記憶しておくかのサイズです。「記憶が良ければ良いほど速くなるけど、脳みその容量（メモリ）には限界があるよね」というバランス調整を、私たちは現場で行っているわけですね。

—

QPACKは、単なるデータの圧縮技術ではありません。「通信相手を待たせない」「不完全な状態でも最善を尽くす」という、ネットワークエンジニアの「気配り」がアルゴリズムとして結晶化したものなのです。

こうして理解すると、ブラウザの読み込みボタンを押した後の0.1秒が、なんだかとても愛おしく感じられませんか？

これからも、パケットが駆け巡るこの素晴らしい世界の「仕組み」を、一緒に楽しく学んでいきましょう！質問があれば、いつでもコメント欄で待っています。