【入門編】 HTTP/3 (QUIC) のヘッダー圧縮 (QPACK) とUDPベースの信頼性確保 – ネットワーク基礎とWebセキュリティ実践ガイド

こんにちは！ネットワークの裏側を覗くのが大好きな技術ライターです。

インフラの世界に足を踏み入れると、最初は「TCP/IP」や「OSI参照モデル」といった教科書通りの堅苦しい言葉に圧倒されてしまいますよね。「パケットがどうこう」「ハンドシェイクがどうこう」と言われても、目に見えないデータが頭の中で迷子になってしまうのは仕方のないことです。一歩ずつ、リラックスして理解していきましょう！

今回は、現代のWebを爆速かつ安全に支えている最新技術、「HTTP/3（QUIC）」を取り上げます。その中でも、特に頭がこんがりそうな「QPACK（ヘッダー圧縮）」と、信頼性のない「UDP」の上でどうやって確実な通信を行っているのかというドラマチックな仕組みを、身近な例えを交えながらたっぷり解説していきますね。

—

1. そもそもHTTP/3ってなに？従来のHTTP/2との違い

これまでのWebの主役はHTTP/2でした。HTTP/2は、1本の太いパイプライン（TCPコネクション）の中で、画像やテキストなどたくさんのファイルを同時に流せる（多重化）という画期的な仕組みを持っていました。

しかし、ここに「TCPの呪い」とも呼べき弱点がありました。
TCPは「届いた順番を絶対に守る」という真面目すぎるプロトコルです。そのため、通信の途中でたった1つのパケットが消滅（パケットロス）すると、その後ろに詰まっているすべてのデータが、再送されて届くまで「ピタッ」とストップしてしまうのです。これを「ヘッド・オブ・ライン・ブロッキング（行頭ブロック）」と呼びます。

例えるなら、「1車線の高速道路で、先頭のトラックがパンクしたせいで、その後ろの乗用車がすべて立ち往生している状態」です。後ろの車には関係のない荷物が積まれているかもしれないのに、迷惑な話ですよね。

そこで登場したのが、UDPをベースにしたQUIC（クイック）を使うHTTP/3です。

—

2. UDPなのに「確実」？QUICのパケット再送と輻輳制御

「えっ、UDPって信頼性がない『投げっぱなし』のプロトコルじゃなかったっけ？」
その通り！DNSの問い合わせやオンラインゲームなどで使われるUDPは、郵便局の「普通郵便」のようなもので、相手に届いたかどうかを確認しません。

しかし、HTTP/3の土台となるQUICは、このUDPの殻をかぶりながら、内部でTCPと同等（あるいはそれ以上）の「確実な配達システム」を独自に作り上げてしまいました。

郵便配達の例えで見るQUICの強さ

HTTP/2（TCP）が「1本の大きなトラック」にすべての荷物を積んで走るのに対し、QUICは「独立した複数のバッグ」に荷物を分けて、それぞれ別のバイク便で送るようなイメージです。

マルチプレクシング（独立したストリーム）：

ひとつのQUICコネクションの中に、複数の「ストリーム（小部屋）」を作ることができます。もし画像データ用のストリームでパケットがロスしても、テキストデータ用のストリームは影響を受けずにスイスイ進みます。先頭のトラックがパンクしても、他のバイクは別ルートを走れるわけです。

コネクションIDの魔法（マイグレーション）：

スマホでWi-Fiから4G/5G回線に切り替わったとき、従来のTCPだとIPアドレスが変わるため、通信が途切れて再接続（ローディング地獄）になっていました。しかしQUICは「コネクションID」という固有のパスポートを持っているため、IPアドレスが変わっても「あ、さっきの続きね」とシームレスに通信を継続できます。

—

3. ヘッダーを小さく圧縮する技術「QPACK」の正体

Webブラウザとサーバーが通信するとき、URLやブラウザの種類（User-Agent）、Cookieなど、中身のデータ（画像やHTML）の何倍もある「メタデータ（HTTPヘッダー）」を毎回やり取りしています。

HTTP/2ではこれを「HPACK」という技術で圧縮していましたが、HTTP/3ではさらに進化させた「QPACK」が使われています。

辞書を使った暗号のような仕組み

