TLSハンドシェイクの裏側で何が起きているのか？HTTP/2 ALPNが実現する真のゼロ・ラウンドトリップ・ネゴシエーション
インターネットのトラフィックの大半が暗号化され、セキュアであることが「標準」となった現代において、私たちが日常的に利用するブラウザとWebサーバーの間では、目に見えない幾重ものハンドシェイクがミリ秒単位のドラマを生み出しています。
TCPの3ウェイ・ハンドシェイクが完了し、その直後に始まるTLS（Transport Layer Security）ハンドシェイク。この暗号化の確立プロセスにおいて、クライアントとサーバーが「これからどのアプリケーション層プロトコルで会話するか」をスマートに合意するための技術、それが ALPN（Application-Layer Protocol Negotiation） です。
特に、HTTP/1.1の呪縛である「Head-of-Line Blocking（ヘッド・オブ・ライン・ブロック）」を打破し、単一のTCPコネクション上で多重化（Multiplexing）を実現する HTTP/2 にとって、ALPNは単なる「おまけの拡張機能」ではありません。それは、パフォーマンスの極限を追求するインフラアーキテクトやテックリードにとって、絶対に避けて通れない最前線のプロトコル仕様なのです。
今回は、パケットレベルの挙動、TLSとの緻密な連携、そして現場のエンジニアが知るべき実装上の必須要件に至るまで、ALPNの深層を徹底的に紐解いていきましょう。
—
1. なぜALPNが必要だったのか？ —— 握手から始まるプロトコル選択の歴史
HTTP/2の仕様（RFC 7540）を読み解くと、非常に興味深い、しかし極めて合理的な制約に行き当たります。それは、「HTTP/2は、原則として暗号化されたTLS（TLS 1.2以降）の上でしか動作させない（h2）」 という方針です（※暗号化なしの明文通信は `h2c` と呼ばれますが、主要ブラウザはこれを完全にサポートしていません）。
歴史を少し振り返ってみましょう。HTTP/1.1からHTTP/2へ移行する過渡期、クライアントはサーバーに対して「自分はHTTP/2を話せますよ」と伝える必要がありました。
従来のNPN（Next Protocol Negotiation）の限界
最初に考案されたのはGoogleが主導した NPN ですが、これは致命的な設計ミスを抱えていました。サーバー側が「どのプロトコルに対応しているか」をクライアントに一方的に提示し、クライアントがそれを選択するというフローだったため、サーバー側のCPU負荷やハンドシェイクのラウンドトリップが増加する原因となりました。また、TLSのハンドシェイクのシーケンスに対して後付けでねじ込んだような仕様であり、拡張性に乏しかったのです。
ALPNによるパラダイムシフト（RFC 7301）
これに代わってIETFが標準化したのが ALPN です。ALPNの美しさは、TLSハンドシェイクという「既存のセキュアな枠組み」に完全に溶け込んでいる点にあります。
TLSのClient Helloメッセージの中に、クライアントがサポートするアプリケーションプロトコルの一覧（ALPN Extension）を格納し、Server Helloでサーバーがその中から1つを即座に選択する。これにより、追加のラウンドトリップ（RTT）を一切発生させることなく、暗号化の確立とアプリケーションプロトコルの決定を同時に完了させる ことが可能になりました。
—
2. パケットキャプチャで見るALPNの正体 (`h2` プロトコルID)
百聞は一見に如かず。Wiresharkや`tcpdump`を用いて、TLSハンドシェイクのパケットを覗いてみましょう。
クライアント（ブラウザ等）がTLS 1.3のClient Helloを送信する際、Extensionフィールドに `application_layer_protocol_negotiation` が含まれています。
Transmission Control Protocol (TCP)
Transport Layer Security (TLS)
TLSv1.3 Record Layer: Handshake Protocol: Client Hello
Extension: application_layer_protocol_negotiation (len=14)
ALPN Extension
ALPN Extension Length: 12
ALPN Protocol
ALPN string: h2 <-- HTTP/2を示すマジック文字列
ALPN string: http/1.1 <-- フォールバック用のHTTP/1.1
ここで注目すべきは、`h2` というたった2文字のASCII文字列（バイナリ表現では `\x02h2`）です。これがHTTP/2を表す公式のALPNプロトコルIDです。
サーバー側は、自身の設定（Nginxであれば `ssl_protocols` や `http2` ディレクティブなど）に基づき、このリストから `h2` を選択し、Server Helloで返却します。
TLSv1.3 Record Layer: Handshake Protocol: Server Hello
Extension: application_layer_protocol_negotiation (len=5)
ALPN Extension
ALPN Protocol
ALPN string: h2 <-- サーバーがHTTP/2の採用を断言
この瞬間、トランスポート層（TCP）と暗号化層（TLS）の確立と同時に、「このコネクション上ではHTTP/2のストリームとフレーミング規則に従ってバイナリデータを流す」という強固な合意が形成されます。
—
3. 実装上の必須要件と、現場で踏みがちな「地雷」
インフラエンジニアやバックエンドエンジニアが、Nginx、HAProxy、あるいはGoやNode.jsなどのモダンな言語でHTTP/2サーバーを構築する際、ALPNに関して絶対に押さえておかなければならない「実践的な要件」があります。
要件1：TLSバージョンと暗号スイート（Cipher Suites）の厳格な選定
前述の通り、現代のメジャーブラウザ（Chrome, Safari, Firefoxなど）は、TLS 1.2以上 かつ モダンな暗号スイート が強制されない限り、ALPNで `h2` を要求してもサーバーがそれを拒否すると、コネクション自体を断絶（あるいはHTTP/1.1へフォールバック）します。
特にHTTP/2の仕様（RFC 7540 Appendix A）では、パフォーマンスやセキュリティの観点から ブラックリスト化された暗号スイート（Weak CiphersやRC4、CBCモードの一部など） を使用している場合、サーバー側は `INADEQUATE_SECURITY` というエラーコード（エラータイプ `0x6`）を返して接続を拒絶しなければならないと定められています。
実例：Nginxにおけるモダンかつ堅牢なTLS/ALPN設定
実務で即座に使える、NginxのTLSおよびHTTP/2設定の模範解答を見てみましょう。
server {
listen 443 ssl http2; # ポート443でSSLを有効にし、HTTP/2を有効化
server_name example.com;
# 証明書と秘密鍵の指定
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# TLSプロトコルはTLS 1.2およびTLS 1.3のみを許可（古い脆弱なプロトコルを排除）
ssl_protocols TLSv1.2 TLSv1.3;
# HTTP/2の仕様に準拠した強力な暗号スイートのみを指定
# ブラックリストに含まれる古い暗号を排除し、前方秘匿性(PFS)を確保
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;
ssl_prefer_server_ciphers off; # TLS 1.3ではサーバー側の順序指定は原則不要
# セッションキャッシュの設定によるハンドショイクの高速化
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
location / {
root /var/www/html;
index index.html;
}
}
—
4. パフォーマンスの極限へ：ALPN・TLS・TCPバッファチューニングの統合
ALPNによってスムーズに `h2` のネゴシエーションが完了したとしても、そこでインフラの最適化が終わるわけではありません。HTTP/2の真骨頂である「マルチプレクシング（単一コネクションでの並列リクエスト処理）」を極限まで引き出すためには、下位レイヤーのチューニングが不可欠です。
1. 0-RTT（TLS 1.3）とHTTP/2のシナジー
TLS 1.3とALPN、そしてHTTP/2の組み合わせは、Webのレイテンシを極限まで削ぎ落とします。
一度接続したことがあるクライアントであれば、TLS 1.3の 0-RTT Resumption を利用することで、最初のClient Helloと同時に暗号化されたアプリケーションデータ（HTTP/2のフレーム）を送信することが理論上可能です。ただし、0-RTTデータにはリプレイ攻撃のリスクが伴うため、冪等性（Idempotency）を持つ安全なGETリクエスト以外での利用には細心の注意が必要です。
2. TCPウィンドウト・バッファチューニング
HTTP/1.1では、帯域を使い切るためにブラウザ側が複数のTCPコネクション（通常はドメインごとに6本程度）を張っていました。しかし、HTTP/2は基本的に1つのドメインにつき1つのTCPコネクションしか使用しません。
これは、1本のTCPコネクション上でパケットロスが発生した場合、そのコネクション上のすべてのHTTP/2ストリームがブロックされる（TCPのHead-of-Line Blocking）というトレードオフを意味します。
そのため、LinuxカーネルのTCPバッファ設定を適切に行い、帯域幅遅延積（BDP: Bandwidth-Delay Product）を最大化することが、HTTP/2環境下では極めて重要になります。
/etc/sysctl.conf などに記述する推奨パラメータの例
TCP送受信バッファのデフォルト値と最大値を拡大（高BDP環境向け）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
BBR混雑制御アルゴリズムの有効化（パケットロスに強く、HTTP/2のマルチプレクシングと相性が良い）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
従来のCUBIC混雑制御に比べ、Googleが開発した BBR（Bottleneck Bandwidth and Round-trip propagation time） は、パケットロスを「輻輳」ではなく単なる「変動」として高精度に処理するため、単一の肥大化したTCPコネクション上で大量のストリームを多重化するHTTP/2と抜群の相性を誇ります。
—
5. まとめ：プロトコルの深い理解がインフラの境界線を押し広げる
HTTP/2におけるALPNの役割は、単に「HTTP/2を使うかどうかの合図」という事務的なものではありません。それは、セキュアなトランスポート層（TLS）と、高効率なアプリケーション層（HTTP/2）を、余計なオーバーヘッドなしにシームレスに橋渡しする唯一無二の鍵です。
パケットのバイト列を読み解き、TLSのハンドシェイクの構造を理解し、さらにその下のLinuxカーネルのTCPスタックまでを見通す視点を持つこと。それこそが、障害に強く、秒速のレスポンスを叩き出す真にモダンなインフラストラクチャを構築するための条件です。
私たちが何気なくブラウザに打ち込むURLの裏側では、こうしたプロトコルたちの緻密なハンドシェイクと、エンジニアたちの知恵が毎秒何億回と交わされています。ぜひ、ご自身の環境のパケットキャプチャや設定ファイルを開き、その息吹をご自身の目で確かめてみてください。
コメント