握手の流儀：ALPNが切り拓くHTTP/2の高速な未来
ネットワークの現場において、「速さ」とは単なるスペックの羅列ではない。それは、OSのバッファからNICのキュー、そして光ファイバーを駆け抜ける電子の移動に至るまでの、無駄を削ぎ落とした「律動」そのものだ。
HTTP/2が登場して久しいが、未だにその「接続確立」の深淵に触れられていないエンジニアは少なくない。今回は、TLSハンドシェイクの裏側で密かに行われるALPN（Application-Layer Protocol Negotiation）という名の「プロトコルの選別」について、パケットの挙動を交えて紐解いていこう。
—
ALPN：0-RTTに近い決断の速さ
HTTP/1.1の時代、接続確立後に`Upgrade`ヘッダーを用いてプロトコルを切り替える方式があった。しかし、これは致命的なオーバーヘッドを生む。1往復の通信を無駄にし、サーバーの理解を待つという行為は、高レイテンシ環境では絶望的なロスだ。
そこで登場したのがALPNだ。これはTLSのハンドシェイクという「必須の儀式」の中に、プロトコルネゴシエーションを埋め込むという極めて賢明な手法だ。
パケットレベルの視点
クライアントが送る`ClientHello`の中に、`ALPN`という名のTLS拡張フィールドが忍び込んでいる。ここには`h2`（HTTP/2）や`http/1.1`という文字列がリストとして格納されている。
概念的なClientHelloの構造
TLSv1.3 Client Hello
- Extensions:
- ALPN (Application-Layer Protocol Negotiation)
- Protocol: h2
- Protocol: http/1.1
サーバーは、自身の対応状況を確認し、`ServerHello`で「今回は`h2`で行こう」と即座に回答する。これにより、暗号化通信が開始されるその瞬間に、アプリケーション層のルールも確定している。これが、HTTP/2が「接続したその瞬間からマルチプレクシング（多重化）を開始できる」最大の理由だ。
—
現場で直面するTCPバッファとHTTP/2の相性
HTTP/2の真髄は、1本のTCPコネクションで複数のストリームを処理するマルチプレクシングにある。しかし、ここでインフラアーキテクトが忘れてはならないのが、TCPの「ヘッド・オブ・ライン・ブロッキング（HOLB）」と、それを緩和するためのカーネルチューニングだ。
HTTP/2は1つのTCPストリームを共有するため、パケットロスが発生すると、その背後にある全てのストリームが停止する。これを避けるためには、LinuxカーネルレベルでのTCP制御が必須となる。
推奨されるsysctl設定（高負荷環境向け）
TCPの輻輳制御アルゴリズムをBBRに変更（パケットロス時のスループット低下を抑制）
sysctl -w net.ipv4.tcp_congestion_control=bbr
TCPウィンドウサイズを拡大し、高レイテンシ環境でのパイプライン効率を上げる
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
TCP Fast Openを有効にし、TLSハンドシェイクのRTTをさらに削減
sysctl -w net.ipv4.tcp_fastopen=3
—
HPACK：ヘッダー圧縮という名の記憶術
HTTP/2の効率化を語る上で欠かせないのがHPACKだ。HTTPはステートレスなプロトコルだが、リクエストのたびに「User-Agent」や「Cookie」といった巨大なヘッダーを送り続けるのは、現代のネットワークにおいてあまりに愚行だ。
HPACKは、ヘッダーを「静的テーブル（定義済み）」と「動的テーブル（通信中に学習）」に分割し、インデックス番号のみを送信する。
- 静的テーブル: `GET`, `User-Agent` 等の頻出ヘッダーを固定インデックスで保持。
- 動的テーブル: 通信のコンテキストに合わせて、クライアントとサーバー双方がメモリ上でヘッダーを「記憶」し合う。
注意点: この動的テーブルはメモリを消費する。大規模なCDNやロードバランサーを設計する際、`SETTINGS_HEADER_TABLE_SIZE`を過剰に大きく設定すると、メモリ枯渇攻撃（Slowloris的な側面を持つDoS）の標的になり得る。デフォルト値（4096バイト程度）を適切に運用し、接続ごとのメモリ占有量を監視することが、堅牢なシステムを構築する鍵だ。
—
セキュリティスペシャリストへの提言
HTTP/2の恩恵を享受する一方で、HTTP/2特有の脆弱性にも目を向けるべきだ。特に「HTTP/2 Rapid Reset」のような攻撃手法は、ストリームの生成と即時キャンセルを繰り返すことで、サーバーのリソースを意図的に圧迫する。
- 対策: NginxやEnvoyの設定で`http2_max_concurrent_streams`を適切に制限し、同時ストリーム数に上限を設けること。
- 監視: `netstat`や`ss`コマンドでコネクションの状態を追うだけでなく、APMツールを用いてストリームのライフサイクルを可視化すること。
最後に
ALPNによる接続の高速化、HPACKによるヘッダーの軽量化、そしてTCPバッファの最適化。これらは単なる設定値ではない。ユーザーがページを開こうとしたその瞬間に、光速に近いレスポンスを届けるための、エンジニアによる「工芸」だ。
ネットワークプロトコルは、ただ動けばいいというものではない。そのパケットがどのルートを通り、どのような制約の中で処理されているかを想像できる者だけが、真の「ハイパフォーマンス」を語る資格がある。
今夜もまた、サーバーのログを眺めながら、その目に見えない通信の律動に耳を澄ませてほしい。
コメント