【実務・中級編】HTTP/3におけるALPN(Application-Layer Protocol Negotiation)の役割 – HTTPプロトコル・通信規格実践ガイド

こんにちは。シニアネットワークエンジニアの私だ。

Webフロントエンドの高速化や、国内外をまたぐモバイル回線でのパケットロス対策として、HTTP/3（QUICベース）への移行を検討・検証している現場は多いことだろう。だが、TCPからUDP（QUIC）へボトムからガラリと変わるこのプロトコル、いざ本番環境に導入しようとすると「どうやってブラウザやクライアントがHTTP/3の存在に気づき、シームレスに切り替えるのか」というハンドシェイクの初期動作でつまずくエンジニアが後を絶たない。

そこで今回は、HTTP/3の扉を開く鍵である ALPN（Application-Layer Protocol Negotiation） と、その識別子である `h3` の役割にスポットを当て、パケットの往復から実際のデバッグ・実装設定までを徹底的に紐解いていこう。教科書をなぞるだけでは見えてこない、現場のリアルな挙動を共有する。

—

1. HTTP/3とALPN：なぜ暗号化ハンドシェイクの中で合意が必要なのか？

これまでのHTTP/1.1やHTTP/2は、信頼性の高いTCPコネクションを確立した その上 で、TLSハンドシェイクを行い、その拡張であるALPN（RFC 7301）を使って「HTTP/1.1にするか、HTTP/2（識別子 `h2`）にするか」をネゴシエーションしていた。

しかし、HTTP/3の世界は根本的に異なる。下層レイヤーにTCPではなく UDPベースのQUIC を採用しているため、コネクション確立とTLS 1.3による暗号化ハンドシェイクが完全に一体化しているのだ。

従来のTCP + TLS vs QUIC + TLS 1.3

• HTTP/2 (TCPベース):

[TCP 3-way ハンドシェイク] ➔ [TLS 1.3 ハンドシェイク (ALPN: `h2`)] ➔ データ転送

• HTTP/3 (QUICベース):

[QUIC Initial / Handshake (同時にTLS 1.3を実行、ALPN: `h3`)] ➔ 暗号化データ転送即座に開始

この統合されたTLS 1.3ハンドシェイクの「Client Hello」および「Server Hello」の拡張領域に埋め込まれるのが、アプリケーション層プロトコル識別子 `h3` である。クライアントはこの `h3` を提示することで、「私はHTTP/3を喋ることができます」とサーバーに宣言し、サーバーがそれを許可（エコーバック）することで、晴れてQUIC上のHTTP/3セッションが確立される。

—

2. 通信の全貌：ALPN `h3` を用いたネゴシエーション・フロー

では、実際のワイヤー上でパケットがどのようにやり取りされているのか、シーケンスを見てみよう。初めてアクセスするサイトの場合、クライアントは通常HTTP/3の存在を知らないため、最初はAlt-Svcヘッダーや事前のキャッシュによる「オルタネート（代替）接続」を利用するか、あるいは「Race（競合）」と呼ばれるアプローチをとる。

ここでは、すでにブラウザが「このサーバーはHTTP/3をサポートしている」と学習している状態（あるいはAlt-Svcで通知された状態）での、ダイレクトなQUIC/HTTP/3ハンドシェイクのフローを示す。

[Client] [Server (Nginx/Envoy等)]
| |
|— ① QUIC Initial (Client Hello + TLS 1.3 + ALPN: “h3”) ————>|
| (※ この1往復目で暗号化とプロトコル合意が同時に完了する) |
| |
|<-- ② QUIC Handshake (Server Hello + ALPN: "h3" 確定) --------------| | | |=== ③ 0-RTT / 1-RTT Data (HTTP/3 HEADERS / DATA frames) ============>|
| (マルチプレクスされたストリームでリクエスト/レスポンスを並列処理) |

ポイントは、TLSのハンドシェイクパケット（Cryptoフレーム）の中にALPNのバイト列が含まれている点だ。Wiresharkなどでキャプチャすると、TLSの `Extension: application_layer_protocol_negotiation (len=4)` の中に `h3` という文字列がはっきりと確認できるはずだ。

—

3. 実務での壁：Alt-Svcヘッダーによるプロトコル広告

「最初からHTTP/3で接続できないなら、どうやってクライアントは `h3` の存在を知るのか？」
ここがインフラエンジニアの腕の見せ所だ。答えは Alt-Svc（Alternative Services）ヘッダー である。

初回アクセスをHTTPS (HTTP/2など) で受けたサーバーは、レスポンスヘッダーで次のようにクライアントへ囁く。

HTTP/2 200 OK
content-type: text/html; charset=UTF-8
alt-svc: h3=”:443″; ma=86400, h3-29=”:443″; ma=86400

• `h3=”:443″`: このサーバーのポート443では、QUICを使ったHTTP/3 (`h3`) が稼働しているよ、という告知。
• `ma=86400`: Max-Age（有効期限）。この情報とポートの組み合わせをクライアント（ブラウザなど）が86400秒（24時間）キャッシュし、次回以降のアクセスではいきなりUDP/443へQUIC接続（ALPN: `h3`）を試みるようになる。

