仕様書

意味

[2] RST_STREAM フレーム (フレーム型 0x3) は、ストリームを直ちに終わらせるものです >>1。

[35] END_STREAM フラグとは違って、異常終了を表します。 おおよそいつでも送信できます。

構文

[8] ストリーム識別子を指定しなければなりません >>1。 0x0 は指定できません。

[6] フラグはありません >>1。 0 でなければなりません >>18。 受信者は無視しなければなりません >>18。

[4] payload は、次の欄を含みます。

文脈

[3] RST_STREAM フレームは、ストリームエラーの際に送信されます >>13。

[10] idle 状態のストリームに送信してはなりません >>1, >>19。 その他の状態のストリームで送信できます。ほとんどいつでも送信できますが、 (他のストリームも含めて) CONTINUATION フレームが送られるべき位置で送ることはできません。

[14] 受信した RST_STREAM フレームに対して RST_STREAM フレームを送信してはなりません >>13。

[20] reserved (local) 状態のストリームについて、 予約解除のために使うことができます >>19。

[15] フロー制御の都合で送信されることがります。

[16] クライアントからの要求の送信途中でサーバーがもう要求の続きは不要であることを示すために RST_STREAM を送信することができます。

[26] サーバープッシュが不要と示すために、 RST_STREAM を送信することができます。

[22] RST_STREAM フレームを送信した直後は、通常の closed 状態とは異なり、一部のフレームを部分的にのみ処理したり、無視したりします >>19。 いずれにせよ、受信する準備をしておかなければなりません >>13。

[24] RST_STREAM フレームを複数回送信するべきではありません。 ただし closed になった後 1RTT を経過してもフレームを受信し続ける場合を除きます。 >>13

[28] CONNECT では、TCP RST などのエラーに相当します。

[37] 303 を除く HTTPリダイレクトの受領直後にクライアントが RST_STREAM を送信することが推奨 (encourage) されています >>36。

処理

[9] 受信者は、ストリーム識別子が 0x0 なら、 接続エラー PROTOCOL_ERROR としなければなりません >>1。

[34] ストリームの状態遷移の項も参照。

[11] 受信者は、ストリームが idle 状態なら、 接続エラー PROTOCOL_ERROR としなければなりません >>1。

[33] Chrome も Firefox も、未使用 (idle) のストリームの RST_STREAM を受信しても、エラーとはしません。 2015-10-10T11:58:17.300Z

[31] Firefox は HEADERS より前に RST_STREAM を受信したら接続エラー PROTOCOL_ERROR とするようです。 (Chrome は何も送信しません。) 自身が HEADERS を送信したら open 状態になっているはずなので、接続エラーとするのは不審です。 2015-10-10T11:42:35.00Z

[12] 受信者は、payload の長さが 4 以外なら、 接続エラー FRAME_SIZE_ERROR としなければなりません >>1。

[7] 指定されたストリームを closed 状態へと移行させます >>19。 受信者は、以後 PRIORITY 以外のフレームを送信してはなりません >>1。しかし送信者はなおも受信する準備をしなければなりません >>1。

[32] END_HEADERS より後で END_STREAM より前に RST_STREAM を受信すると、Firefox も Chrome もネットワークエラーとします。その RST_STREAM やそれ以後の同じストリームのフレームは無視するようです。 2015-10-10T11:53:35.600Z

[23] closed 状態で受信した RST_STREAM は、 状況によって無視したり、エラーとしたりします >>19。

DoS 攻撃

[48] 令和5年10月に大規模 DoS攻撃があり、 HTTP/2 プロトコル実装上の脆弱性と報告されました。

[44] CVE Record | CVE, 2023-10-10T20:41:36.000Z, 2023-10-11T05:10:56.217Z https://www.cve.org/CVERecord?id=CVE-2023-44487

[42] HTTP/2 Rapid Reset: deconstructing the record-breaking attack, 2023-10-11T05:09:43.000Z https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

[43] HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks, 2023-10-11T05:10:27.000Z https://blog.cloudflare.com/zero-day-rapid-reset-http2-record-breaking-ddos-attack/

[45] How AWS protects customers from DDoS events | AWS Security Blog, 2023-10-12T22:51:49.000Z, 2023-10-13T14:34:40.751Z https://aws.amazon.com/jp/blogs/security/how-aws-protects-customers-from-ddos-events/

[46] Google Cloud mitigated largest DDoS attack, peaking above 398 million rps | Google Cloud Blog, 2023-10-13T14:35:09.000Z https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps?hl=en

[47] How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog, 2023-10-13T14:35:37.000Z https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en

[49] >>47 GOAWAY による対処についても言及あり、

関連

[29] TCP の RST や TLS の error alert と役割が似ています。

歴史

[41] HTTP/2 で導入されました。

[21] Allow user agents to transmit RST_STREAM upon seeing a redirect · whatwg/fetch@af0dc92 (2016-03-26 11:55:58 +09:00 版) https://github.com/whatwg/fetch/commit/af0dc923f7636751996a9762309904511725a1a7

[38] Abortable fetch (jakearchibald著, 2017-09-20 21:59:57 +09:00) https://github.com/whatwg/fetch/commit/0bcd5dfc71ef44319873887f4b83119bd6d0b71d

[39] More eargerly send RST_STREAM on redirects (annevk著, 2017-11-24 20:11:46 +09:00) https://github.com/whatwg/fetch/commit/fd286755e9664d570260c16f7c1933f424d2f39a

[40] More eargerly send RST_STREAM on redirects by annevk · Pull Request #638 · whatwg/fetch (2017-11-30 23:34:01 +09:00) https://github.com/whatwg/fetch/pull/638