网站启用HTTP/2后是否更容易遭受DDoS攻击

HTTP/2 的普及常伴随着一个尖锐的质疑：多路复用和长连接是否让攻击成本变得更低？答案很明确，HTTP/2 协议本身并不会制造 DDoS 漏洞，但它确实改变了攻击的流量特征和防御门槛。传统的基于连接数和请求速率的防御策略在 HTTP/2 面前经常失效，因为一个合法的 TCP 连接在 HTTP/2 下可以承载数百个并发的流，攻击者不再需要耗费大量资源去完成 TCP 握手和 TLS 协商，就能在单一连接内发起海量请求。这意味着攻击的隐蔽性更高，对服务器计算资源的压榨也更精准。

HTTP/2 的核心优势是二进制分帧和多路复用，这允许客户端在同一个连接上同时打开多个流，发送交错请求。正常的浏览器会限制并发流数量，但恶意客户端不会。攻击者可以建立一个 TLS 连接，然后瞬间向服务器声明数千个流，每个流都携带一个看似合法的请求头。服务器必须为每个流分配内存和解析资源，即便最终发现请求是恶意的，资源也已被消耗。这种攻击在 HTTP/1.1 时代需要建立数千个连接，容易被基于 IP 和连接计数的防护设备识别，而在 HTTP/2 下，攻击流量高度集中，单 IP 的攻击密度可以提升数十倍。

HTTP/2 使用 HPACK 算法压缩请求头以减少带宽，但这为服务器内存耗尽攻击提供了新路径。攻击者会发送精心构造的头部帧，这些头部在压缩状态下体积很小，能轻松通过流量检测，但解压后在服务器内存中会膨胀到数兆甚至数十兆。更危险的是，攻击者可以利用动态表更新机制，不断向服务端发送引用动态表的指令，迫使服务器反复进行解压和索引重建。一个单流请求就可能耗尽几十 MB 内存，如果结合多路复用同时发起几十个这样的流，服务器会在几秒内因内存溢出而崩溃。这种攻击完全绕过了传统的请求速率限制，因为从请求数量看完全正常。

HTTP/2 的流量控制基于连接和流两个层级，攻击者可以通过恶意操控流控窗口来发起资源耗尽攻击。正常客户端会及时更新窗口大小，但攻击者可以故意不发送 WINDOW_UPDATE 帧，导致服务端必须长时间保持流状态等待窗口开放。当攻击者在单一连接上创建上万个这样的“僵尸流”，服务端必须为每个流维护发送缓冲区和状态机，连接本身却不会超时，因为 PING 帧可以正常响应。这种攻击将慢速攻击从连接级别升级到了流级别，一台普通服务器可能只需几十个恶意连接就能被拖垮，而防火墙看到的是少量长连接在正常通信。

HTTP/2 的控制帧处理消耗的是服务器最核心的协议栈资源。PING 帧原本用于测量往返时间，但攻击者可以以极高频率发送 PING 帧，服务器必须立即回复 PING ACK，这直接消耗 CPU 和网络中断资源。更隐蔽的是 PRIORITY 帧攻击，攻击者不断发送优先级变更指令，迫使服务器对依赖树进行重新排序和计算。由于 HTTP/2 规范要求服务器必须尊重客户端的优先级建议，这种计算开销无法被轻易忽略。当攻击者以每秒数千次的频率发送 PRIORITY 帧时，服务器的协议处理线程会陷入优先级排序的死循环，业务请求反而得不到处理。

HTTP/2 的 SETTINGS 帧在收到后必须立即生效，攻击者可以利用这一点发起参数协商攻击。例如，攻击者可以将 SETTINGS_MAX_CONCURRENT_STREAMS 设置为一个极大值，然后瞬间创建大量流；或者将 SETTINGS_HEADER_TABLE_SIZE 设为零，迫使服务器清空并重建 HPACK 动态表，反复发送这种 SETTINGS 帧就会导致服务器持续进行昂贵的表重建操作。更恶劣的是，攻击者可以在 SETTINGS 帧中填入大量未知参数标识符，根据规范服务器必须忽略它们但仍需完整解析帧内容，这种解析本身就需要消耗 CPU 周期，当帧被故意填充到接近最大帧大小限制时，解析开销变得不可忽视。

很多网站运维团队在启用 HTTP/2 后，仍然沿用 HTTP/1.1 时代的压测和防护标准。他们关注的是每秒请求数（RPS），却忽略了并发流数量这一关键指标。在 HTTP/1.1 下，1000 个并发请求意味着 1000 个连接，服务器能清晰看到连接数的增长。在 HTTP/2 下，1000 个并发请求可能只来自 10 个连接，但每个连接内部有 100 个流在竞争服务器资源。如果服务器的并发流上限配置过高，攻击者就能用极少的 IP 和连接制造巨大的内部并发压力。这种压力不会触发传统的连接数告警，也不会被基于 IP 信誉的防护系统拦截，因为攻击 IP 的请求频率看起来完全在正常范围内。

不同服务器软件对 HTTP/2 的实现存在显著差异，这些差异本身就是攻击面。某些服务器在流状态管理上采用乐观分配策略，即客户端声明一个流 ID 后服务器立即分配内存，而不是等到请求数据到达。攻击者可以连续声明大量流 ID 而不发送任何数据，快速耗尽内存。另一些服务器在处理 RST_STREAM 帧时存在竞态条件，攻击者通过快速创建流然后立即重置，可以触发服务器释放已分配但仍在使用的内存，导致内存损坏或崩溃。这些实现层面的漏洞与 HTTP/2 协议规范无关，但在实际部署中，正是这些细节决定了服务器能否在攻击中存活。

