HTTP/2ストリーム多重化の光と影：マルチプレクシングの背後にある「静かなる脅威」とリソース防衛のアーキテクチャ
ネットワークスペシャリストやインフラエンジニアの仕事とは、突き詰めれば「制限されたリソースの調停」に他ならない。帯域幅、CPUサイクル、メモリプール、そしてTCPのウィンドウサイズ。いかにして这些リソースを効率的に極限まで使い倒すか。その美学を体現したのがHTTP/2であり、1本の永続的TCPコネクション上で無数のリクエストとレスポンスを並列処理する「ストリーム多重化（Multiplexing）」は、まさにモダンダウンロードの歴史を塗り替えた発明だった。
しかし、コインの裏表のように、高度な効率化は新たな脆弱性を生む。HTTP/1.1時代に猛威を振るったホリブロッカー（Head-of-Line Blocking）を粉砕したその仕組みは、悪意ある攻撃者にとって「サーバーの喉元に突きつけられた無数の刃」に変貌し得る。
今回は、HTTP/2の心臓部であるストリーム多重化のパケットレベルでの挙動から、それが孕む致命的な脆弱性、そして現場のアーキテクトが講じるべき実践的な防衛策まで、深く潜り込んでいこう。
—
1. パケットレベルで見るHTTP/2：バイナリフレーミングとストリームの躍動
HTTP/1.1のテキストベースのやり取り（`GET / HTTP/1.1\r\n…`）から、HTTP/2は完全にバイナリへと移行した。この変更は単なるパケットサイズの削減ではない。TCPのバイトストリームという「単一の巨大な管」の内部に、論理的な仮想チャネルである「ストリーム（Stream）」を縦横無尽に多重化するためのパラダイムシフトなのだ。
通信の最小単位は「フレーム（Frame）」であり、すべてのフレームは一律9バイトのヘッダーを持つ。
+———————————————–+
| Length (24) |
+—————+—————+—————+
| Type (8) | Flags (8) |
+-+————-+—————+——————————-+
|R| Stream Identifier (31) |
+-+————————————————————-<
| Payload Data... |
+---------------------------------------------------------------+
この31ビットの「Stream Identifier（ストリームID）」こそが肝だ。クライアントが生成するストリームIDは奇数（1, 3, 5...）、サーバー側は偶数（2, 4, 6...）を使用するという厳格なルールがある。これにより、1本のTLS化されたTCPコネクション（通常はTLS 1.3上で動く）の上で、数千のリクエストが互いにブロックし合うことなく、パケットの断片（`DATA`フレームや`HEADERS`フレーム）としてインターリーブ（混在）しながら流れていく。
この洗練された世界では、RTT（Round Trip Time）の呪縛は大幅に軽減される。TLS 1.3の「1-RTTハンドシェイク（場合によっては0-RTT）」を完了させれば、即座に何百ものストリームを同時にオープンし、アトミックなデータの奔流を作り出すことができるのだ。
---
2. 光の裏側の影：ストリーム多重化攻撃（Stream Multiplexing Attacks）のメカニズム
しかし、この「並列性の追求」が、そのままサーバー側の致命的なアキレス腱になる。
HTTP/2の仕様では、クライアントは理論上、同時に何百万ものストリームを開くことができる。攻撃者はこの仕様を逆手に取り、次のような手口でサーバーを沈黙に追い込む。
1. 一斉オープン（Stream Flooding）：
悪意あるクライアントが、1本のTCPコネクション上で数千から数万もの `HEADERS` フレームを送信し、それぞれに異なる奇数のストリームIDを割り当てる。
2. リソースの漸進的枯渇：
サーバー側は、新しいストリームを受け入れるたびに、状態管理用のメモリ（Stream State Machine）を割り当て、HPACKコンテキストの維持や、リクエストを処理するための内部構造体を生成しなければならない。
3. リセットの嵐（RST_STREAM Abuse / Rapid Reset Attack）：
さらに悪質なケース（近年発見されたCVE-2023-44487など）では、クライアントがリクエストの送信直後に `RST_STREAM` フレームを送り、ストリームを即座にキャンセルする。しかし、サーバー側はキャンセルを処理するまでにすでにCPUとメモリを消費しており、これが秒間何万回も繰り返されることで、CPU使用率が100%に張り付き、正当なユーザーのトラフィックが一切処理できなくなる（Denial of Service）。
ここで重要なのは、レイヤーのミスマッチだ。TCP層から見れば、接続は健全に生きており、輻輳制御ウィンドウ（cwnd）も開いている。TLS層からも、正当な暗号化通信が行われているように見える。しかし、そのアプリケーション層（HTTP/2層）の内部では、見えないリソースのゾンビたちがサーバーのメモリを食い潰しているのだ。
—
3. 防衛の要：SETTINGSフレームによる「合意形成」とレートリミット
この脅威に対抗するためには、HTTP/2プロトコルの仕様に組み込まれた防衛機構を正しく理解し、Webサーバー（Nginx, Envoy, Apacheなど）のパラメータを適切にチューニングする必要がある。
SETTINGS_MAX_CONCURRENT_STREAMS の厳格な管理
HTTP/2のネゴシエーション時、サーバーは `SETTINGS` フレームを通じて、1つのコネクションあたりに許可する最大同時ストリーム数（`SETTINGS_MAX_CONCURRENT_STREAMS`）をクライアントに通知する。
デフォルト値が無制限、あるいは非常に大きく設定されているサーバーは、攻撃者にとって格好のターゲットとなる。この値を適切に絞ることが、最初の防衛ラインとなる。
以下に、高負荷環境とセキュリティのバランスを取った Nginx の設定例を示す。
http {
# HTTP/2 の有効化
listen 443 ssl http2;
# 1つのコネクションあたりに許可する最大同時ストリーム数を厳しく制限
# デフォルトは無制限に近い値だが、実用上、通常は 100〜250 程度が妥当
http2_max_concurrent_streams 128;
# ヘッダーの最大サイズを制限し、HPACK爆弾（Huge Headers）を防ぐ
http2_max_header_size 16k;
# 1つのコネクション内で処理できる最大リクエスト数を制限し、コネクションの寿命を管理
keepalive_requests 1000;
# アイドルタイムアウトを短く設定し、放置されたストリームやコネクションを切断
keepalive_timeout 65;
}
Envoy Proxy における高度なレートリミットとサーキットブレーカー
モダンなマイクロサービスアーキテクチャの境界（エッジ）を担う Envoy Proxy では、よりきめ細やかなストリーム制御が可能だ。Envoyのルーティング設定やクラスター設定では、アクティブなストリーム数に対するサーキットブレーカー（Circuit Breaker）を明示的に設定できる。
Envoyのクラスタ設定におけるリソース制限の例
resources:
- max_connections: 10000 # 最大TCPコネクション数
max_pending_requests: 1000 # キューイングされる最大リクエスト数
max_requests: 10000 # 同時最大リクエスト（ストリーム）数
max_retries: 3 # 最大リトライ数
さらに、HTTP/2のレイヤーにおいて、異常な頻度で `RST_STREAM` を送信するクライアントを検知し、即座にTCPコネクションを切断するメカニズム（CVE-2023-44487のパッチで導入されたような動的レートリミット）を適用することが、現在のインフラ運用の必須条件となっている。
—
4. トランスポート層とTLSの最適化：根本的なパフォーマンスの担保
ストリーム多重化攻撃を防ぐためにセキュリティを厳しくしすぎると、今度は通常の正当なユーザーのパフォーマンスが犠牲になるというジレンマに陥る。ここで、TCPバッファチューニングとTLSハンドショイクの最適化が重要になってくる。
HTTP/2は1本のTCPコネクションに依存するため、そのコネクションでパケットロスが発生すると、「TCPのヘッド・オブ・ライン・ブロック（HOLB）」が発生し、その上で動いているすべてのストリームが一時停止する。
これを最小限に抑えるためには、Linuxカーネルパラメータのチューニングが欠かせない。
/etc/sysctl.conf におけるネットワークスタックの極限チューニング
BBR輻輳制御アルゴリズムの有効化（パケットロスに強く、高スループットを実現）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
TCP受信/送信バッファの動的チューニング範囲を拡大（大帯域・高遅延回線対策）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
ウィンドウのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1
TIME_WAIT ソケットの再利用を許可し、高負荷時のポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
これらのカーネルチューニングと、前述したHTTP/2レベルの `SETTINGS_MAX_CONCURRENT_STREAMS` の適切な制御を組み合わせることで、「攻撃者からのリソース枯渇を防ぎつつ、正当なユーザーには最大限のマルチプレクシングの恩恵を提供する」という、アーキテクトが目指すべき理想的な状態を構築できる。
—
結びにかえて：プロトコルの深淵を見据えるエンジニアリング
HTTP/2のストリーム多重化は、ネットワークの効率を極限まで高めた美しい仕組みである。しかし、効率の追求は常に複雑性を伴い、複雑性は脆弱性の温床となる。
パケットがNICを叩き、TLSの暗号通貨がほどかれ、バイナリフレームがパーサによってストリームに分解される――その一連のライフサイクルを頭の中でリアルタイムにトレースできるかどうかが、単なる「設定ファイル職人」と、真の「ネットワークアーキテクト」を分ける境界線だ。
脆弱性は恐れるものではない。そのメカニズムをパケットレベルで理解し、適切なパラメータとアーキテクチャによって手なずけることこそが、我々インフラエンジニアの醍醐味なのである。
コメント