HTTP/3への扉：ALPN識別子とネゴシエーションの深層
ネットワークの歴史において、トランスポート層のトランスポート機構そのものを置き換える試みは、常に狂気と紙一重のロマンを孕んでいる。TCPという、30年以上にわたってインターネットの血管を流れ続けた信頼性の高いパケット配送網。その上に築かれたTLS、そしてHTTP/2。これらは偉大な発明だったが、「ヘッド・オブ・ライン・ブロッキング（HoLB）」という、避けて通れない構造的呪縛を私たちに残した。
一つのパケットがロスしただけで、後続のすべてのストリームが凍りつく。この悪夢を断ち切るために登場したのが、UDPベースのQUICであり、その上に構築されたHTTP/3だ。
だが、考えてみてほしい。クライアントが初めてあるオリジンサーバーにアクセスする時、ブラウザやHTTPクライアントは、どうやって「このサーバーはHTTP/3を話せる」と知るのだろうか？ TCPの3Wayハンドシェイクを飛び越え、最初からUDPの海へ飛び込むことはできない。この「鶏と卵」のジレンマを解決し、ミリ秒単位の遅延すら削ぎ落とす仕組みこそ、TLS 1.3のALPN（Application-Layer Protocol Negotiation）識別子とネゴシエーションの魔術に他ならない。
今回は、パケットのワイヤーフォーマット、TLSハンドシェイクの内部挙動、そして現場のインフラエンジニアが知るべきアップグレードパスの裏側を、徹底的に解剖していこう。
—
1. 接続の起点：Alt-SvcとALPNが描く未来
HTTP/3のセッションが確立されるシナリオには、大きく分けて2つのルートが存在する。すでに一度そのサーバーと通信した実績がある「既知のセッション（0-RTTまたは再接続）」と、完全な「初回の接続（First-Contact）」だ。
初回接続のパラドックスとAlt-Svc
クライアントが初めて `https://example.com/` にアクセスする場合、DNSを引いた後に最初に行うのは、標準的なTCP接続の確立とTLSハンドシェイク（通常はHTTP/2またはHTTP/1.1）である。この瞬間、クライアントはまだHTTP/3を使えない。
ここでサーバー側がHTTP/2のレスポンスヘッダーに仕込むのが、`Alt-Svc`（Alternative Services） ヘッダーだ。
HTTP/2 200 OK
Content-Type: text/html
Alt-Svc: h3=”:443″; ma=2592000, h3-29=”:443″; ma=2592000
このヘッダーの意味を、ネットワークの文脈で翻訳してみよう。「おい、クライアント。もしお前がUDPの443番ポートを叩けるなら、次回からの通信はTCP（HTTP/2）ではなく、`h3`（HTTP/3）に切り替えてくれ。この設定の有効期限（max-age）は30日間だ」とサーバーが宣言しているのだ。
クライアント（ブラウザなど）の内部では、この情報をオプティミスティックにキャッシュする。次回以降、同じドメインへのリクエストが発生した際、ブラウザはTCPハンドシェイクを待つことなく、並行してUDP（QUIC）による接続試行を開始できる。これが「Alt-Svcによるアップグレードパス」の実態である。
—
2. TLS 1.3ハンドシェイクとALPN識別子 `h3` の深層
HTTP/3は、トランスポート層にTCPではなくQUICを採用している。そしてQUICは、そのプロトコルのトポロジの中にTLS 1.3の暗号化ハンドシェイクを完全に統合している。つまり、QUICのパケットペイロードのなかで、TLS 1.3のClientHelloとServerHelloが交わされるのだ。
このTLSハンドシェイクの拡張フィールドにおいて、アプリケーション層のプロトコルを合意するために使われるのが ALPN（Application-Layer Protocol Negotiation, RFC 7301） である。
ワイヤーフォーマットに見る `h3` の識別
TLS 1.3のClientHelloメッセージの中には、サポートするプロトコルの一覧がバイト列として格納される。HTTP/3を示す識別子は、シンプルに`h3`という文字列（ASCIIで `0x68 0x33`）だ。
パケットアナライザ（Wiresharkなど）でこの領域を覗くと、以下のようなネゴシエーションが行われていることが確認できる。
Transmission Control Protocol / UDP Payload
TLS Handshake Protocol: Client Hello
Extensions
Extension: application_layer_protocol_negotiation (len=14)
ALPN Extension
ALPN Protocol: h3
ALPN Protocol: h2
ALPN Protocol: http/1.1
クライアントは「私はHTTP/3 (`h3`)、HTTP/2 (`h2`)、そして最後の手段としてHTTP/1.1を話せる」とサーバーに告げる。サーバー側は、自身のNginxやCaddy、あるいはEnvoyなどのリバースプロキシの設定に基づき、対応可能なプロトコルを一つだけ選んでServerHelloで返す。
TLS Handshake Protocol: Server Hello
Extensions
Extension: application_layer_protocol_negotiation (len=4)
ALPN Extension
ALPN Protocol: h3
ここでサーバーが `h3` を選択した瞬間、このQUICコネクション上で流れるすべてのデータは、HTTP/3のセマンティクス（QPACKによるヘッダー圧縮、ストリーム多重化など）に従うことが保証される。もしサーバー側がHTTP/3を無効化していれば、フォールバックとして `h2` が選択され、ネゴシエーションは平和裏に完了する。
—
3. 実装の現場：Nginx / EnvoyにおけるHTTP/3・ALPN設定の勘所
理論が分かったところで、実際にこれを本番環境のインフラとして構築する際の設定を見てみよう。LinuxカーネルのUDPバッファチューニングと合わせ、現場のプロが記述する設定の極意を公開する。
Nginx (1.25+ / mainline) における設定例
NginxでHTTP/3を有効化する場合、リスニングソケットに `http3` キーワードを指定し、さらに `ssl_protocols` でTLS 1.3を強制することが必須となる（HTTP/3の仕様上、TLS 1.3未満は許容されない）。
server {
listen 443 ssl;
listen 443 http3 reuseport; # UDPでHTTP/3を待ち受け。マルチコア性能を引き出すためのreuseport
listen 443 http2; # 互換性維持のためのHTTP/2フォールバック
server_name example.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# HTTP/3の前提条件であるTLS 1.3を確実に有効化
ssl_protocols TLSv1.3;
# ブラウザにHTTP/3の存在を教えるAlt-Svcヘッダーの送出
add_header Alt-Svc ‘h3=”:443″; ma=86400’;
# QUIC用のパケットサイズ（MTU）最適化ヘッダー（必要に応じて調整）
# quic_gso on; を有効にするとLinuxカーネルのGeneric Segmentation Offloadが働きCPU負荷が激減する
quic_gso on;
quic_retry on; # DDoS対策のソースアドレス検証（Retry packetの送信）
location / {
root /usr/share/nginx/html;
index index.html;
}
}
Linuxカーネル側のチューニング（UDPバッファ）
HTTP/3（QUIC）はUDP上で動作するため、高トラフィック環境ではカーネルのUDP受信バッファが溢れ、パケットドロップが発生する。TCPの `rmem` / `wmem` と同様に、UDP側も明示的にチューニングを行う必要がある。
`/etc/sysctl.conf` に以下のパラメータを追記し、システムの限界を引き上げよう。
UDP受信/送信バッファの最大値を拡大（例：最大25MB）
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
デフォルトのバッファサイズ
net.core.rmem_default = 67108864
net.core.wmem_default = 67108864
커넬レベルでのUDPパケット処理キューの最大長
net.ipv4.udp_mem = 65536 131072 262144
反映するには `sudo sysctl -p` を実行する。これを怠ると、大量の同時リクエストを受けた際にQUICのInitialパケットがカーネルでドロップされ、ハンドシェイクが無限にタイムアウトするという地獄を見る。
—
4. セキュリティの罠とプロトコルダウングレード攻撃の回避
新しいプロトコルの導入には、常に新たな攻撃ベクトルのリスクが伴う。HTTP/3のネゴシエーションにおいて最も警戒すべきは、プロトコルダウングレード攻撃（Protocol Downgrade Attack）、あるいは不適切なAlt-Svcキャッシュによる中間者攻撃（MitM）だ。
Alt-Svcインジェクションと偽装の脅威
悪意ある攻撃者がWi-Fiスポットや経路上ルーターを掌握し、偽の `Alt-Svc: h3=”evil.com:443″` を注入してきたらどうなるか？ クライアントは本来のセキュアなオリジンとは異なる偽のQUICサーバーへ誘導され、トラフィックを傍受されるリスクがある。
これを防ぐための防衛策として、ブラウザおよびクライアント実装側では、Alt-Svcの適用対象が「同一オリジン（Same-Origin）」である厳格な検証を行っている。クロスオリジンへのAlt-Svc指定には、サーバー側で `Alt-Used` ヘッダーやCORSの厳格なポリシー、あるいはオリジン認証（Alt-Svcの証明書が元のドメインと一致していることの検証）が必須となる。
TLS 1.3のゼロラウンドトリップ（0-RTT）とリプレイ攻撃
HTTP/3とQUICの最大の売りの一つが、以前接続したサーバーに対して暗号化パラメータをキャッシュし、初回パケットからアプリケーションデータを送信できる 0-RTT（Zero Round Trip Time） だ。
しかし、0-RTTデータ（早期データ）は、暗号学的には「リプレイ攻撃（Replay Attack）」に対して脆弱性を持つ。悪意ある攻撃者が、正当なユーザーが送信した「決済リクエスト」のQUICパケットをキャプチャし、そのまま何度もサーバーに再送（リプレイ）した場合、サーバーがそれを正当なリクエストとして処理してしまう危険性がある。
アーキテクトとしての実践的な解法：
サーバーサイドの実装（NginxやCloudflare等のエッジ）において、冪等性を持たない（POST、PUT、DELETEなどの状態を変更する）リクエストに対しては、0-RTTでの処理をデフォルトで拒否するか、アプリケーション層のトークン（ワンタイム・ノンス）によって厳格にバリデーションする設計が不可欠である。
Nginxにおける0-RTTの制御（必要に応じて安全側に倒す）
ssl_early_data on; は便利だが、決済系などのクリティカルなAPIサーバーでは
リプレイ攻撃のリスクを考慮してあえて無効化する判断もプロの選択肢となる。
ssl_early_data off;
—
5. 結びにかえて：パケットの未来を見据えるエンジニアへ
HTTP/3のALPN識別子 `h3` とネゴシエーションの仕組みは、単なる「文字列の合意」にとどまらない。それは、長年インターネットを縛り付けてきたTCPの呪縛を解き放ち、暗号化とトランスポートを完全に一体化させた次世代インフラストラクチャの「合言葉」なのだ。
Alt-Svcによるシームレスな移行、TLS 1.3の拡張領域で行われる高速なネゴシエーション、そしてカーネルレベルのUDPチューニング。これらを点ではなく「線」として理解し、設計・実装できるインフラエンジニアこそが、次世代のWebパフォーマンスとセキュリティを担保する主役となる。
さあ、あなたのコンソールを開き、パケットキャプチャを立ち上げよう。そこには、TCPの枠組みを脱ぎ捨てた新しいパケットたちが、軽やかにUDPの海を駆けていく美しい挙動が広がっているはずだ。
コメント