HTTP/2 在实际部署中几乎强制使用 TLS，这引入了额外的攻击维度。TLS 握手本身就是计算密集型操作，攻击者可以发起大量 TLS 握手请求但不完成 HTTP/2 的初始化，迫使服务器在握手阶段消耗 CPU 资源。更高级的攻击会完成完整握手并建立 HTTP/2 连接，然后利用 HTTP/2 的多路复用能力在加密隧道内发起应用层攻击。因为流量被加密，传统深度包检测设备完全无法识别内部的帧攻击，只能看到加密数据在正常流动。这意味着防御必须从网络层上移到应用层，需要服务器自身具备 HTTP/2 帧级别的检测能力，而这恰恰是多数部署的薄弱环节。

面对 HTTP/2 带来的攻击面变化，防御措施必须下沉到协议帧级别。首先，服务器应严格限制单连接的并发流数量，Nginx 的 http2_max_concurrent_streams 指令默认值为 128，这是一个相对安全的起点，但需要根据业务实际需求调整，而不是盲目放大。其次，必须启用流级别的超时控制，对长时间不发送数据的流主动发送 RST_STREAM 终止，避免僵尸流堆积。第三，HPACK 解压后的头部大小必须设置硬性限制，超过阈值的头部直接拒绝，不能无限制地允许头部膨胀。第四，对 PING、PRIORITY、SETTINGS 等控制帧的发送频率进行令牌桶限速，超出频率的控制帧直接丢弃并记录告警。

最有效的防御架构是在 HTTP/2 流量到达源站之前进行协议清洗。在反向代理层终结 HTTP/2 连接，将经过验证和清洗的请求以 HTTP/1.1 或内部协议转发给后端。这样做的好处是，所有帧级别的攻击都在代理层被消化，后端服务器完全不受影响。代理层可以部署专门的 HTTP/2 安全模块，对帧序列进行状态机检测，识别异常帧组合。例如，连续发送 SETTINGS 帧而不发送实际数据的行为可以被标记为可疑；在短时间内创建大量流然后立即重置的模式可以被识别为资源耗尽攻击。这种协议级别的行为分析远比简单的速率限制有效。

HTTP/2 客户端在握手阶段会发送 SETTINGS 帧宣告自身参数，不同客户端库和浏览器的参数组合具有指纹特征。攻击工具通常使用定制化的 HTTP/2 库，其 SETTINGS 参数组合与正常浏览器存在明显差异。防御系统可以建立正常客户端的指纹白名单，对指纹异常的连接施加更严格的流控限制。同时，限速策略需要从 IP 维度细化到连接维度和流维度。同一个 IP 的不同连接可能混合了正常用户和攻击脚本，不能因为一个连接异常就封禁整个 IP。更精细的做法是对每个连接独立评估，对异常连接只断开该连接而不影响同 IP 的其他连接。

启用 HTTP/2 后，运维团队必须更新监控面板。传统的连接数、请求速率指标已不足以反映真实负载。需要新增的监控指标包括：单连接平均流数量、峰值流数量、流创建速率、流重置速率、PING 帧频率、SETTINGS 帧频率、HPACK 解压失败次数、头部大小分布等。当单连接流数量突然飙升至正常值的数十倍，或者流重置率超过 50%，即使总请求量没有变化，也极有可能正在遭受 HTTP/2 特有的攻击。这些指标需要被集成到告警系统中，并且设置合理的动态基线，因为不同业务时段的正常流模式差异很大。

服务器配置层面有若干立即可行的加固措施。对于 Nginx，除设置 http2_max_concurrent_streams 外，还应配置 http2_recv_timeout 和 http2_idle_timeout 来主动清理异常连接。对于 Apache，H2MaxSessionStreams 和 H2StreamTimeout 提供类似功能。在操作系统层面，应调整 TCP 缓冲区大小和连接追踪表容量，防止单连接消耗过多内核资源。在应用层面，应实现请求处理的超时熔断机制，对处理时间异常长的请求主动中断，避免工作线程被慢速攻击耗尽。这些配置不是一劳永逸的，需要根据攻击态势持续调整。

HTTP/3 使用 QUIC 协议替代 TCP，底层传输机制发生根本变化，但多路复用的核心思想被保留并进一步强化。QUIC 的连接迁移特性意味着攻击者可以不断变换 IP 地址而保持同一个连接和流状态，这给基于 IP 的追踪和限速带来更大挑战。HTTP/3 的帧结构与 HTTP/2 类似，因此帧级别的攻击手法大多可以平移，但 QUIC 内置的加密层使得中间设备的可见性进一步降低。现在部署 HTTP/2 时积累的帧级别防御经验，将直接成为未来应对 HTTP/3 攻击的基础。那些现在就开始在代理层做协议清洗的团队，在迁移到 HTTP/3 时会发现架构上的优势更加明显。

网站启用 HTTP/2 后，遭受 DDoS 攻击的风险并没有在协议层面增加，但攻击的形态和防御的难点发生了本质变化。攻击者可以利用多路复用、头部压缩和流控机制，用更少的资源发起更隐蔽、更精准的资源耗尽攻击。传统的基于连接数和请求速率的防御体系在这种新攻击面前存在明显盲区。安全的关键不在于是否启用 HTTP/2，而在于是否建立了帧级别的检测能力和协议清洗架构。对于已经启用或计划启用 HTTP/2 的网站，当务之急是审查服务器配置中的并发流限制、头部大小限制和控制帧频率限制，并在反向代理层部署 HTTP/2 安全策略，将协议层面的风险隔离在业务逻辑之外。