こんにちは！インフラ・ネットワークの世界へようこそ。
私たちが普段なにげなく使っているWebブラウザ。URLを入力した瞬間にピカッと美しいWebサイトが表示されますが、その裏側では一体どんなドラマが繰り広げられているでしょうか。
「ボタンを押したらデータが届く」という魔法のような仕組みの裏には、実はクライアント（あなたのパソコン）とサーバー（遠くのデータセンター）の間で行われる、めちゃくちゃスマートな「事前の挨拶と相談」が存在しています。
今日は、その中でも現代の高速なWebを支える「HTTP/2」が、いかにして華麗にスタートラインに立つのか――その舞台裏の立役者である ALPN（Application-Layer Protocol Negotiation） について、一緒に紐解いていきましょう！難しい専門用語が出てきても大丈夫。一歩ずつ、身近な例えを交えて優しく解説していきますね。
—
1. 昔の約束と、新しい時代のジレンマ
一昔前のWebの世界（HTTP/1.1の時代）は、例えるなら「定食屋の注文スタイル」でした。
「まずご飯をくれ（リクエスト）」→「はい、ご飯です（レスポンス）」。「次に味噌汁をくれ」→「はい、味噌汁です」。一つの通信につき、ひとつのやり取りしかできなかったため、ページを表示するのに何度も何度も往復しなければならず、ちょっともどかしかったのです。
そこで登場したのが、一度に複数の注文を同時に並行して運べる、超効率的なスーパートラック便「HTTP/2」です。
ここで、ネットワークの世界ならではの大きな悩み（ジレンマ）が生まれます。
サーバーの扉を叩いたとき、クライアント（ブラウザ）はこう思っています。
「ねぇ、ぼく新しいHTTP/2で話したいんだけど、君（サーバー）はそれ理解できる？」
もし、お互いがHTTP/2に対応しているなら、最初から超高速なHTTP/2で会話を始めたいですよね。でも、もしサーバーが古くて「えっ、HTTP/1.1しか話せないよ？」という場合だったらどうでしょう。言葉が通じなくて大混乱になってしまいます。
「私たちはどの言語（プロトコル）で会話しましょうか？」
これを安全かつ一瞬で決めるために生まれたのが、今回主役の ALPN なんです。
—
2. 郵便配達に例えてみるALPNの仕組み
このやり取りを、現実世界に例えてみましょう。
あなたは海外の友人へ荷物を送りたいとします。その国の人とは「英語」で話すのが一番スムーズですが、もしかしたら相手は日本語しか話せないかもしれません。
手紙を書いてから「日本語しか読めません」と返事が返ってきたら、書き直すの手間ですよね。
そこで、あなた（クライアント）はこう考えました。
「出発する前の『握手（挨拶）』のタイミングで、こう尋ねてみよう。『私は英語（h2）と日本語（http/1.1）が話せるんだけど、君はどれがいける？』って！」
これを受ける相手（サーバー）も賢いです。
「おっ、君も英語（h2）が話せるのか！じゃあこれからは英語（h2）でいこう！」と、その場で即座に返答します。
この「暗号化された安全な握手（TLSハンドシェイク）の最中に、お互いが話せる言語をこっそりスピーディーに合意しちゃう仕組み」こそが、ALPN（Application-Layer Protocol Negotiation：アプリケーション層プロトコル交渉）の正体です。
—
3. 実際の通信の裏側を覗いてみよう
「なんだかカッコいい仕組みだね！」と思っていただけたところで、実際にネットワーク上で行われているやり取りの雰囲気を少しだけ覗いてみましょう。
私たちが普段見ているWebサイトの多くは、セキュリティのために鍵がかけられています（HTTPS）。この鍵をかけ合う手続き（TLSハンドシェイク）の中に、ALPNの情報がちゃっかり相乗りしています。
概念的なイメージとして、設定ファイルやデバッグツールで見るような形を覗いてみましょう。
【Nginxサーバーのイメージ設定】
現代のWebサーバーは、クライアントと手をつなぐときにこう設定されています
server {
listen 443 ssl http2; # SSLで待ち受けつつ、HTTP/2も有効化するよ
server_name example.com;
ssl_certificate /path/to/signed_cert.crt; # 身分証明書（SSL証明書）
ssl_certificate_key /path/to/private.key; # 秘密の鍵
# ALPNで交渉するプロトコルの優先順位リスト
# 「まずはHTTP/2(h2)で話したいな！ダメなら昔ながらのhttp/1.1でいこうね」と伝える設定
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}
この設定があるおかげで、ブラウザがサーバーに「こんにちは！」と声をかけた瞬間、サーバーは「お、HTTP/2の『h2』という合言葉が使えるな！」と判断し、無駄な通信の往復（オーバーヘッド）を一切発生させずに、最初からアクセル全開のHTTP/2通信をスタートさせることができるのです。
—
4. トラブルシューティングの現場から：ALPNがうまくいかないとき
インフラエンジニアとして現場に立っていると、たまにこんな壁にぶつかります。
「あれ？ 新しいサーバーを作ってHTTP/2を有効にしたはずなのに、なぜかブラウザのデベロッパーツールで見ると『http/1.1』で通信しているぞ…？」
こういうときの原因の多くは、実はこのALPNのすれ違いにあります。よくあるチェックポイントをいくつか挙げておきますね。
1. 古いTLSバージョンや暗号スイートを引きずっていませんか？
- HTTP/2の仕様上、あまりに古いセキュリティ方式（TLS 1.0や1.1など）の上では、ALPNが正しく機能しないように制限されているケースがあります。基本は `TLSv1.2` や `TLSv1.3` を使いましょう。
2. 中間にあるプロキシやロードバランサーの設定は大丈夫？
- クラウドのロードバランサー（ALBやCloudflareなど）を挟んでいる場合、手前の機器が「h2」をサポートしていても、背水のWebサーバー側への転送でHTTP/1.1に落ちてしまっている場合があります。
3. ブラウザやライブラリが古くないですか？
- クライアント側があまりに古い古いプログラムだと、「私、h2っていう合言葉知らないや…」となってしまい、安全にHTTP/1.1にフォールバック（格下げ）してしまいます。
コマンドラインから今のサーバーがどんなプロトコルを受け入れてくれるかサクッと確認したいときは、おなじみの `openssl` コマンドが使えます。
【実践！サーバーのALPN対応状況をこっそりチェックするコマンド】
サーバー（例: example.com）に対して、HTTP/2(h2)で話せるか直接聞いてみるテスト
openssl s_client -connect example.com:443 -alpn h2,http/1.1
実行したあとの出力の中に、以下のような一行が見つかれば大成功！
ALPN protocol: h2
これで「おっ、このサーバーはちゃんとHTTP/2で会話できるぞ」と確認できます。
もしここで `ALPN protocol: http/1.1` と返ってきたら、「おや、サーバー側の設定や対応バージョンに何か見落としがあるな？」と素早くアタリをつけることができます。プロトコルの足並みが揃っているかを一発で看破できる、エンジニア必携のテクニックですね。
—
おわりに：お互いの「言語」をスマートに合わせる優しさ
いかがでしたでしょうか？
ALPNという名前を聞くと、なんだか呪文のように難しく感じてしまいますよね。でも、その本質は「通信を始める一番最初の挨拶で、お互いに一番効率のいい共通言語をスマートに決めちゃう仕組み」に他なりません。
私たちが意識することなく、世界中のWebサイトが一瞬で表示されるのは、こうした見えない舞台裏で、クライアントとサーバーがコンマ数秒のうちに「じゃあ今回はこの言語でいこう！」と美しい握手を交わしているからなのです。
ネットワークの世界は、紐解いていくと人間社会のコミュニケーションととってもよく似ています。
次にWebブラウザを開くときは、画面の裏側で繰り広げられているこのスマートなアイコンタクトに、ちょっとだけ思いを馳せてみてくださいね。それでは、また次回の技術探訪でお会いしましょう！
コメント