【入門編】HTTP/2におけるサーバーサイド同時接続数制限の設計指針 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。インフラエンジニアの主筆ライターとして、日夜パケットたちのドラマを追いかけている私です。

Webサイトをブラウザで表示したとき、画像やスタイルシート、JavaScriptといったたくさんのファイルが、まるで魔法のように一瞬で読み込まれるようになりましたよね。これはひとえに、現代のWebを支える「HTTP/2」という次世代の通信規格のおかげです。

HTTP/2の最大の魅力は、なんといっても「マルチプレクシング（多重化）」という技術。昔のHTTP/1.1では、まるで一本の狭い一本橋を渡るように、ファイル一つひとつを順番待ちしながらやり取りしていましたが、HTTP/2では一本の太いパイプライン（TCPコネクション）の中で、複数の荷物（ストリーム）を同時に行き交わせることができるようになりました。

「じゃあ、どれだけでも同時に荷物を送っていいの？」

ここで気になってくるのが、今回のテーマである「サーバーサイドの同時接続数制限（最大同時ストリーム数）」です。サーバーがパンクしないための「入場制限」の仕組みと、そのスマートな設計指針について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！

—

郵便局の窓口と「受け入れ制限」の物語

HTTP/2のマルチプレクシングをイメージするために、街の大きな郵便局を想像してみてください。

あなた（クライアント）は、その郵便局（サーバー）に対して「このWebサイトに必要な50個の荷物を全部同時に配達して！」とお願いしました。HTTP/1.1の時代なら、窓口を50個も開けたり、50人が順番に並び直したりと大騒ぎでしたが、HTTP/2の世界では、「めちゃくちゃ広い一つの専用レーン」を使って、50個の小包を同時にやり取りします。

ここで郵便局長の気持ちになってみましょう。
もし、世界中からやってくる何万人ものお客さんが、一斉に「私専用のレーンで同時に100個の荷物を送れ！」と言ってきたらどうなるでしょうか？

郵便局の裏側にある仕分けロボットは熱を帯び、作業員は倒れ、最終的には郵便局全体がシステムダウンしてしまいますよね。

そこでサーバー側には、「一度に処理できる荷物の数（ストリーム数）は、お一人様ここまでですよ」とあらかじめ決めておく安全装置が用意されています。これが、設定値である `SETTINGS_MAX_CONCURRENT_STREAMS`（最大同時ストリーム数）の正体です。

—

`SETTINGS_MAX_CONCURRENT_STREAMS` ってどんな仕組み？

HTTP/2の通信が始まるとき、サーバーとクライアントは最初に「お互いのルール確認（SETTINGSフレームの交換）」を行います。その際、サーバーがクライアントに対して、

> 「うちのサーバー、ちょっと今忙しいから、一つの通信レーンの中で同時にやり取りできる荷物（ストリーム）は最大で100個までにしてね！」

とこっそり伝えるのが、この設定の役割です。

クライアント（ブラウザなど）はこの約束を守り、同時にリクエストを送る数が100個に達したら、101個目以降のリクエストは心の中で「ちょっと待っててね」と列を作って待機させます。サーバーが前の荷物を片付け、「空いたよ！」と合図を送ると、次の荷物を流し始めるのです。

—

現場で悩む「適切な設定値」のジレンマ

インフラエンジニアとしてサーバーを構築する際、この最大同時ストリーム数をいくつに設定すべきか、頭を悩ませるポイントになります。

数を大きくしすぎた場合（例：1000など）
メリット：クライアントが大量のファイルを一気に要求できるため、体感スピードが上がるように感じます。
デメリット：悪意あるユーザーや、大量のアクセスが来たときにサーバーのメモリやCPUが一気に枯渇し、サーバーがダウン（DDoS状態）します。
数を小さくしすぎた場合（例：10など）
メリット：サーバーの安全は絶対に守られます。
デメリット：最近のWebサイトは1ページ表示するだけで画像やスクリプトが100個を超えることも珍しくありません。「順番待ち」の時間が長くなり、かえってサイトの表示が遅くなってしまいます。

黄金比はどこにある？

一般的なWebアプリケーションサーバー（NginxやApache、Node.jsなど）やリバースプロキシでは、デフォルト値として `100` もしくは `128` が設定されていることがほとんどです。

実務の現場では、このデフォルト値を出発点としつつ、次のような指針でチューニングを行います。

1. サーバーのスペック（CPU・メモリ）と相談する

リクエストごとにデータベースへ重い問い合わせをするAPIサーバーなら、小さめ（50〜100）に絞ってサーバーを守ります。
静的な画像やHTMLを配るだけのCDNやリバースプロキシなら、少し大きめ（128〜250）に設定しても耐えられます。

2. クライアント側の負荷分散・制御を知る

現代のモダンなブラウザは、同一ドメインに対するHTTP/2の同時ストリーム数を自発的に制御しています。サーバー側が「1000OKだよ」と言っても、ブラウザ側が勝手に「いや、うちは安全のために100個くらいにしておこう」と自制してくれたりします。

—

設定ファイル（Nginx）を覗いてみよう

百聞は一見にしかず。実際のWebサーバー（Nginx）の設定ファイルで、この値がどのように扱われているか見てみましょう。実務の現場でそのままコピー＆ペーストして、コメントを参考に調整してみてください。

server {
listen 443 ssl http2;
server_name example.com;

# SSL証明書などの設定は省略…

# ==========================================
# HTTP/2 の詳細チューニング設定
# ==========================================

# 1つのTCPコネクション上で同時に処理できる最大ストリーム数を指定します。
# サーバーリソース（メモリ）を守るため、デフォルトの128から、
# アプリケーションの負荷に合わせて調整します。
http2_max_concurrent_streams 128;

# クライアントから受け付けるウィンドウサイズ（一度に送れるデータ量）の初期値
http2_window_size 256k;

location / {
proxy_pass http://my_backend_application;

# バックエンドへの負荷を考慮したプロキシ設定
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}

このように、一行の設定を適切に施すだけで、トラフィックの急増によるサーバーの突然死を防ぎ、安定したパフォーマンスを維持することができるのです。

—

まとめ：ネットワークの調和をデザインする

HTTP/2のマルチプレクシングと最大同時ストリーム数の制限は、いわば「効率」と「安全性」のバランスを取るダンスのようなものです。

すべてを自由に同時並行で処理できれば理想的ですが、現実世界のリソース（サーバーのメモリやCPU）には必ず限界があります。だからこそ、ネットワークアーキテクトやインフラエンジニアは、この「制限のルール（SETTINGS_MAX_CONCURRENT_STREAMS）」を上手に設計し、ユーザーには快適なスピードを、サーバーには確かな安心を届ける必要があるのです。

「なぜこの設定値になっているんだろう？」
次にWebサイトを構築したり、ブラウザの開発者ツールでネットワークタブを覗いたりするとき、今回の郵便局の例えを思い出してもらえたらとても嬉しいです。

それでは、また次回のインフラ探訪でお会いしましょう！