• 为何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 来管理限制,从技术上讲,限制是针对 "流 "而非 "请求 "的。

    原文

  • 相关阅读:
    【FFmpeg】ffmpeg使用drawtext过滤器在视频上叠加文字
    C#多线程之(Thread)详解与示例
    L2-007 家庭房产 - java
    个推「数据驱动运营增长」上海专场:携程智行火车票分享OTA行业的智能用户运营实践
    复盘:经典的HR面试问题,这些问题可以挖掘你个人的素质,看看你是否合适合我们部门
    ERP对接淘宝/天猫/京东/拼多多商品详情数据API接口
    windows上 Nexus 批量上传 maven依赖npm依赖
    美创科技参编《数字政府建设与发展研究报告(2023)》 正式发布
    Elasticsearch索引操作(七)
    springboot 整合clickhouse
  • 原文地址:https://blog.csdn.net/cfy_banq/article/details/133820700