CC攻击中HTTP2多路复用的请求限制策略

CC攻击中，HTTP/2多路复用的请求限制策略核心在于：攻击者利用HTTP/2协议的单连接多路复用特性，在一个TCP连接上并发发送海量请求，以极低的成本耗尽服务器资源。应对的关键不是简单地限制连接数，而是要在单个连接内部，对并发流（Stream）的数量、速率以及请求的生命周期进行精细化的管控和约束。

理解HTTP/2多路复用如何被CC攻击滥用

传统的HTTP/1.1时代，CC攻击主要依靠建立大量TCP连接，每个连接发送少量请求。服务器维护每个连接都有开销，但这种攻击模式相对容易被识别，例如通过限制单个IP的连接数。然而，HTTP/2的多路复用改变了游戏规则。它允许在同一个持久连接上同时交错传输多个请求和响应（这些独立的请求/响应流称为Stream）。对于攻击者而言，这意味着只需建立少数几个甚至一个到目标服务器的HTTP/2连接，就可以在这个连接内并发地发起成千上万的请求。这极大地降低了攻击成本（减少握手开销和套接字占用），并绕过了基于连接数的传统防御策略，使得攻击流量更隐蔽，对服务器应用层（如CPU、数据库、内存）的打击更精准、更致命。

针对HTTP/2连接的核心限制策略

要防御此类攻击，必须在网关或Web服务器层面实施针对HTTP/2特性的深层控制。首要策略是限制单个HTTP/2连接内的并发活动流数量。HTTP/2协议本身通过SETTINGS帧中的SETTINGS_MAX_CONCURRENT_STREAMS参数协商服务端允许的最大并发流。防御方应主动设置一个保守的阈值。例如，在Nginx中，可以通过"http2_max_requests"或"http2_max_concurrent_streams"指令进行限制。但仅此还不够，因为攻击者可以快速完成旧流并开启新流。

# Nginx 配置示例：限制每个HTTP/2连接的最大并发流
http {
    server {
        listen 443 ssl http2;
        http2_max_concurrent_streams 100; # 限制单个连接最多100个并发流
        ssl_certificate /path/to/cert.pem;
        ssl_certificate_key /path/to/key.pem;
        ...
    }
}

其次，需要限制单个连接上流的创建速率。即使并发流数有限，攻击者仍可以以极高的速率串行发送请求（快速结束旧流，发起新流）。因此，必须实施“请求速率限制”，即限制单个连接在单位时间内可以发起的请求总数（或新建流的总数）。这需要在网络边缘设备或Web服务器配置中实现。

结合应用层识别的精细化管控

单纯的协议层限制可能会误伤正常用户。因此，策略必须与应用层行为分析结合。例如，对请求的以下特征进行动态分析：

(1) 请求目标：大量并发流是否集中攻击某个特定URL（尤其是消耗资源的动态API或登录页面）？

(2) 流状态异常：是否存在大量快速重置（RST_STREAM）的流或长时间处于IDLE状态的流？

(3) 请求内容与模式：请求参数是否异常、是否来自已知恶意User-Agent、是否符合人类操作模式（如正常浏览会有图片、CSS、JS请求，而CC攻击往往只反复请求核心接口）。

基于这些分析，可以实施动态策略：对疑似恶意的连接，动态调低其"SETTINGS_MAX_CONCURRENT_STREAMS"值，或对其施加更严格的请求速率限制。例如，使用OpenResty结合Lua脚本可以灵活实现：

-- OpenResty Lua 示例：基于IP和URL路径的动态流限制
local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("my_limit_store", 50, 100) -- 每秒50req，突发100
if not lim then
    ngx.log(ngx.ERR, "failed to instantiate a resty.limit.req object: ", err)
    return ngx.exit(500)
end

local key = ngx.var.remote_addr .. ":" .. ngx.var.uri -- 按IP+URI组合限流
local delay, err = lim:incoming(key, true)
if err == "rejected" then
    -- 如果请求被拒绝，可以发送RST_STREAM帧或直接断开连接
    ngx.header["x-http2-stream-reset"] = "1"
    return ngx.exit(503)
end

利用超时与重置机制进行防御

主动管理流的生命周期至关重要。设置合理的超时时间可以有效释放被占用的资源：

(1) 流超时：如果一个流开启后，在指定时间内未收到请求帧或未发送完响应，应强制关闭该流。

(2) 连接超时：对于长时间空闲或活动流异常多的连接，应主动断开。此外，服务器应积极使用HTTP/2的RST_STREAM帧来立即终止恶意或异常的流，而不是等待其自然完成，这可以快速释放服务器端资源。

部署于网络架构中的多层次防御

有效的防御不应只依赖Web服务器。推荐采用纵深防御架构：

(1) 边缘防护层：使用具备高级HTTP/2感知能力的Web应用防火墙（WAF）或云安全服务。这些服务能解析HTTP/2帧，基于全局情报和机器学习模型识别异常的多路复用模式，并在边缘进行清洗和拦截。

(2) 负载均衡/API网关层：在此层实施全局速率限制和连接管理策略。例如，配置每个后端服务实例所能接受的总HTTP/2连接数和总并发流数上限，防止流量穿透到脆弱的业务服务器。

(3) Web服务器/应用层：如前所述，进行最终的精细控制和兜底防护。

监控、日志与应急响应

没有监控的防御是盲目的。必须建立针对HTTP/2流量的监控指标：每个连接的并发流数分布、新建流速率、流错误率（如RST_STREAM比例）、请求与响应字节数比率等。一旦发现单个连接的并发流数持续接近设定阈值、或新建流速率异常高，应立即触发告警。在日志中，需要记录详细的HTTP/2帧信息（在隐私合规前提下），特别是流ID、帧类型、标志位等，以便在攻击发生后进行溯源和分析。应急响应预案应包括：临时调低全局并发流限制、对特定攻击源IP实施HTTP/2连接阻断、或暂时降级到HTTP/1.1协议（因为HTTP/1.1的连接成本模型更容易被现有防御体系处理）。

总结与最佳实践建议

面对利用HTTP/2多路复用的CC攻击，防御者需要转变思路，从“管连接”深入到“管流”。最佳实践可归纳为：限并发（设置保守的SETTINGS_MAX_CONCURRENT_STREAMS）、控速率（限制单个连接的单位时间请求数）、识异常（结合应用层行为分析进行动态调整）、设超时（主动管理流和连接的生命周期）、分层防（在网络边缘、网关、服务器多层部署策略）。同时，保持协议栈的及时更新，以修补可能被利用的HTTP/2实现漏洞。通过上述组合策略，可以在享受HTTP/2性能红利的同时，有效抵御其被滥用带来的安全风险，确保服务的高可用性。

CC攻击中HTTP2多路复用的请求限制策略

服务指南

帮助中心