HTTP/2の美学：RST_STREAMが救うコネクションの命と、パケットの裏側でうごめくトランスポートの現実
ウェブの高速化を追求するアーキテクトやテックリードであれば、HTTP/1.1の「Head-of-Line（HoL）ブロック」という悪夢から私たちを救い出したHTTP/2のマルチプレクシング（多重化）に、一度は魅了されたことがあるはずだ。1本の単一TCPコネクション上で、無数のストリームが並行して疾走する。その光景は、あたかも寸分の狂いもなく制御された超高層ビルのエレベーターシャフトのようであり、美しさすら感じさせる。
しかし、現実は美しい仕様書通りには動かない。
非同期でリクエストが飛び交う世界では、「ある特定のストリームの処理が破綻した」「クライアントが突如として画像データのダウンロードをキャンセルした」「不正なデータが送りつけられてきた」といった例外事態が常に発生する。ここでHTTP/1.1の感覚のままコネクション全体を切断していたのでは、せっかくTLSハンドシェイクを終え、TCPスロースタートを抜けて爆速で流れている他の健全なストリームまで巻き添えにしてしまう。
そこで登場するのが、今回の主役である `RST_STREAM`（フレームタイプ: `0x3`） だ。
今回は、この小さな、しかし極めて強力なフレームが、パケットレベルでどのようにコネクションを救い、TLSやTCPのバッファチューニング、そしてセキュリティの要塞においてどのような役割を果たしているのか。プロトコルの深層へ深く潜ってみよう。
—
1. マルチプレクシングの光と影：なぜ `RST_STREAM` が必要なのか
HTTP/2の基本単位は「フレーム」であり、複数のフレームがインターリーブ（織り交ぜ）されて1本のTCPコネクションを流れる。この多重化の恩恵により、ブラウザは1つのオリジンに対して無数のリクエストを同時に並行処理できるようになった。
しかし、ここにジレンマがある。TCPはバイトストリーム指向の信頼性プロトコルであり、カーネルのソケットバッファレベルでは「ただの連続したデータ」として扱われる。HTTP/2レイヤーは、その中に仮想的な「ストリーム（Stream ID）」という概念を構築し、論理的な境界線を引き直しているに過ぎない。
ここで想像してほしい。
あるストリーム（例えば Stream ID: 3）で巨大な動画ファイルをダウンロードしている最中、ユーザーがそのタブを急に閉じたとする。あるいは、バックエンドのデータベースがタイムアウトを起こし、そのレスポンス生成が不可能になったとする。
もし `RST_STREAM` が存在しなかったらどうなるか？
クライアントまたはサーバーは、すでに送信中あるいは送信予定のデータを無視する術を持たない。コネクション全体を `GOAWAY` でブツ切りにするか、無駄なデータを最後まで受信し続けるしかなく、貴重な帯域とCPUリソースがドブに捨てられることになる。
`RST_STREAM` のパケット構造と挙動
`RST_STREAM` フレームは、ペイロードとして「32ビットのエラーコード」を伴う。その構造は極めてシンプルだ。
+—————————————————————+
| Length (24) |
+——————————-+—————+—————+
| Type (8) | Flags (8) |
+-+—————————–+——————————-+
|R| Stream Identifier (31) |
+=+============================================================+
| ErrorCode (32) |
+—————————————————————+
このフレームが特定のストリーム識別子（Stream Identifier）と共に送出された瞬間、送信側と受信側の双方向において、その特定のストリームだけが即座に「Closed」状態へと遷移する。他のストリーム（例えば、同じコネクション上で動いているAPI通信やCSSの取得）は、微塵も影響を受けることなく、何食わぬ顔でパケットを流し続ける。これが `RST_STREAM` の真骨頂だ。
—
2. 現場を救うエラーコードの知見：どのエラーでどう振る舞うべきか
RFC 7540（および後継のRFC 9113）では、`RST_STREAM` や `GOAWAY` で使用される標準的なエラーコードが定義されている。インフラエンジニアとして、ログやパケットキャプチャ（Wireshark等）でこれらのコードに直面した際、瞬時にその意味を理解できなければならない。
代表的なエラーコードをいくつかピックアップし、現場の文脈で読み解いてみよう。
| エラーコード | 名称 | 16進数表現 | 現場での実状とアーキテクチャ上の意味 |
| :— | :— | :— | :— |
| `0x0` | `NO_ERROR` | `0x00` | 正常終了。主にキャンセルに近い用途で使われる。 |
| `0x1` | `PROTOCOL_ERROR` | `0x01` | プロトコル違反。不正なフレームシーケンスを検知した場合。 |
| `0x2` | `INTERNAL_ERROR` | `0x02` | サーバー内部の予期せぬエラー（DB落ち、メモリ不足など）。 |
| `0x3` | `FLOW_CONTROL_ERROR`| `0x03` | フロー制御ウインドウの違反。実装のバグを疑うべき。 |
| `0x5` | `STREAM_CLOSED` | `0x05` | すでに閉じられたストリームに対するフレームを受信した。 |
| `0x8` | `CANCEL` | `0x08` | クライアントがリクエストを自発的に破棄した（タブ閉じなど）。 |
| `0xD` | `HTTP_1_1_REQUIRED` | `0x0D` | HTTP/2では処理できないため、HTTP/1.1へフォールバックを要求。 |
コード `CANCEL (0x08)` と `INTERNAL_ERROR (0x02)` の境界線
ウェブアプリケーションのデバッグをしていると、ブラウザから `RST_STREAM`（Error: `CANCEL`）が飛んでくる光景によく遭遇する。これは多くの場合、ユーザーの離脱（ページ遷移、キャンセルボタン押下）によるものであり、サーバー側としては「あ、もうあのレスポンス作らなくていいんだな」とハンドラーを即座にアボート（中断）させるシグナルとして利用できる。
逆に、サーバー側から `RST_STREAM`（Error: `INTERNAL_ERROR` または `CANCEL`）を返す場合、アプリケーションサーバーとリバースプロキシ（NginxやEnvoyなど）の連携ミスが隠れていることが多い。例えば、バックエンドからのレスポンスが遅すぎて、プロキシ側のタイムアウトが発動した瞬間、プロキシはバックエンドとのコネクションを切りつつ、クライアント（または上流）に向けて `RST_STREAM` を叩きつける。
—
3. トランスポート層とTLSの隠されたコスト、そして「HTTP/2 悪魔の証明」
ここで少しレイヤーを下げて、TCPおよびTLSの観点からHTTP/2の挙動を見てみよう。HTTP/2は「1本のコネクションを使い回す」ため、TCPハンドシェイクやTLSのフルハンドシェイク（およびALPNネゴシエーション）のオーバーヘッドを劇的に削減した。
しかし、この「1本化」は、同時にトランスポート層の制約をすべてのストリームが共有するという諸刃の剣でもある。
TCPヘッド・オブ・ライン・ブロック（HoLブロック）の呪縛
よく誤解されるが、HTTP/2は「アプリケーション層のマルチプレクシング」であって、TCPの「トランスポート層の順序保証・再送制御」を回避しているわけではない。
もしパケットロスが発生し、TCPのシーケンス番号の途中に「穴」が空いた場合、そのTCPセグメントが再送されて復旧するまでの間、そのTCPコネクション上を流れるすべてのHTTP/2ストリームが一時停止（ストール）する。
この状況下で `RST_STREAM` はどう動くか？
ロストしたパケットのせいでTCPバッファが詰まっている最中でも、アプリケーション層で「このストリームもういらないからキャンセルして」という `RST_STREAM` フレームを割り込ませることは論理的には可能である。しかし、肝心のTCP層がブロックされているため、その `RST_STREAM` フレーム自体もカーネルのソケットバッファの奥底で足止めを食らうことになる。
この限界こそが、のちにQUICプロトコル（HTTP/3）を生み出す最大の原動力となった。QUICはUDPベースであり、トランスポート層自体がストリーム単位の独立性を持っているため、あるストリームでパケットロスが起きても他のストリームは微動だにしない。
とはいえ、現代のインターネットインフラの大部分は依然としてTCP/TLS上のHTTP/2で動いており、この環境で極限のパフォーマンスを引き出すためには、カーネルパラメータのチューニングが不可欠となる。
—
4. 極限のパフォーマンスチューニング：Linuxカーネルとバッファ戦略
HTTP/2環境下におけるNginxやEnvoy、あるいはGo製カスタムサーバーのパフォーマンスは、LinuxカーネルのTCPスタック設定に深く依存している。特に `RST_STREAM` が飛び交うような高負荷・動的トラフィックの環境では、以下のチューニングが命綱となる。
カーネルパラメータの推奨設定（`/etc/sysctl.conf`）
— TCP窓とバッファの動的チューニング —
メモリプレッシャーを防ぎつつ、BDP (Bandwidth-Delay Product) を最大化
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
— TCPハイパーパラメータの最適化 —
TCP Window Scalingを有効化（広帯域・高遅延回線でのスループット維持）
net.ipv4.tcp_window_scaling = 1
TIME_WAITソケットの迅速な再利用（短命なコネクションが多い環境向け）
net.ipv4.tcp_tw_reuse = 1
輻輳制御アルゴリズムに BBR を採用
損失ベースのCUBICではなく、ボトルネック帯域とRTTを動的計測してパケットロスを防ぐ
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
なぜ BBR と HTTP/2 の相性が良いのか？
HTTP/2のマルチプレクシング環境では、1本のTCPパイプラインに大量のデータがミックスされて流れる。従来のCUBICアルゴリズムでは、パケットロスを「輻輳（混雑）」と誤認し、ウィンドウサイズを急激に絞ってしまう傾向があった。
BBR（Bottleneck Bandwidth and RTT）を導入することで、パケットロスに過剰反応せず、回線の真の限界までパイプラインを太く保つことができる。結果として、`RST_STREAM` によって無駄なトラフィックが即座に排除されたあとの空きスペースを、即座に健全なストリームのデータで埋め尽くすことが可能になるのだ。
—
5. セキュリティの防壁：リソース枯渇攻撃と `RST_STREAM` 洪水
プロトコルの仕様の隙をつく攻撃者にとって、HTTP/2はその複雑さゆえに格好のターゲットになり得る。その代表例が、CVE-2019-9511（Rapid Reset Attack）として知られる脆弱性だ。
「Rapid Reset Attack」のメカニズム
攻撃者は、HTTP/2のマルチプレクシングと `RST_STREAM` の仕組みを悪用する。
1. 膨大な数のストリームを同時にオープンし、リクエストを送信する。
2. サーバーがそのリクエストの処理（レスポンス生成の準備）を開始した直後、攻撃者は即座に `RST_STREAM`（Error: `CANCEL`）を送信してそのストリームを破棄する。
3. 攻撃者はこれを毎秒何千、何万回も繰り返す。
サーバー側は、「リクエストの受信・ストリームの作成・バックエンドへのルーティング・そして直後のアボート処理」というCPU負荷の高い一連のサイクルを無限に強制される。結果として、CPU使用率が100%に張り付き、正当なユーザーのリクエストが一切処理できなくなる（DoS状態）。
実務における防御策（リバースプロキシの設定）
この種の攻撃を防ぐため、Nginx、Envoy、Cloudflareなどのエッジプロキシでは、ストリームのキャンセル頻度やアクティブなストリーム数に対する厳格なレートリミット（流量制限）が実装されている。
例えば、Nginx（1.25.x以降、あるいは商用版）や最新のフロントエンドプロキシでは、以下のようなパラメータで異常な `RST_STREAM` の連打を検知・ブロックする。
http {
# HTTP/2接続あたりの同時オープン可能な最大ストリーム数を制限
# デフォルト無制限に近い状態を防ぎ、リソース枯渇を防止
http2_max_concurrent_streams 128;
# ウィンドウサイズやフレームサイズの上限を適切に絞る
http2_chunk_size 8k;
# 異常な頻度でRST_STREAMを送るクライアントを一時的にコネクション遮断する設定
# （※実装しているプロキシのディレクティブ仕様に依存しますが、概念としてのレートリミット）
# limit_req zone=h2_reset_zone burst=20 nodelay;
}
セキュリティ専門家やインフラエンジニアは、WAFやプロキシのログを監視し、「短時間に同一コネクションから異常な数の `RST_STREAM` が発生していないか」をメトリクスとして常時トラッキングしておく必要がある。
—
6. まとめ：パケットの流れる音を聴け
HTTP/2の `RST_STREAM` は、一見すると単なる「エラー通知用の小さなパケット」にすぎない。しかし、その内部挙動を解きほぐしていくと、マルチプレクシングという巨大な抽象化を支えるための「最後の安全弁」であり、リソース管理の極限の工夫が詰まったメカニズムであることが見えてくる。
- コネクションの全滅を防ぎ、特定の病巣だけを外科手術のように切り捨てる。
- ユーザーの離脱（CANCEL）を即座にサーバーの負荷軽減に直結させる。
- TCPバッファとカーネルパラメータの調律により、プロトコルのポテンシャルを限界まで引き出す。
- 悪意ある「RST洪水」からインフラストラクチャの命を守る。
プロトコルスペシャリストにとって、ネットワークとは単なるデータのパイプではない。そこには設計者たちの哲学と、現実の物理法則（遅延、帯域、CPU負荷）との妥協なき戦いの歴史が刻まれている。
パケットキャプチャを開き、流れるフレームの中に `RST_STREAM` を見つけたとき、そこにどのようなドラマ（あるいはトラブル）があったのかを想像できるようになれば、あなたも立派なインフラの求道者だ。今日も今日とて、美しきパケットの海へダイブしよう。
コメント