こんにちは！ネットワークやインフラストラクチャの世界へようこそ。
日頃何気なく使っているWebブラウザですが、URLを入力してからページが表示されるまでの裏側では、目にも留まらぬ速さでさまざまなデータ（パケット）が飛び交っています。その主役である「HTTPプロトコル」は、私たちのWeb体験を支える超重要インフラですよね。
今回は、現代の高速なWebを支える「HTTP/2」の、ちょっとマニアックだけど実はとっても身近なテーマ「クライアント側の同時ストリーム数制限の挙動」について、一緒に紐解いていきましょう！
「なんだか難しそうな用語が出てきたな……」と思った方も、どうぞご安心ください。一歩ずつ、現実世界のたとえ話を交えながら優しく解説していきますね。
—
1. HTTP/2ってどんな仕組み？（郵便配達でたとえてみよう）
前世代の「HTTP/1.1」まで、Webブラウザとサーバーのやり取りは、まるで「1人しかいない真面目な郵便配達員」のようでした。
彼（HTTP/1.1）は、手紙（画像やCSS、JavaScriptなどのファイル）を1通持って配達に行き、それが相手に届いて返事をもらうまで、次の手紙を持てない仕組みになっていました。そのため、ページの中にたくさんファイルがあると、配達員が大渋滞を起こしてしまっていたんです。
そこで登場したのが「HTTP/2」です。
HTTP/2は、この配達員を「超高速なバイクに乗った分身の術が使える配達員」に進化させました。
このHTTP/2の技術の核心が「マルチプレクシング（多重化）」です。1本の太い道路（TCPコネクション）のうえに、仮想的なレーン（これをストリームと呼びます）を何本も並行して作り、一つの通信路で同時にいくつものファイルをやり取りできるようになりました。
—
2. 「ストリーム数制限」って、いったいなに？
分身の術を使って何でも同時に運べるようになったHTTP/2ですが、ここで一つ問題が起きます。
もし、サーバー側が「同時に1,000個もファイルを持ってこないでよ！パンクしちゃうよ！」と困ってしまったらどうでしょう？あるいは、逆にクライアント側がサーバーの許容量を無視して無茶な数のリクエストを送りつけたら……？
そこでHTTP/2では、お互いが「同時に処理できるストリーム（レーン）の数には上限を設けましょうね」というルールを取り決められるようになっています。
今回注目するテーマは、「クライアント（ブラウザなど）がサーバーに対して設定する最大ストリーム数の意味」と、「それをサーバー側が超過してしまった場合の挙動」です。
設定の名前は `SETTINGS_MAX_CONCURRENT_STREAMS`
エンジニアの世界では、この「同時に持てるストリームの最大数」を、設定パラメータ名で `SETTINGS_MAX_CONCURRENT_STREAMS` と呼びます。
今回は「クライアント側がこの制限をどう管理するか」という視点に立ってみましょう。
例えば、あなたが開発している自作のHTTP/2クライアントツールや、特定のプロキシサーバーでこの値をコントロールする場面を想像してください。
—
3. 実際のコードとパラメーター設定を覗いてみよう
現代のネットワーク開発では、HTTP/2を扱うために様々なライブラリが使われます。例えば、Node.jsやGo言語、あるいはNginxなどの設定ファイルで、このストリーム数を意識することがあります。
ここでは、HTTP/2の通信を制御する際のイメージとして、設定値を扱うコードの断片を見てみましょう（今回はJavaScript / Node.jsの `http2` モジュールをベースにした、分かりやすいサンプルを用意しました）。
const http2 = require(‘http2’);
// クライアントとしてHTTP/2サーバーに接続します
const client = http2.connect(‘https://example.com’);
client.on(‘connect’, (session) => {
// サーバー側が許可している「最大同時ストリーム数」をリモート設定から取得できます
const remoteSettings = session.remoteSettings;
console.log(`サーバーが許可する最大ストリーム数: ${remoteSettings.maxConcurrentStreams}`);
});
// 同時に複数のリクエスト（ストリーム）を生成して送信する処理
function sendMultipleRequests(clientSession) {
// 例として、同時に100個の画像データを取得しにいこうとする試み
for (let i = 1; i <= 100; i++) {
const req = clientSession.path(`
// 各リクエストはそれぞれ独立した「ストリーム」として流れます
req.on('response', (headers, flags) => {
console.log(`ストリーム ${i}: レスポンスを受信しました`);
});
req.on(‘end’, () => {
// 通信が終わると、ストリームは綺麗に消滅します
});
req.end();
}
}
このように、私たちはコード上や設定ファイル一つで、大量のストリームを同時に開くことができます。しかし、ここでサーバー側のキャパシティを超えるような制限の壁にぶつかることがあるのです。
—
4. 制限を超過したとき、ネットワークの裏側では何が起きているのか？
もし、クライアント側（またはサーバー側）が設定された最大同時ストリーム数を超えて、新しいリクエストのストリームを作ろうとしたらどうなるのでしょうか？
ここでパケットの世界のルールが登場します。
1. ルールの超過検知:
サーバー側（あるいはクライアント側）は、現在オープンになっているストリームの数を常に数えています。もし許可された上限（例: 100）を超えて新しいストリームIDを開こうとするリクエストを受信した場合、受信側は「おいおい、ルール違反だよ！」と判断します。
2. RST_STREAM（強制終了）のシグナル:
ルール違反を犯したストリームに対して、受信側は「RST_STREAM（リセット・ストリーム）」という特殊な制御フレームを相手に送り返します。エラーコードとしては `REFUSED_STREAM`（ストリームが拒否された）などが通知されます。
3. 該当ストリームだけの切断:
ここで面白い（そして優秀な）ポイントは、「ルールを超えたその特定のストリームだけが強制終了される」という点です。大元の太い道路（TCPコネクション）ごとプッツリ切断されるわけではなく、他の正常に動いているストリーム（他の画像のダウンロードなど）には影響を与えません。
身の回りのたとえで言うなら、銀行の窓口（ストリーム）が同時に10個までしか開いていないのに、11番目の人が無理やり割り込んできたため、「申し訳ありませんが、こちらの窓口業務は一度キャンセルさせていただきます。次の空きをお待ちください」と案内されるようなイメージです。
—
5. 実務やトラブルシューティングでの活かし方
インフラエンジニアやWebアプリケーション開発者にとって、この挙動を知っていることは大きな武器になります。
- 「なんだかページの読み込みが途中で止まる、あるいは遅い」というトラブルに直面したとき、ブラウザの開発者ツール（ネットワークタブ）やパケットキャプチャツール（Wiresharkなど）で `RST_STREAM` が頻発していないかを確認する手がかりになります。
- マイクロサービスアーキテクチャなどで、1つのクライアントからバックエンドのAPIサーバーへ過剰な並列リクエストを送っている場合、この制限値（`SETTINGS_MAX_CONCURRENT_STREAMS`）のチューニングが必要になるケースがあります。サーバーとクライアントのバランスを適切に設計することが、安定したWebインフラ構築の秘訣です。
—
まとめ
いかがでしたでしょうか？
HTTP/2の「クライアント側の同時ストリーム数制限」は、一見すると無機質なプロトコル仕様の数字に見えますが、実態は「お互いのシステムがパンクしないように優しくブレーキをかけ合うための、洗練された交通ルール」そのものです。
ネットワークやインフラの世界は、こうした「お互いが気持ちよく通信するための工夫」の積み重ねでできています。
今回の解説が、あなたの毎日の開発やインフラ学習の小さなヒントになれば、ライターとしてこれ以上の喜びはありません。
それでは、また次回の技術探訪でお会いしましょう！
コメント