网模的攻2每秒 蓝点最大规谷歌缓用HT亿个请解史上击 攻击者利求 发出3
服务器仍然需要为取消请求执行大量工作 ，谷歌规模
这样就可以疯狂发起请求然后再发送 RST_STREAM 帧 ，缓解这比 HTTP/1.1 的史上排队处理要优秀的多 。
当服务器收到 RST_STREAM 帧时 ，击攻击与 HTTP/1.1 中的利用蓝点每个请求都是排队处理不同 ，客户端可以单方面这么干 。每秒
在典型的发出 HTTP/2 服务器实现中 ，100 并发流是请求单次请求中的上限，攻击者不会发起超过并发流的谷歌规模限制 ，
对于反向代理实现，缓解在 100 个并发流范围内使用大量攻击客户端在每秒内发出多个请求(注意：在 1 秒内可以发出多次请求 ，史上
这种并发操作的击攻击好处在于每个连接的利用率都可以提高 100 倍 ，其特性之一就是利用蓝点提高 TCP 连接的利用率 ，取消都将立即生效。每秒
这类攻击导致请求的发出数量不再取决于 RTT 即往返时间 ，但谷歌觉得有必要引起业界关注，
HTTP/1.1 攻击、
攻击者利用这个方法从 8 月份开始对谷歌云平台的客户发起攻击 ，这也是目前有记录以来的每秒请求数最高的一次攻击 。发起攻击的一方无需支付发送请求的费用 ，常规 HTTP/2 攻击和 HTTP/2 快速重置攻击的请求示意图
攻击者怎么操作的呢？攻击者利用这个特性，) 。每个流对应着一个 HTTP 请求 。
HTTP/2 的特性 ：
HTTP/2 的主要设计目标就是效率 ，在处理来自该 TCP 链接的任何其他数据之前 ，
HTTP/2 快速重置漏洞 ：
这个问题目前已经被标记为安全问题 ，解析查询并进行标头压缩以及将 URL 映射到资源 。例如分配新的流数据结构 、其中攻击者在某次攻击中在 1 秒内发出了高达 3.98 亿个请求 ，因为服务器并不能单方面调整限制 。
HTTPS/3 没这个问题 ：
由于协议的差异 ，HTTP/2 中可以在单个 TCP 连接中打开多个并发流 ，而是 HTTP/2 的特性被攻击者利用 ，
另一方面 ，而且这还不需要客户端和服务器进行任何协商 ，
HTTP/2 还有个特点是 RST_STREAM ，但每秒发出多次请求就可以快速放大攻击 。谷歌目前并未看到有关 HTTP/3 DDoS 的大规模攻击向量 ，
Google Cloud 本周发布博客介绍最近一段时间新出现的攻击类型：HTTP/2 快速重置 。谷歌认为 HTTP/2 DDoS 不会被直接转换为 HTTP/3 或 QUIC DDoS ，而是取决于服务器的可用网络带宽 。严格来说这并不是安全问题 ，也就是 100 ，该协议允许客户端向服务器发送 RST_STREAM 帧来取消先前的流 ，
理论上说并发打开流的最大数量应该由目标服务器控制 ，服务器也会处理这 100 个流 ，成本极低 。可以在处理 RST_STREAM 帧之前将请求代理到后端服务器 。
缓解方案见这里 ：https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack
尽管如此谷歌仍然建议 HTTP/3 服务器主动实施机制来限制单个传输连接完成的工作量 。还可以放大攻击规模，但实际上客户端的每个请求可以打开 100 个流 ，编号为 CVE-2023-44487 ，这样一个发起攻击的客户端开始工作后再快速重置请求 ，请求被取消后 ，HTTP/2 的连接实际还保持着打开状态 。所以也提交了漏洞通报 。操作方法类似于 HTTP/2 DDoS 的缓解方案 。这对网络带宽的占用也不大 ，在发出请求帧后立即发送 RST_STREAM 帧 ，