HTTP/3への扉：ALPN「h3」がTLS 1.3ハンドシェイクの瞬間に果たす運命の選択
ネットワークの現場に身を置く者なら誰しも、パケットキャプチャを開いた瞬間に立ち込める静寂と、そこに流れるデータの美しさに魅了された経験があるはずだ。TCPの3ウェイハンドシェイクが終わり、TLSのClient Helloが飛び交う。その暗号化のベールに包まれる前の、あるいはまさにその暗号化を確立するコンテキストの中で、クライアントとサーバが「どの言葉で対話するか」を決める瞬間がある。それが ALPN（Application-Layer Protocol Negotiation） だ。
HTTP/3、すなわちQUICをトランスポートとする次世代Webプロトコルにおいて、このALPNが果たす役割は、単なるプロトコルのすり合わせというレベルにとどまらない。それは、TCPという長年の呪縛を断ち切り、UDPベースの新しい世界へシームレスに移行するための「最初の合言葉」なのだ。
今回は、TLS 1.3の暗号学的ハンドシェイクと密に結合したALPN識別子 `h3` が、どのようにパケットの世界で舞い、ネットワークの遅延を極限まで削ぎ落としているのか。その内部挙動の深淵へと、泥臭い実務の知見を交えながら飛び込んでいこう。
—
1. 従来の「ラウンドトリップの呪い」とHTTP/3への移行哲学
HTTP/2はマルチプレクシングをもたらし、HTTP/1.xのヘッド・オブ・ライン・ブロッキング（HoLB）をアプリケーション層で見事に解消した。しかし、その下層を支えるTCPには、どうしようもない構造的限界が残っていた。それが「トランスポート層におけるHoLB」であり、そして何より、接続確立にかかるRTT（Round Trip Time）のオーバーヘッドだ。
HTTPS（HTTP/2 over TLS over TCP）を思い出してほしい。
1. TCP 3-way handshake（1 RTT）
2. TLS 1.3 handshake（1 RTT、またはFast Openで0-1 RTT）
合計で最低でも2回の往復（TLS 1.2であればさらに増える）が、データを1バイトたりとも送る前に必要となる。さらに、パケットロスが発生した際、TCPの厳格な順序制御（Reliable In-Order Delivery）が災いし、後続のすべてのストリームが一時停止させられる。
これを根底から覆したのが、UDPをベースにトランスポート層を再構築した QUIC であり、その上で走る HTTP/3 だ。しかし、ここで大きな課題が生じる。クライアントは、目の前のサーバがHTTP/3を喋れるかどうかを、どうやって知るのか？ まさか、いきなりQUICでパケットを投げて「返事がないからHTTP/2にフォールバックしよう」などという無駄な往復を許すほど、現代のWebパフォーマンスエンジニアリングは甘くない。
ここで登場するのが、TLS 1.3の拡張として統合された ALPN である。
—
2. TLS 1.3ハンドシェイクにおけるALPN `h3` の内部挙動
HTTP/3におけるALPNの最大の特徴は、それがTLS 1.3の暗号化ハンドシェイクと完全に一体化している点にある。QUICはそれ単体で暗号化（TLS 1.3をベースにしたQUIC TLS）を内包しているため、接続確立の最初のパケット（Client Initial）にTLSのClient Helloが乗せられる。
このClient Helloの拡張フィールドの中に、クライアントがサポートするアプリケーションプロトコルのリストが格納される。ここで使われる識別子が `h3` だ。
パケットの軌跡：Client Hello から Server Hello まで
実際のワイヤー上の動きを追ってみよう。
1. Client Initial (QUIC Packet)
- クライアントはUDP/443（あるいは指定ポート）に向けてQUICのInitialパケットを送信。
- このペイロードに含まれるTLS 1.3の `Client Hello` 内の `application_layer_protocol_negotiation` 拡張に、以下のようなバイト列が載せられる。
- `h3` (HTTP/3)
- `h3-29` (ドラフト版の残党。レガシー互換のために残っていることがある)
- `http/1.1` (万が一のためのフォールバック)
2. Server Handshake (QUIC Packet / Encrypted Extensions)
- サーバ側はQUICのスタック（nginxなら nghttp3/quiche、Envoyなら 자체実装など）でこれを受け取る。
- サーバがHTTP/3をサポートしており、かつクライアントの提示したリストの中に合致するものがあれば、TLS 1.3の `Encrypted Extensions` 内のALPN拡張で唯一の勝者を返す。
- ここでサーバが `h3` を選択すれば、この瞬間からこのQUICコネクション上で流れるすべてのアプリケーションデータは、HTTP/3のセマンティクスに従うことが確定する。
この一連のネゴシエーションは、QUICの接続確立フェーズ（Cryptoストリームのやり取り）と完全に並行して、あるいはその一部として処理される。つまり、追加のRTTを一切消費しない。これこそが、アーキテクトがTLS 1.3 + QUICの組み合わせに熱狂する理由である。
—
3. 実務で直面するHTTP/3 & ALPNのトラブルシューティング
机上の空論はここまでにして、現場のインフラエンジニアが直面する現実の話をしよう。NginxやEnvoy、あるいはCDNのエッジ設定において、HTTP/3を有効化したつもりが、なぜかブラウザがHTTP/2（あるいはHTTP/1.1）のままで通信し続ける現象に遭遇したことはないだろうか。
大抵の場合、原因は以下のいずれか、あるいは複合的なものだ。
トラブル事例 1: UDPのブロック（防火壁とファイアウォール）
企業内のプロキシや、設定の甘いクラウドのセキュリティグループ（AWS SGなど）が、UDP/443ポートを遮断しているケース。
TCP（HTTP/2）であれば問題なくハンドシェイクが進むため、ブラウザは「HTTP/3の接続試行（QUIC Initial）がタイムアウトした」と判断し、静かにTCPへフォールバックする。ユーザーは体感速度の低下に気づきにくいが、サーバー側のメトリクスを見るとHTTP/3のヒット率がゼロに張り付くことになる。
トラブル事例 2: Alt-Svcヘッダーの未設定または誤設定
初回のアクセスでは、ブラウザはサーバがHTTP/3を喋れるかどうかわからないため、通常はHTTPS（HTTP/2）で接続する。ここでサーバが返すべき魔法の呪文が `Alt-Svc` (Alternative Services) ヘッダーだ。
HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Alt-Svc: h3=”:443″; ma=86400, h3-29=”:443″; ma=86400
このヘッダーを受け取ったクライアント（ブラウザ）は、「あ、このオリジンはポート443でHTTP/3（`h3`）もいけるんだな」と学習し、次回の接続からは最初からQUIC/HTTP/3を選択するようになる。この `Alt-Svc` の設定漏れや、`ma`（Max-Age）パラメーターの調整不足が、HTTP/3普及の大きな足かせとなっている現場を数多く見てきた。
—
4. 設定の実例：NginxにおけるHTTP/3 & ALPNの有効化
理論とトラブルシューティングを踏まえ、モダンなLinux環境（OpenSSL 3.0以上またはBoringSSL、QUIC対応のNginxビルド）における具体的な設定例を見ておこう。
HTTP/3 (QUIC) を有効にしたサーバブロックの構成例
server {
listen 443 ssl;
listen 443 quic reuseport; # UDPの443ポートでQUIC待ち受け、マルチコア対応のreuseportを付与
server_name example.com;
# SSL証明書の設定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# TLS 1.3はHTTP/3の必須要件。古いプロトコルは排除する
ssl_protocols TLSv1.3;
# ALPNによるプロトコルネゴシエーションの定義
# 順番が重要。h3を先頭に置くことで、クライアントにHTTP/3を強く推奨する
ssl_stapling on;
ssl_stapling_verify on;
location / {
root /var/www/html;
index index.html index.htm;
# クライアントに次回の接続でHTTP/3を使うよう指示するAlt-Svcヘッダー
# ma=2592000 は 30日間のキャッシュを意味する
add_header Alt-Svc ‘h3=”:443″; ma=2592000; persist=1’ always;
}
}
この設定を適用したサーバーに対し、`curl` コマンドを用いてALPNとHTTP/3の挙動をデバッグする際のスニペットがこれだ。
curlでHTTP/3 (QUIC) を強制して接続テストを行う
–http3 オプションにより、内部でQUICを使ったパケット送受信とALPN h3のネゴシエーションが行われる
curl -I –http3 https://example.com/
期待される出力のイメージ（レスポンスヘッダーやHTTPバージョン）
HTTP/3 200
alt-svc: h3=”:443″; ma=2592000; persist=1
…
もし手元の `curl` がHTTP/3をサポートしていない場合（`nghttp3` や `ngtcp2`、あるいはBoringSSLのリンクが必要）、`tshark` や `wireshark` を立ち上げてパケットをキャプチャし、TLS Handshakeの `Client Hello` / `Encrypted Extensions` 内の `ALPN extension` を覗いてみるといい。そこに `h3` という3文字が鮮やかに刻まれているのを確認できるはずだ。
—
5. ヘッダー圧縮（QPACK）とALPNの深い関係
最後に、HTTP/3におけるデータ転送の核心、QPACK とALPNの文脈について触れておこう。
HTTP/2では「HPACK」というヘッダー圧縮アルゴリズムが使われていた。これは前後のリクエスト間で静的・動的なテーブルを共有し、ヘッダーサイズを劇的に削減するものだった。しかし、HTTP/2はTCPベースのストリームであり、パケットロスが発生するとTCP層で全体がブロックされるため、HPACKの動的テーブルの順序が狂うことはなかった。
だが、QUICはパケットロスが発生したストリームを無視して、他のストリームを先に処理する（マルチプレクシングの真骨頂）。もしHPACKをそのまま使えば、ロスしたパケットに含まれていた動的テーブルの更新情報が失われた瞬間、後続のストリームですべてのヘッダーデコードが破綻してしまう。
そこで生み出されたのが QPACK だ。
QPACKは、ヘッダー圧縮の動/静的テーブルの管理を、通常のアプリケーションデータストリーム（Request/Response streams）から切り離し、専用の双方向ストリーム（Encoder stream / Decoder stream） を用いてやり取りする仕組みをとっている。
このQPACKのセマンティクスが有効に機能するためにも、大元のトランスポートとセキュリティ層において、ALPN `h3` による厳密な合意が不可欠なのである。TLSハンドシェイクの瞬間に `h3` が選ばれたからこそ、エンジンは「このコネクション上ではQPACKのルールに従った双方向制御ストリームを初期化せよ」という判断を下すことができる。
—
結びにかえて
ネットワークプロトコルの進化は、地味な仕様の積み重ねのようでいて、実は極めてドラマチックだ。
ALPN `h3` は、単なるテキストの文字列ではない。それは、クライアントとサーバが「我々はもはや古いTCPの制約に縛られる必要はない。今この瞬間から、より速く、よりロバストなQUICの宇宙へ旅立とう」と交わす、静かなる宣誓なのである。
パケットの向こう側で何が起きているのかを想像できるエンジニアだけが、真に安定し、かつ爆速のインフラストラクチャを構築できる。今日のパケットキャプチャには、どんな未来のプロトコルが流れているだろうか。さあ、ターミナルを開き、自分の手で確かめてみよう。
コメント