現場のトラブルシューティングでよくあるのが、「証明書の不備やファイアウォールのUDPブロック（UDP 443が塞がれている）によって、クライアントがHTTP/3へフォールバックしようとして体感が逆に重くなる現象」だ。Alt-Svcを設定する際は、必ずUDP/443が正常に疎通していることを確認してほしい。

—

4. コードと設定で見る：HTTP/3 (ALPN `h3`) の実装・検証ハンズオン

机上の空論はここまでにして、実際に手を動かして `h3` で通信が行われているかを確認・実装する方法を見ていこう。

A. curl コマンドによる検証（要HTTP/3対応ビルド）

近年の `curl`（nghttp3 / quiche / openssl等のバックエンドでビルドされたもの）は、標準でHTTP/3をサポートしている。以下のコマンドで、強制的にHTTP/3（ALPN: `h3`）で接続を試みることができる。

–http3 オプションを指定してリクエストを送信
冗長出力(-v)を有効にすることで、ALPNとして “h3” がネゴシエーションされたことがログに出力される
curl -I –http3 https://example.com/api/v1/status

実行時のログの見どころ:

• Using HTTP/3, Alt-Svc: h3=”:443″
• Connected to example.com (203.0.113.5) port 443 (#0)

incercepting ALPN: h3 negotiated <-- ここで h3 が合意されている

• HTTP/3 stream 0 is alive

< HTTP/3 200 < content-type: application/json

B. Python (httpx) を用いたモダンなAPIクライアント実装

Pythonの `requests` ライブラリは残念ながらまだHTTP/3（QUIC）のネイティブサポートが弱いが、次世代の `httpx` を使えば、実験的にHTTP/3クライアントを実装できる（※環境に `h2` や `quic` 系の依存ライブラリが必要）。

import httpx

def fetch_data_with_h3():
# HTTP/3を有効にしたクライアントを作成
# 内部的にQUICハンドシェイクを行い、ALPN ‘h3’ でセッションを確立する
with httpx.Client(http2=False, http3=True) as client:
try:
response = client.get(“https://example.com/api/v1/data”)
print(f”Status Code: {response.status_code}”)
print(f”Protocol Used: {response.http_version}”) # “HTTP/3″ が出力されるはず
print(response.json())
except httpx.HTTPError as exc:
print(f”HTTP/3 接続に失敗しました（フォールバック要確認）: {exc}”)

if __name__ == “__main__”:
fetch_data_with_h3()

C. Nginx / Envoy におけるALPN `h3` の受け入れ設定

サーバー側（リバースプロキシ）でHTTP/3を受け付けるための設定例だ。代表して Nginx の設定スニペットを掲載する。NginxでHTTP/3を有効にするには、リスナーに `quic` を指定し、Alt-Svcヘッダーを適切に出力させる必要がある。

server {
listen 443 ssl;
listen 443 quic reuseport; # UDPでのQUICリスニングを有効化

server_name example.com;

# SSL/TLS証明書の設定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;

# TLS 1.3 のみがQUIC/HTTP/3の前提条件
ssl_protocols TLSv1.3;

# ブラウザへ「HTTP/3が使えること」を通知するAlt-Svcヘッダー
# サーバ側で自動付与されない場合はadd_headerで明示的に追加する
add_header Alt-Svc ‘h3=”:443″; ma=86400’;

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

—

5. シニアからの現場的アドバイス：トラブルシューティングの勘所

最後に、実務でHTTP/3とALPN `h3` に挑むエンジニアへ、トラブルシューティングの指針を授けておこう。

1. 「UDPが通っていない」問題を見逃すな
AWSなどのクラウド環境や企業の社内プロキシ、ファイアウォールでは、セキュリティポリシーからUDPの443番ポートがドロップ（あるいはスロットル）されているケースが多々ある。TCPの443が通るのでHTTP/2までは動くが、HTTP/3（ALPN `h3`）のネゴシエーションだけタイムアウトするという現象に出会ったら、まず `nc -u` や `iperf3 (UDPモード)` でネットワーク層のUDP疎通を疑え。
2. 証明書チェーンの不備は即座にハンドシェイク失敗に繋がる
QUICのTLS 1.3は非常に厳格だ。中間証明書の欠落や、OCSPスタープの不備などがある場合、TLSハンドシェイクの途中でセッションが切断され、ALPN `h3` のネゴシエーションに至る前にTCP/HTTP/2へ強制フォールバックさせられる。ブラウザのコンソールやopensslコマンドで、TLS 1.3のハンドシェイク自体が正常に完結しているかを細かく追うことがデバッグの近道だ。

HTTP/3とALPN `h3` は、単なる「速いプロトコル」ではなく、トランスポート層とセキュアレイヤーのパラダイムシフトそのものだ。仕組みを深く理解し、手元のパケットとコードの挙動をリンクさせられれば、どんなモダンなWebインフラのトラブルも必ず論理的に解決できる。

さあ、今日のデプロイから、UDPの海へ向けて `h3` のシグナルを飛ばしてみよう。健闘を祈る。