はじめに：なぜ、あの瞬間にHTTP/2へ切り替わるのか？
Web APIの設計や、大規模なインフラのチューニングを行っていると、「HTTP/2やHTTP/3をどうやって確実に有効化するか」という壁にぶつかります。ブラウザを開いてモダンなサイトにアクセスすれば、何食わぬ顔でマルチプレクシング（多重化）の恩恵を受け、無数のリクエストが1本のTCPコネクションを駆け抜けていく。
しかし、ふと立ち止まって考えてみてください。
クライアント（ブラウザやAPIクライアント）とサーバーは、いったいどの瞬間を境に「よし、ここからはHTTP/2で話そう」と合意しているのでしょうか？
「TLSの暗号化が終わったあと？ いや、TCPの3ウェイハンドシェイクの時？」
もしあなたがインフラの現場で、古びたプロキシや独自実装のクライアントと格闘した経験があるなら、この「プロトコルの切り替え」がいかに繊細なプロセスの上に成り立っているかをご存知のはずです。
今回は、このプロトコル交渉の主役である ALPN (Application-Layer Protocol Negotiation) にスポットを当てます。パケットキャプチャの向こう側で何が起きているのか、その実務的なメカニズムを、現場のシニアエンジニアの視点から紐解いていきましょう。
—
1. ALPNとは何か？仕様の裏側にある「大人の会話」
歴史を少しだけ振り返りましょう。HTTP/2の前身であるSPDY、あるいは初期のHTTP/2ドラフトの時代、プロトコルの切り替えには NPN (Next Protocol Negotiation) というTLS拡張が使われていました。しかし、NPNは「サーバー側」が一方的にプロトコル候補を提示し、クライアントがそれに従うというサーバー優位の仕組みであり、TLSの仕様としても美しくありませんでした。
そこで登場したのが、RFC 7301で標準化された ALPN (Application-Layer Protocol Negotiation) です。
役割の本質：TLSハンドシェイクへの「相乗り」
ALPNの最大の美しさは、TLSの暗号化ハンドシェイクのプロセスに、アプリケーション層のプロトコル交渉を完全に相乗りさせた点にあります。
従来のHTTP/1.1では、まず平文でTCP接続を張り、HTTPの `Upgrade` ヘッダーを使って後からプロトコルを切り替える（あるいは最初にHTTP/2のプレーンテキスト版 `h2c` を試す）という、往復遅延（RTT）の無駄が発生していました。
しかし、ALPNを使えば、TLSの鍵交換（Client Hello / Server Hello）の最中に「俺、HTTP/2いけるよ」「私もh2対応してるわじゃあそれで」という合意が完了します。つまり、追加のネットワーク往復（RTT）を1回たりとも発生させずに、最初からHTTP/2の暗号化トンネルを掘り始められるのです。
—
2. 通信フローの解剖：TLS Client Helloからh2確立まで
では、実際のパケットのやり取りを時系列で追いかけてみましょう。Wiresharkを立ち上げてTLSのネゴシエーションを覗いたとき、そこには次のようなドラマが展開されています。
[Client] [Server]
| |
|—- [TCP 3-Way Handshake: SYN -> SYN-ACK -> ACK] ————>|
| |
|—- [TLS Client Hello] ————————————–>|
| 拡張領域: application_layer_protocol_negotiation |
| – 提示リスト: [“h2”, “http/1.1”] |
| |
| [TLS Server Hello] —-|
| 拡張領域: alpn |
|<---- 選択されたプロトコル: "h2" ------------------------------|
| |
|---- [TLS Key Exchange / Finished (暗号化開始)] -------------->|
|<--- [TLS Finished / 接続確立] --------------------------------|
| |
|=== [ここから完全な HTTP/2 (h2) 通信がスタート] ===============|
パラメーターの深掘り：識別子 “h2” と “http/1.1”
クライアントが送信する `Client Hello` のALPN拡張には、対応しているプロトコルのリストが優先度順に格納されます。
ここで用いる識別子（Protocol ID）は、IANA（Internet Assigned Numbers Authority）によって厳密に定義されています。
- `h2`: TLS上で動作するHTTP/2プロトコル（ALPNで使用されるのはこちら）。
- `h2c`: 平文（TCP直上）で動作するHTTP/2プロトコル（※現代の主要なブラウザやパブリッククラウドの多くはセキュリティ上の理由から `h2c` をサポートしていません）。
- `http/1.1`: 伝統的なHTTP/1.1。
サーバー側は、クライアントから提示されたリストの中から「自分がサポートしており、かつ最も優先したいもの」を1つだけ選び、`Server Hello` のALPN拡張で返します。もしサーバーがどちらも理解できなければ、TLSハンドシェイク自体をエラー（`no_application_protocol`）で中断します。
—
3. 実務での検証：curl、Python、そして設定ファイルの作法
インフラエンジニアやAPI開発者にとって最も重要なのは、「本当に意図したプロトコルで通信できているか」を自分の手でスピーディーに確認し、正しく設定することです。
① `curl` でのALPNネゴシエーションの覗き見
手元の環境で、サーバーが正しく `h2` を返すか確認する定番のワンライナーです。`-v`（verbose）オプションをつけ、出力されるTLSハンドシェイクのログに注目します。
HTTP/2 (ALPN: h2) でアクセスし、詳細なハンドシェイクログを出力する
curl -v –http2 https://example.com/api/v1/health
出力ログの注目ポイント（こういう記述を探す）:
ALPN: server accepted h2
Server certificate:
…
< HTTP/2 200
もし `ALPN: server accepted http/1.1` と表示された場合、サーバー側の設定ミス、あるいはTLSのバージョン（後述）に問題がある可能性が高いです。
② Python (requests vs httpx) での挙動の違い
開発現場でよくあるトラブルが、「PythonスクリプトからAPIを叩いたら、なぜかHTTP/1.1になってしまい、HTTP/2特有の仕様にハマる」というケースです。
業界標準の `requests` ライブラリは、実は歴史的な経緯からデフォルトではHTTP/2をサポートしていません（urllib3の制限）。HTTP/2で通信したい場合は、`httpx` などのモダンなクライアントを使用する必要があります。
httpx を使ったHTTP/2 (ALPN) 通信のサンプル
import httpx
http2=True を明示的に指定することで、内部のTLSハンドシェイク時に ALPN “h2” がネゴシエートされます
with httpx.Client(http2=True) as client:
response = client.get(“https://example.com/api/v1/data”)
print(f”ステータスコード: {response.status_code}”)
print(f”使用されたプロトコル: {response.http_version}”) # “HTTP/2″ と出力されるはずです
print(f”レスポンスヘッダー: {response.headers}”)
③ Nginx / Apache での設定の勘所
サーバーサイドを構築する際、ALPNを正しく機能させるためには「TLSのバージョン」と「暗号スイート（Cipher Suites）」の足回りが非常に重要です。HTTP/2の仕様（RFC 7540）により、ブラックリスト化された脆弱な暗号スイートを使用している場合、クライアントはHTTP/2への移行を拒否しなければならないと定められているためです。
以下は、Nginxで堅牢なHTTP/2（ALPN）環境を構築する際の実設定例です。
server {
listen 443 ssl http2; # 443ポートでSSL有効化しつつHTTP/2を有効にする
server_name api.example.com;
# 証明書と秘密鍵の設定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# TLSプロトコルバージョンの制限（HTTP/2にはTLS 1.2以上が必須）
ssl_protocols TLSv1.2 TLSv1.3;
# HTTP/2が許容する強固な暗号スイート（Weak Cipherを排除）
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers off;
location / {
proxy_pass http1_backend_cluster;
# バックエンドへのプロキシ時にもHTTP/2のコンテキストを維持する設定など
}
}
—
4. トラブルシューティング：現場で遭遇する「ALPNの罠」
最後に、私がこれまでの現場で幾度となく遭遇した「ALPNにまつわるトラブルと解決の知見」をいくつか共有しておきます。デバッグの引き出しとして持っておいて損はありません。
罠1：ロードバランサー（ALB/Cloudflare等）とバックエンドの落とし穴
「クライアントとALBの間」では完璧にALPNで `h2` が合意できているのに、バックエンドのアプリケーションサーバー（あるいはリバースプロキシ）との間で問題が起きるケースです。
特に、gRPC（HTTP/2必須）を使おうとして `The server closed the connection` や `RST_STREAM` エラーに悩まされる場合、ALBからバックエンドへの転送時にHTTP/1.1にダウングレードしてしまっていることが原因の大半です。ALBのターゲットグループ設定で、プロトコルバージョンとして「gRPC」または「HTTP/2」が明示的に指定されているか必ず確認してください。
罠2：古いOpenSSLやランタイムの呪縛
古めのオンプレミスサーバーやコンテナベースイメージ（例: 脆弱性の残る古いAlpineやCentOSベース）でPythonやGoのアプリを動かしていると、ビルド時にリンクされているOpenSSLのバージョンが古く、TLS 1.3のALPN拡張の挙動がおかしくなるケースがあります。「なぜか特定のクライアントからだけHTTP/2に移行できない」という現象にぶつかったら、まず `openssl s_client -connect … -alpn h2` コマンドを叩いて、サーバーがどのようなALPN応答を返すかを単体でテストしてみるのが一番の近道です。
OpenSSLを使った手動でのALPNネゴシエーションテスト
openssl s_client -connect api.example.com:443 -alpn h2
このコマンドの実行結果の中に `ALPNExtension: application/protocol, val: h2` と返ってくれば、サーバー側のALPNスタックは正常に機能しています。
—
おわりに
ALPNは、TLSハンドシェイクというほんの一瞬の暗号化の裏側で、モダンなWebの高速化を支える極めてエレガントなプロトコル交渉の仕組みです。普段私たちが何気なく使っている「HTTP/2による爆速なAPIレスポンス」は、この小さな3文字の識別子 `h2` の合意の上に成り立っています。
インフラストラクチャやAPIのパフォーマンスにこだわるエンジニアだからこそ、こうしたプロトコルの根底にある「目に見えないハンドシェイクのやり取り」に思いを馳せ、トラブルシューティングの武器を増やしていきましょう。あなたのネットワークライフに、確かなパケットの導きがあらんことを。
コメント