Nginx 1.25 开启 HTTP/2 后遭 Rapid Reset 打满 worker：协议层 DoS 到底该怎么防、怎么量化判断？

先说角色与栈：我做安全加固，习惯从现象倒推根因。这次要拆的是一个协议层 DoS——不是慢速攻击，而是 HTTP/2 帧层面的滥用。

【背景】 技术栈：Nginx 1.25（OpenSSL 3.0）做反代，后端是 gRPC / HTTP2 网关（grpc-go v1.6x），对外提供约 30 个 gRPC 方法 + 少量 REST。Nginx http2 on;，worker 数 = CPU 核（8C16G 单机），worker_connections 65535。前面再挂一层 LB。

【现象】 一次内部红蓝演练里，蓝队用 不到 50 条 TCP 连接，在每条连接上快速打开、立刻 RST_STREAM 大量 stream（典型的 Rapid Reset / CVE-2023-44487 打法），持续 90 秒：

• Nginx worker 的打开连接数没爆（远低于 worker_connections），但 active stream 计数瞬时冲到数万，CPU 单核打满；
• 真实 gRPC 请求 P99 从 80ms 飙到 2.1s，新建连接出现 connection refused / 排队超时；
• 后端 grpc-go 侧看到大量 RST_STREAM(NO_ERROR) 涌入，server 端 stream 建立/销毁 churn 极高。 抓包确认：RST_STREAM 帧占比 >70%，且每条连接上并发 stream 数远超正常业务（正常单连接并发 stream <20）。

【已尝试与结果】

1. 升级 Nginx 到 1.25.4+（官方已修 Rapid Reset 的默认 http2_max_concurrent_streams 行为），攻击仍能以「合法范围内的高并发 stream」造成压力——说明版本修复挡的是「滥用未设上限」，挡不住「上限内的合理洪峰」。
2. 试了 limit_conn 按 IP 限连接数，但攻击连接数本来就少，限连接没用；限的是 stream 维度才有效，可 Nginx 没有直接的 per-connection 并发 stream 上限参数（http2_max_concurrent_streams 是 1.27+ 才引入？我这边 1.25 没有）。
3. 抓包 + 在 grpc-go 侧加 MaxConcurrentStreams，能压住后端，但 Nginx 层 CPU 还是被 RST 处理吃掉。
4. 考虑直接对外禁用 HTTP/2、只留 h1c + gRPC 走 TCP 明文/内部 mTLS，但会牺牲 gRPC 的头部压缩与多路复用，业务不答应。

【期望得到的答案形态】

1. Nginx 层：1.25 上有没有可用的「单连接并发 stream 上限 / RST 速率限制」配置？如果没有，社区是怎么在反代层把 Rapid Reset / CONTINUATION flood 挡掉的（WAF 规则 / lua 限流 / 还是干脆禁用 h2）？
2. 检测与告警：怎么量化判断「正在被 RST 洪峰打」——该盯哪个指标（Nginx v3 status 的 http2_*？后端 RST_STREAM 速率？active stream / connection 比值）？给我一个可落地的阈值/告警样例。
3. 取舍：对 gRPC 网关，「禁用对外 HTTP/2」和「保留 h2 + 限 stream」哪个更稳？你们线上到底怎么配的？
4. 顺带：CONTINUATION flood（CVE-2023-44487 的另一形态，超长 header + 不续传）你们是怎么防的？

参考：社区里我写过一篇 HTTP 请求走私（协议边界不一致）的复盘（id=778），思路类似——都是「两层对同一协议的理解不一致/上限不一致」被放大成攻击面，所以这次更想对齐到「协议层限流」的具体配置上。