毎回「私の名前はGoogle Chromeです」「私はこのCookieを持っています」とフルネームで名乗るのは無駄ですよね。そこで、よく使われるヘッダーの項目をあらかじめ「共通の辞書（インデックス）」に登録しておきます。

通常の送信： user-agent: Mozilla/5.0... （文字数が多くて重い）
QPACKの送信： ID: 24番 （たったこれだけの数字や短いコードで伝わる！）

しかし、ここでQUICならではのジレンマが発生します。
「パケットがバラバラの順番で届くかもしれないUDPの上で、もし『ID 24番』が辞書の登録ページより先に届いてしまったら、サーバーは『24番ってなんだっけ？』とパニックになってしまうのでは？」

QPACKの安全装置（動的テーブルと同期）

この問題を解決するため、QPACKには「安全な制御用ストリーム」が用意されています。
データ本体を送るストリームとは別に、「今度の辞書にはこの単語を追加したからね！」という連絡を専用のルートで確実に同期させながら、パケットの順序迷子を防いでいるのです。

—

4. 実務で触れるNginxでのHTTP/3 (QUIC) 設定例

理屈が分かったところで、実際にインフラエンジニアがサーバー側でどのようにHTTP/3を有効化しているのか、その設定の雰囲気を見てみましょう。

現代のWebサーバー（Nginxなど）では、QUICを有効にするために少し特別なパラメータを指定します。

# /etc/nginx/conf.d/example.com.conf
server {
    # 443番ポートでHTTPSを待ち受けつつ、UDPの443番でもQUICを受け付ける設定
    listen 443 ssl;
    listen 443 quic reuseport; # QUIC用のUDPリスニングを有効化

    server_name example.com;

    # SSL/TLS証明書の指定（HTTP/3にはTLS 1.3が必須です）
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    ssl_protocols TLSv1.3;

    # ブラウザに対して「ウチはHTTP/3が使えるよ！」と教えるためのレスポンスヘッダー
    # Alt-SvcヘッダーでUDPの443番へ誘導します
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC特有のバッファやタイムアウト設定
    quic_retry on; # 偽装パケット攻撃を防ぐためのリトライ有効化

    location / {
        root /var/www/html;
        index index.html;
    }
}

このように、設定ファイルの一行に quic reuseport と書くだけで、OSのネットワークスタックと連携し、高速なUDPパケットの処理がバックグラウンドで動き出します。

—

5. トラブルシューティングの現場から：QUICが動かないときのチェックポイント

実務でHTTP/3を導入した際、「あれ、ブラウザがHTTP/2のままで通信しているぞ？」という壁にぶぶつかることがあります。そんなときの現場でのチェックリストをシェアしますね。

1. ファイアウォール（セキュリティグループ）の穴あけ忘れ

TCPの 443 番ポートを開けていても、QUICはUDPの 443 番を使います。「UDPの443」を通す設定になっているか、クラウドのセキュリティグループやルーターを確認しましょう。

2. TLS 1.3への対応

QUICはトランスポート層の暗号化とTLSが一体化しています。古い暗号スイートを引きずっているとHTTP/3は立ち上がりません。

3. ブラウザ側のキャッシュやフラグ

初回アクセス時は Alt-Svc ヘッダーを読んで「次からHTTP/3で行こう」と判断するため、2回目以降のアクセスで初めてh3に切り替わることが多いです。Chromeの検証ツール（NetworkタブのProtocol列）で h3 と表示されているかじっくり確認してみてください。

—

まとめ

今回は、HTTP/3とQUIC、そしてQPACKの裏側にあるドラマを、郵便配達や道路の渋滞に例えて解説しました。

HTTP/3 は、信頼性のない UDP をベースにしつつ、アプリ側で賢くパケットの再送をコントロールする。
従来のTCPのような「行頭ブロック（ひとつの遅延が全体を止める現象）」がないため、ネットワーク環境が悪くてもサクサク動く。
QPACK により、重たいヘッダー情報も辞書機能を使ってスマートに圧縮・送信されている。

インフラやネットワークの世界は、一見すると無機質なコードの羅列に見えますが、その裏側では「どうすればデータをより速く、確実に、美しく届けるか」というエンジニアたちのロマンと工夫が詰まっています。

今日の解説が、あなたのネットワーク学習のワクワクする第一歩になれば幸いです。それではまた、次の技術の深淵でお会いしましょう！