HTTP/2マルチプレクシングの牙城を守る：`SETTINGS_MAX_CONCURRENT_STREAMS`の極限チューニングと設計指針
ネットワークエンジニアリングの醍醐味は、論理的なプロトコルの仕様が、物理的な電気信号や光パケット、そしてOSカーネルのメモリ空間とどのように交錯しているかを解き明かすことにある。
HTTP/1.1の「1コネクション＝1リクエスト」という呪縛を打ち破り、単一のTCPコネクション上で無数のリクエストとレスポンスを並行して流し込むHTTP/2は、まさに現代Webインフラの高速化の立役者だ。しかし、この「マルチプレクシング（多重化）」という圧倒的なパワーは、適切なリミッターが効いていない場合、サーバーサイドへのDDoS攻撃や、カーネルメモリの枯渇を引き起こす両刃の剣となる。
今回は、HTTP/2の根幹を支える「ストリーム」の概念と、サーバー保護の要である `SETTINGS_MAX_CONCURRENT_STREAMS` の設計指針について、パケットレベルの挙動からLinuxカーネルのチューニングまで、徹底的に深掘りしていこう。
—
1. パケットレベルで見るHTTP/2ストリームとマルチプレクシングの現実
HTTP/2の通信は、すべて単一のTCPコネクション上で確立されたバイナリフレームのやり取りによって成り立っている。TCPの上位に独自の仮想的なチャネルである「ストリーム」を構築し、それぞれのストリームには奇数（クライアント起因）のストリームIDが付与される。
ここで注意しなければならないのは、「HTTP/2はアプリケーション層のマルチプレクシングであアり、トランスポート層（TCP）の制約からは逃れられない」という冷徹な事実だ。
[ Client ] [ Server / Nginx / Envoy ]
| |
|— HEADERS (Stream 1) ——————————>|
|— HEADERS (Stream 3) ——————————>|
|— HEADERS (Stream 5) ——————————>|
| |
| (単一のTCPウィンドウと輻輳制御の枠内で競合) |
クライアントが何百というアセット（画像、JS、CSS）を並行して要求するために、何百ものストリームを同時にオープンしたとする。しかし、これらすべてのストリームは、たった1つのTCPウィンドウと輻輳制御アルゴリズム（CUBICやBBRなど）を共有している。
もし回線上のどこかでパケットロスが発生すると、TCP層では再送制御（Retransmission）のために対抗パケットの到着を待つ（HOLブロッキング）。結果として、TCPセグメントがロスした瞬間、その上で多重化されているすべてのHTTP/2ストリームが一時停止を強いられることになる。HTTP/2はアプリケーション層でのHOLブロッキングを解消したが、トランスポート層のHOLブロッキングからは逃れられない――このアーキテクチャ上のトレードオフを常に念頭に置く必要がある。
—
2. `SETTINGS_MAX_CONCURRENT_STREAMS` の正体と安全なデフォルト値
クライアントが無制限にストリームを作成し、サーバーにリクエストを送りつけたらどうなるか。サーバーのメモリは瞬く間に枯渇し、リクエストのキューイング処理でCPUキャッシュはヒット率を落とし、最終的にはOOM Killerの餌食になるか、サービスが完全停止する。
これを防ぐための防壁が、HTTP/2の接続確立時に交わされるセッティングフレームの1つ、`SETTINGS_MAX_CONCURRENT_STREAMS` である。
なぜデフォルト値「無制限（あるいは極端に大きな値）」が危険なのか
多くのHTTP/2実装（Nginx, Envoy, Apacheなど）のデフォルト、あるいはRFC 7540の仕様上、明示的に制限をかけない場合、クライアントは理論上数百万もの同時ストリームを開くことが可能になる。悪意あるクライアントがこれを利用し、意図的にレスポンスを返さない重いリクエストを何千も同時発行した場合、サーバーのリソースは容易に食い潰される（これが有名なHTTP/2 Rapid Reset攻撃などの土壌ともなった）。
推奨される設定値の設計指針
実務において、この値は「クライアントの利便性（UX）」と「サーバーの防衛」の絶妙なバランスの上に成り立たなければならない。
- 一般的なWebアプリケーション（B2C、メディア等）: `100` 〜 `250`
- APIサーバー（マイクロサービス間通信・gRPC等）: `50` 〜 `128`
- 高トラフィック・高同時接続をさばくエッジプロキシ: `128` 〜 `500`（※バックエンドのキャパシティに直結）
一般的に、現代のブラウザは1つのオリジンに対して同時接続するTCPコネクション数を制限しつつ、その中でHTTP/2のストリームを最大化する。実測値として、通常のWeb閲覧においてブラウザが同時にアクティブ化するストリーム数はせいぜい数十程度であることが多い。したがって、`100` または `128` という値は、パフォーマンスを犠牲にせずにリソースを守るための「黄金比」と言える。
—
3. Webサーバー（Nginx / Envoy）での具体的な設定実装
それでは、実際のプロダクション環境でどのようにこの制限をかけ、チューニングすべきか。代表的なプロキシである Nginx と Envoy の設定例を見ていこう。
Nginx における設定例
Nginxでは、`http`、`server`、または `location` コンテキストにおいて、`http2_max_concurrent_streams` ディレクティブで制御する（※近年のNginxバージョンでは `http2` モジュールが統合・最適化されている）。
http {
# HTTP/2の設定ブロック
# 1つのコネクションあたり同時に処理するストリーム数を128に制限し、
# 悪意ある大量ストリームオープンによるメモリ枯渇を防ぐ
http2_max_concurrent_streams 128;
# クライアントからのリクエストボディのバッファサイズ
client_body_buffer_size 16k;
client_max_body_size 10m;
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /path/to_cert.pem;
ssl_certificate_key /path/to_key.pem;
# 高度なセキュリティのためのTLS設定（TLS 1.3推奨）
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://backend_cluster;
proxy_http_version 1.1;
# バックエンドへは必要に応じてコネクションプーリングを活用
}
}
}
Envoy Proxy における設定例
マイクロサービスアーキテクチャの境界で圧倒的なシェアを誇る Envoy の場合、`HttpConnectionManager` の設定内で厳密に制御する。
static_resources:
listeners:
- name: ingress_listener
address:
socket_address:
address: 0.0.0.0
port_value: 443
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: [“”]
routes:
- match:
prefix: “/”
route:
cluster: backend_service
http2_protocol_options:
# 最大同時ストリーム数を100に厳格に制限
max_concurrent_streams: 100
# 初期ウィンドウサイズの調整（スループット最適化）
initial_stream_window_size: 65535 # 64KB
initial_connection_window_size: 1048576 # 1MB
—
4. トランスポート層（TLS/TCP）の最適化とカーネルパラメータの調律
HTTP/2のパフォーマンスは、アプリケーション層の設定だけで決まるものではない。土台であるTCPとTLSのハンドシェイク、そしてLinuxカーネルのバッファチューニングが三位一体となって初めて真価を発揮する。
1. TLS 1.3 によるハンドシェイクの極限短縮
HTTP/2は実質的にTLS（HTTPS）上でのみ実装される（H2Cを除く）。従来のTLS 1.2では2-RTTを要していたハンドシェイクが、TLS 1.3では1-RTT（さらに事前共有鍵があれば0-RTT）に短縮される。これにより、最初のTCPパケット送信からわずか数ミリ秒でHTTP/2のSETTINGSフレーム交換に到達できる。
2. Linuxカーネルパラメータ（sysctl）のチューニング
大量の並行ストリームを捌くということは、それだけソケットバッファやファイルディスクリプタを消費するということだ。`/etc/sysctl.conf` において、以下のパラメータを適切にチューニングしておく必要がある。
— TCPメモリおよびバッファの動的チューニング —
TCP送受信バッファの最小値、デフォルト値、最大値（バイト単位）
高速なネットワーク環境下でスループットを最大化する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
TIME_WAITソケットの再利用を許可し、ポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
SYNバックログキューのサイズを拡大し、DDoSやフラッド攻撃に備える
net.ipv4.tcp_max_syn_backlog = 8192
接続要求キュー（Listen queue）の最大長を設定
net.core.somaxconn = 8192
BBR輻輳制御アルゴリズムの有効化（パケットロスに強く、高スループットを実現）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
これらのカーネルチューニングを行うことで、HTTP/2のマルチプレクシングによって発生する無数の並行リクエストの波を、カーネルレベルでスムーズに裁くことが可能になる。
—
5. クライアント側の負荷分散・接続管理戦略
サーバーサイドがどれほど強固に `SETTINGS_MAX_CONCURRENT_STREAMS` を絞っていたとしても、クライアント側（APIクライアント、フロントエンド、マイクロサービスの呼び出し元）がその制限を無視して突撃すれば、サーバーから `RST_STREAM`（エラーコード: `REFUSED_STREAM`）の嵐を食らい、システム全体のスループットが著しく低下する。
クライアントアーキテクチャ設計における鉄則は以下の通りだ。
1. コネクションプーリングと共有:
同一オリジンに対するHTTP/2コネクションは原則として1つ（必要に応じて数個）に絞り、その上で全てのストリームを多重化させる。コネクションを無闇に増やすのはHTTP/2のメリットを相殺する。
2. キューイングとフロー制御の理解:
`SETTINGS_MAX_CONCURRENT_STREAMS` の上限に達したクライアント側のライブラリは、新たなリクエストをローカルのキューで待機させる必要がある。このキューイング機構が適切に実装されていないクライアントは、エラーハンドリングで破綻する。
3. `REFUSED_STREAM` の検知とリトライロジック:
サーバーが負荷耐性のためにストリームを拒否した場合、HTTP/2プロトコル上では `REFUSED_STREAM` が返される。クライアント側（特にgRPCや高度なAPIクライアント）では、このエラーを受け取った際に安全に別のコネクションにフォールバック、あるいは指数バックオフ（Exponential Backoff）を伴うリトライを行う設計が不可欠である。
—
結びにかえて：インフラストラクチャの美学
HTTP/2のマルチプレクシングと `SETTINGS_MAX_CONCURRENT_STREAMS` の設計は、単なる「設定値の調整」ではない。それは、クライアントの利便性とサーバーのリソース防衛という、常に相反する二つの力学の均衡点を見つけ出す、インフラアーキテクトの腕の見せ所である。
パケットがNICを叩き、TLSで復号され、カーネルのバッファを通過し、HTTP/2のストリームとして美しく調律されていく。その一連のライフサイクル全体を見通したとき、ネットワークは単なる配管ではなく、生き物のような複雑さと美しさを持つシステムとして立ち現れてくる。
今日の設計が、明日の安定稼働を支える。ぜひ手元の環境で、現在の `max_concurrent_streams` の値とカーネルパラメータを見直し、真に強靭なHTTP/2インフラストラクチャを構築してほしい。
コメント