こんにちは！ネットワークの世界へようこそ。インフラエンジニアの主筆ライターとして、日々数々のパケットと向き合っている私ですが、今回はWebの高速化を支える「HTTP/2」の、ちょっと裏側の主役についてお話ししたいと思います。
皆さんは普段、ブラウザでウェブサイトを見るとき、アドレスバーに「https://〜」と打ち込んでいますよね。この「https」の裏側では、通信を安全にするための暗号化（TLS）が行われているのですが、実は「このブラウザとサーバー、どちらも最新の速い通信規格（HTTP/2）で話そうよ！」と握手をする瞬間があるんです。
その握手の立役者こそが、今回テーマにする ALPN (Application-Layer Protocol Negotiation) です。
「なんだかアルファベットが並んでいて難しそう……」と思いましたか？ 大丈夫です！ 一歩ずつ、身近な例えから紐解いていきましょう！
—
1. 郵便配達で例える「何語で話すか問題」の解決
想像してみてください。あなたは日本から、遠くヨーロッパの郵便局へ荷物を送ろうとしています。
窓口に行って、いきなりペラペラと日本語で話し始めても、相手の係員が日本語を理解できなければ困ってしまいますよね。「あ、すみません、英語でお願いします」とか「ドイツ語でいけますか？」といったやり取りが、荷物をやり取りする前に必要になります。
Webの世界もこれとまったく同じです。
ブラウザ（あなた）とWebサーバー（郵便局の窓口）がネットの回線をつないだとき、最初にこんな会話が心の中で行われています。
- ブラウザ： 「こんにちは！ 私のブラウザは古い通信（HTTP/1.1）も、新しい超高速な通信（HTTP/2）もどっちも話せますよ！」
- サーバー： 「おっ、奇遇ですね！ 私のサーバーもHTTP/2対応ですよ。じゃあこれからは最新のHTTP/2でいきましょう！」
この「お互いにどの言語（プロトコル）で話すかを、通信の最初（暗号化のハンドシェイク時）にスマートに決める仕組み」が、ALPNの正体です。
—
2. 暗号化の「握手」のついでに決めるのがミソ
従来の古い仕組みでは、まず暗号化の通信路をがっちりと作ってから、「ねえねえ、これからどの規格で喋る？」とわざわざ後から確認していました。これだと、やり取りの回数（往復）が増えてしまい、Webページが表示されるまでにコンマ数秒のロスが生まれてしまいます。
せっかく暗号化のやり取り（TLSハンドシェイク）をするんだから、その「はじめまして」の挨拶のタイミングで、一緒に何語で話すかも決めちゃえば一石二鳥じゃん！ という天才的なひらめきから生まれたのがALPNです。
TLSの接続を確立するその一瞬の隙に、お互いのポケットの中を見せ合うように「うちは `h2` が話せます」「お、うちも `h2` いける口だよ」と一瞬で合意を形成します。
ここで登場する `h2` というのが、HTTP/2を表す公式のプロトコルIDです。この「h2」というパスポートを見せ合うことで、お互いに「よし、じゃあマルチプレクシング（多重化）やヘッダー圧縮のフル装備でいこう！」とスイッチが入るわけですね。
—
3. 実装時の必須要件：ALPNを動かすための条件
「じゃあ、うちのサーバーも今日からHTTP/2にしよう！」と思ったとき、実はいくつかクリアしなければならない現実的なハードル（必須要件）があります。ここを間違えると、「せっかく設定したのにHTTP/2にならない……！」という現場の罠にハマるので注意してくださいね。
主な必須要件は以下の3つです。
1. 暗号化（TLS 1.2 または TLS 1.3）が必須であること
- ALPNは、TLSの拡張機能として動きます。そのため、暗号化されていない「http://」の通信ではALPNは使えません。実質的にHTTP/2を使うにはHTTPSが必須となります。
2. サーバー側のソフトウェアがALPNに対応していること
- Nginx, Apache, EnvoyなどのWebサーバー、あるいはGoやNode.jsなどの言語の標準ライブラリが、ALPNに対応している必要があります（近年のモダンなソフトウェアであればほぼ標準クリアしています）。
3. TLSを処理するライブラリ（OpenSSLなど）が古すぎないこと
- ここがインフラエンジニアの落とし穴になりがちです。OSのバージョンが古く、組み込まれているOpenSSLが古いと、ALPNのネゴシエーションに対応できず、強制的に古いHTTP/1.1へフォールバックしてしまいます。OpenSSL 1.0.2以降が必須ラインとなります。
—
4. 実務で役立つ設定とデバッグのヒント
それでは、実際に現場でよく使われるNginxの設定を例に、ALPNがどのように意識されているか見てみましょう。特別な「ALPNを有効にする呪文」を何行も書く必要は実はあまりなく、正しいTLS設定を行うことがそのままALPNの有効化につながります。
server {
listen 443 ssl http2; # ポート443で待ち受け、SSLとHTTP/2を有効化
server_name example.com;
# 安全な暗号化スイート（TLS 1.2およびTLS 1.3）の指定
# ※ALPNを確実に成功させるため、モダンなTLS設定を心がけます
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ‘ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-HIGH:ECDHE-RSA-HIGH’;
# 証明書と秘密鍵のパス
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
location / {
root /var/www/html;
index index.html;
}
}
デバッグの裏技：本当に `h2` でネゴシエーションできているか？
「設定は書いたけど、ちゃんとALPNで `h2` が選ばれているかな？」と不安になったときは、手元の端末から `openssl` コマンドを使ってサクッと確認できます。これが現場でめちゃくちゃ役立つテクニックです。
OpenSSLを使って、example.com に対して ALPNプロトコル(-alpn h2) を指定して接続をテストする
openssl s_client -connect example.com:443 -servername example.com -alpn h2
このコマンドを叩いたとき、画面に表示される出力結果の中に、次のような行を見つけてみてください。
Reused, (NONE)
Start response
Negotiated protocol: h2 <-- ここが「h2」になっていれば大成功！
もしここが `http/1.1` になっていたり、何も表示されなかったりする場合は、サーバー側のOpenSSLのバージョンが古かったり、設定のどこかでTLSのハンドシェイクに失敗していたりします。
---
まとめ
今回は、HTTP/2を陰で支える交通整理の主役、ALPNについて解説しました。
- ALPNとは： TLSハンドシェイクのついでに、お互い何語（HTTP/2なのか、古いHTTP/1.1なのか）で話すかを決めるスマートな仕組み。
- 決まり手： 「`h2`」というパスポートを提示し合うことで、高速なHTTP/2の世界へ突入できる。
- 注意点： 暗号化（TLS）と、それを支えるOpenSSLなどのライブラリのバージョンが古くないか要チェック！
普段私たちがブラウザで何気なく爆速のWebサイトを見られているのは、こうした目立たないところで繰り広げられる「一瞬の合意」の積み重ねのおかげなんですね。
ネットワークやインフラの仕組みは、一見すると難解な用語の壁に阻まれがちですが、こうして現実世界のやり取りに置き換えてみると、エンジニアリングのロマンや美しさがぐっと見えてきます。
それでは、また次回のネットワーク探訪でお会いしましょう！ 日々のインフラ運用、一緒に頑張っていきましょうね！
コメント