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

HTTP/3の「QPACK」を攻略せよ！郵便配達に例えるヘッダー圧縮の魔法

こんにちは！インフラの世界へようこそ。今日は、インターネットを支える「HTTP/3」の心臓部の一つ、「QPACK（キュパック）」についてお話しします。

「HTTP/3？QUIC？何だか難しそう……」と思っているあなたも大丈夫。今日は、小難しいパケットのビット数なんて脇に置いて、「郵便配達」を想像しながら、この技術がなぜ画期的なのかを紐解いていきましょう。

—

まず、私たちがWebサイトを見るときのことを考えてみてください。ブラウザはサーバーに対して「この画像ちょうだい！」「このスタイルシートも！」と、何度も何度も「リクエスト」を送りますよね。

このリクエストには、毎回同じような情報が含まれています。

毎回、全く同じ内容を大きな封筒に入れて送っていたら、郵便局（ネットワーク）はパンクしてしまいますよね。そこで登場するのが「ヘッダー圧縮」です。

「毎回送る同じ情報は、辞書（テーブル）に登録して、番号だけでやり取りしよう！」

これがHPACK（HTTP/2の技術）の考え方です。でも、HTTP/3の世界では、これだけでは足りない「ある問題」が発生したのです。

—

HTTP/2（HPACK）は、非常に厳格な「順番」を大切にする仕組みでした。
「1番目の手紙が届かないと、2番目の手紙は開けられないよ！」というルールです。

しかし、HTTP/3（QUIC）は、「パケットはバラバラに届いても、あとで組み立てればいいよね！」という自由奔放なスタイル。ここで問題が起きます。

HPACKの「順番通りじゃないと辞書が更新できない」というルールを、QUICの「バラバラに届く」という世界に持ち込むと、「辞書が揃うまで処理が止まってしまう（ブロッキング）」という渋滞が発生するのです。

そこで生まれたのが、QPACKです。「多少順番が前後しても、うまく辞書をやり取りして渋滞を回避しよう！」という、非常に賢い仕組みなんですね。

—

QPACKは、大きく分けて2つの辞書を使い分けることで、この渋滞を解消しています。

「よく使われるヘッダー（`user-agent`など）」を、あらかじめサーバーとブラウザの両方が共通で持っている辞書です。これは「辞書に載っている言葉なら、番号だけでOK」という最強のショートカットです。

通信の途中で、「あ、このユーザーは最近このクッキーをよく使うな」と判断したら、その場で辞書に追加します。

ここがQPACKのすごいところ！
もし動的テーブルの情報がまだ届いていなくても、QPACKは「とりあえず今回は番号じゃなくて、直接文字で送っちゃえ！」と判断し、処理を止めません。これが「ブロッキング回避」の正体です。

—

実際にサーバー（NginxやEnvoyなど）を触る際、QPACKの挙動を調整するパラメーターがあります。設定ファイルでよく見かけるのはこんな項目です。

NginxでQPACKを制御する際のイメージ例
http {
# 動的テーブルの最大サイズ（サーバーが記憶しておくヘッダーの総量）
# 大きすぎるとメモリを食い、小さすぎると圧縮率が下がります
http3_qpack_table_size 4096;

# サーバーが「まだ届いていない情報」をどれだけ許容するか
# ストリームのブロッキングを防ぐための重要なチューニング値です
http3_max_blocked_streams 10;
}

`http3_qpack_table_size`: 辞書の大きさです。サーバーのメモリと相談して決めましょう。
`http3_max_blocked_streams`: ここを大きくしすぎると、辞書が届くのを待つリクエストが溜まりすぎてメモリを圧迫します。デフォルト値から始めるのが吉です。

—

QPACKは、単なるデータの圧縮技術ではありません。
「順番が前後しても、相手を待たせず、いかに効率よく情報を届けるか」という、ネットワークエンジニアたちの「思いやり」が詰め込まれた仕組みなんです。

こう考えると、HTTP/3の進化が少しだけ身近に感じられませんか？

もし皆さんがネットワークのトラブルシューティングをしていて、「なぜか通信が遅いな……」と感じたときは、ぜひこのQPACKの「辞書」のやり取りを思い出してみてください。

それでは、また次回の解説でお会いしましょう！Happy Networking!