こんにちは！ネットワークやインフラの世界へようこそ。
日頃私たちが何気なく使っているウェブサイト。ブラウザを開けば一瞬で画像や文字が表示されますが、その裏側では「HTTP/2」という非常に賢いプロトコルが、驚くようなスピードでデータをやり取りしています。
HTTP/2の最大の特徴といえば、1本の太い通信回線（コネクション）の中で、いくつものデータを同時にテキパキとさばく「マルチプレクシング（多重化）」という技術ですよね。まるで、1人の敏腕配達員が同時に何件もの荷物を配り歩くようなものです。
でも、世の中、すべてが順調に進むわけではありません。
「あ、やっぱり今の注文キャンセルして！」「待って、その荷物の中身がおかしいから今すぐストップ！」なんてトラブル、現実の世界でもありますよね。
HTTP/2の世界でも、まさに同じことが起きます。今回は、そんな緊急事態に飛び出す「RST_STREAM（リセットストリーム）フレーム」と、その時に添えられる「エラーコード」の仕組みについて、一緒に優しく紐解いていきましょう！
一歩ずつ理解していけば全然難しくありませんので、リラックスして読み進めてくださいね。
—
1. 郵便配達で例える「ストリーム」と緊急停止
まずは、HTTP/2の基本的な仕組みをおさらいしておきましょう。
HTTP/2では、サーバーとブラウザの間に「1本の大きなパイプ（TCPコネクション）」がつながっています。そして、そのパイプの中に「ストリーム」と呼ばれる、いわば「個別の荷物をやり取りするレーン（専用の小包）」を何本も同時に作ることができます。
例えば、
- ストリーム番号1：トップページのHTMLを運ぶレーン
- ストリーム番号3：綺麗な背景画像を運ぶレーン
- ストリーム番号5：お気に入りのアイコンを運ぶレーン
こんなふうに、番号で管理されたレーンが同時に何本も走っているわけです。敏腕配達員（HTTP/2）は、あっちのレーンから荷物を運び、こっちのレーンへと、驚異的な手際よさで往復しています。
急なトラブル！荷物を強制終了したいときは？
さて、ここで想像してみてください。
あなたがストリーム番号3のレーンを使って、すごく重たい高画質な画像をダウンロードし始めたとします。でも、途中で気が変わって、別のページに移動しちゃいました。
このとき、「あ、もうあの画像の荷物、いらなくなった！」ですよね。
もし昔のやり方（HTTP/1.1）や、愚直にダウンロードを続けてしまう仕様だったら、いらないデータの到着を最後までじっと待たなければなりません。これでは回線の無駄遣いだし、ユーザーもイライラしてしまいます。
そこで登場するのが、今回の主役である「RST_STREAM（リセットストリーム）フレーム」です。
これは、配達員に向かって、
「おい！ストリーム番号3の荷物はもういいから、今すぐそのレーンをブチッと切って（キャンセルして）くれ！」
と叫ぶ、緊急停止の赤色灯付きの命令書なんです。
—
2. RST_STREAMフレームってどんなもの？
RST_STREAMは、HTTP/2がやり取りする「パケット（フレーム）」の一種です。
難しいビットの並びを覚える必要はありませんが、中身はざっくり言うと「どのレーンを」「どんな理由で」止めるのかが書かれたシンプルなメモ書きだと思ってください。
このフレームが送られてくると、サーバーもブラウザも、その番号のストリームを即座に消滅させ、使っていたメモリや回路を解放します。「終わった話はスパッと忘れて、次の仕事に集中しよう！」というわけですね。
どんな時に使われるの？主な2つのシチュエーション
1. ユーザーによるキャンセル
- 先ほど例に挙げた「ページを途中で閉じた」「リンクを押し直した」など、もうデータが不要になった時。
2. システムのエラーや異常事態
- 届いたデータの中身がめちゃくちゃで、ルール違反（プロトコルエラー）を見つけた時。
- サーバー側が「ごめん、もうリソースが足りないからこの処理続けられない！」と音を上げた時。
—
3. なぜ止めたの？を伝える「エラーコード」
RST_STREAMで「ストリームを止める！」と指示するとき、ただ止めるだけではなく、「なぜ止めるのか」という理由（エラーコード）を必ずセットで添えることになっています。
これが、現場のトラブルシューティング（デバッグ）において非常に重要な手がかりになります。代表的なものを、身近な例えと一緒にいくつか見てみましょう。
| エラーコード名（英語） | 意味・ニュアンス | 現実世界での例え |
| :— | :— | :— |
| NO_ERROR (0x0) | 「特に怒ってないけど、もう要らなくなったからやめるね」という穏やかなキャンセル。 | 「あ、やっぱりその品物、さっきのと一緒だったからキャンセルで！」 |
| PROTOCOL_ERROR (0x1) | ルール違反。「HTTP/2の約束事から外れた変なデータが来たよ！」 | 送り状の書き方がルール無用で、配達員が困惑している状態。 |
| CANCEL (0x2) | 「もうこのデータは不要になったからストップして」 | 注文した後に「やっぱりいらなくなった」と電話で取り消す時。 |
| REFUSED_STREAM (0x3) | 「今ちょっと忙しすぎて、その処理はやれない！」 | ラーメン屋で「すいません、本日のスープ切れで終了です！」と言われる時。 |
| INTERNAL_ERROR (0x6) | サーバー内部で予期せぬバグやパニックが起きた。 | レジのシステムが突然「フリーズ」して青画面になった時。 |
こうしたコードがログに残るおかげで、ネットワークエンジニアは「あ、このブラウザはユーザーがページを閉じたからキャンセル（CANCEL）したんだな」「こっちはプログラムの不具合でルール違反（PROTOCOL_ERROR）を起こしてるぞ」と、一目で原因を突き止めることができるのです。
—
4. 実務の現場でどう見える？（パケットやログの世界）
インフラエンジニアやWebエンジニアとして働いていると、ブラウザの開発者ツール（F12キーを押して出るコンソールやネットワークタブ）や、ネットワーク解析ツール（Wiresharkなど）で、このRST_STREAMに遭遇することがあります。
例えば、パケットキャプチャツール「Wireshark」で中身を覗き見すると、以下のような情報が記録されています。
Frame 123: 13 bytes on wire
HTTP/2
Length: 4
Type: RST_STREAM (3) <- これがRST_STREAMフレームだよ！
Flags: 0x00
Stream Identifier: 3 <- ストリーム番号「3」のレーンを指しているよ！
Error Code: CANCEL (0x00000002) <- 理由は「ユーザーのキャンセル」だよ！
もし、皆さんが開発しているアプリやWebサーバーで、意図せず `PROTOCOL_ERROR` や `INTERNAL_ERROR` が頻発していたらどうでしょう？
「おや、クライアント側が送るリクエストの形式がおかしいのかな？」それとも「バックエンドのプログラムにバグがあるのかな？」と、アタリをつける強力な武器になりますよね。
---
まとめ
いかがでしたでしょうか？
一見難しそうに見える「HTTP/2のRST_STREAMフレームとエラーコード」も、蓋を開けてみれば「多重化されたレーンの中で、不要になったり異常があったりした通信を、理由を添えて安全に強制終了させるための仕組み」という、非常に人間らしく合理的でシンプルなストーリーで出来ています。
日々のネットワークの向こう側で、こうしたフレームたちがコンマ何秒の間に「ちょっとストップ！」「了解！」と会話を繰り広げているのを想像すると、インフラやプロトコルの世界が少し身近に感じられてワクワクしてきませんか？
実務でエラーログに直面したときは、ぜひ今回の「郵便配達と緊急停止のメモ」を思い出してみてくださいね。あなたのネットワークデバッグの旅が、少しでもスムーズで楽しいものになりますように！
コメント