为何Http3没有Http2快速重置攻击?

让我们从一个简单的自动售货机的类比开始:

  • HTTP/2 就像一个效率非常低的系统:每次有人购买一件物品时,都需要立即由一名(非常劳累的)员工全天候(24/7)进行补充。它始终保持充足的库存。
  • HTTP/3 是一种更现实的设置:机器只有在(几乎)空的时候或在设定的时间才会重新加水。如果是空的,你只需要等待。 HTTP/3 自动售货机非常严格地执行了这一规定:如果你试图购买不存在的物品,它就会炸毁整栋大楼!

换句话说,

  • HTTP/2 对其可处理的并发请求量是有限制的。 每当一个请求处理完毕(从自动售货机中购买并补充物品),紧接着就可以接受另一个请求。

  • 但是,HTTP/3 对累计请求的处理量有限制。 即使请求已完成,总计数仍会增加 1(自动售货机中少了 1 件商品)。您需要等待自动售货机重新装满(新的累计限制)。

和大多数比喻一样,这个类比也有缺陷,但能帮助我们理解这里的高层次差异。

那么,让我们从更底层的角度来看看实际发生了什么。

假设 HTTP/2 和 HTTP 3 的请求数都限制为 3 个:

对于 HTTP/2:

  • 请求 1 接收(并发请求数 = 1)

  • 请求 1 被客户端快速重置(并发请求数 = 0)

  • 请求 2 进入(并发请求数 = 1)

  • 请求 2 被客户端快速重置(并发请求数 = 0)

  • 请求 3 进入(并发请求 = 1)

  • 请求 3 被客户端快速重置(并发请求 = 0)、

由于被客户端“快速重置”,3 这个并发限制被 "绕过"。

对于 HTTP/3:

  • 请求 1 接收(累计请求数 = 1)

  • 请求 1 被重置(累计请求数 = 1)

  • 请求 2 进入(累计请求数 = 2)

  • 请求 2 被重置(累计请求数 = 2)

  • 请求 3 进入(creqs = 3)

  • 请求 3 重置(creqs = 3)

如果请求 4 进入,HTTP/3 将以 STREAM_LIMIT_ERROR 结束。

因此,虽然 HTTP/2 的限制从未改变,但并发请求量却始终低于该限制。 而对于 HTTP/3,累计限制会增加,但只有当总请求数达到之前的限制时才会增加,而不是像http2在重置数据流的时候!

这里有一点细微差别。理论上,HTTP/3 实现可以在每次请求重置后更新(内部)累计限制,但这种实现方式很奇怪(通常要等到至少处理完一个数据包后才会这样做)。

因此,在上面的例子中,如果请求 4 与请求 1-3 在同一个数据包中(如快速重置),HTTP/3 就会出错,因为它只有在处理完整个数据包后才会更新累计限制。 因此,攻击者可以在每个数据包中容纳更少的请求。

因此,从概念上讲,HTTP/3 可能存在漏洞,但前提是实现过程中出现了奇怪的情况(非常急切地更新限制)。 否则,攻击就会受到每次往返最大累计请求的限制(因为限制更新需要先到达客户端,然后才能继续!)。

因此,HTTP/3的每秒最大请求次数比 http2 低得多,从而减轻了攻击。 IETF 的一份新文件建议在 HTTP/2 中使用 HTTP/3 流限制
我们将拭目以待未来的实现如何处理这一问题。

最后的技术补充:在 HTTP/3 中,实际上是由 QUIC 来管理限制,从技术上讲,限制是针对 "流 "而非 "请求 "的。

原文

你可能感兴趣的:(javascript,reactjs)