CC攻击通过HTTP2多路复用放大

CC攻击利用HTTP/2多路复用进行放大，本质上不是协议漏洞，而是对并发模型和服务器资源分配机制的极限压测。攻击者在一个TCP连接上，通过单一信道同时发送数百甚至上千个请求，目标服务器或反向代理必须为每个请求分配对应的处理资源，但连接层面的追踪和限制手段却只能看到一个合法的、低频的TCP握手。这种不对称，让传统基于连接数或请求速率的防御策略大面积失效。

HTTP/2的核心优化是允许在一条TCP连接上并发传输多个流，每个流承载一对请求与响应。正常浏览器会限制并发流数量，通常控制在100到200个，但攻击工具完全无视这种约定。攻击者建立一条TCP连接，完成TLS握手后，直接在这条连接上开启数千个流，每个流携带一个看似合法的HTTP请求，目标地址可以是同一个资源，也可以是随机生成的动态路径。

服务器收到这些流后，协议栈会将其拆分成独立的请求交给后端处理。如果后端是PHP-FPM、Java线程池或Node.js事件循环，每个请求都会占用Worker、线程或文件描述符。攻击成本是一条连接、一次握手，而防御方需要消耗数千倍的资源去处理这些请求。更致命的是，很多WAF和限速模块基于连接数或IP维度做统计，面对单连接万级并发流，统计值完全失真。

压力点不在带宽，而在内存和CPU上下文切换。每个HTTP/2流都对应一个HPACK压缩上下文、一个流状态机和一块发送缓冲区。当攻击者在一个连接上瞬间创建8000个流，Nginx或Apache的HTTP/2模块需要为每个流分配内存结构，并维护其生命周期。即使后端返回444或直接RST_STREAM，协议栈本身已经消耗了大量内核态和用户态内存。

实测中，一台配置32核CPU、64GB内存的Nginx服务器，面对单连接10000个并发流，Worker进程的内存占用会从几百MB飙升至数GB，CPU软中断和上下文切换激增。如果攻击者同时从多个IP发起类似的单连接高并发流，服务器很快会进入资源耗尽状态，表现为502、504错误，或者TCP Accept队列溢出，正常用户的请求被严重挤压。

基于IP的速率限制是最早失效的。攻击者可以只用10个IP，每个IP建立一条HTTP/2连接，每条连接上维持5000个并发流，总请求量达到50000 QPS，但每个IP的连接数仅为1，远低于常规阈值。基于连接数的限制同样无效，因为攻击者刻意压低连接数，把并发压力转移到流层面。

WAF的挑战在于，HTTP/2流量到达WAF时已经是解密后的明文，但WAF需要解析每个流的HEADERS帧和DATA帧。如果WAF自身对HTTP/2多路复用的处理没有做流级别的深度限速，攻击者可以通过大量短小请求直接打满WAF的解析能力。部分WAF为了性能，甚至会将HTTP/2请求先转换为HTTP/1.1再进行检测，这个转换过程本身就会在内存中缓存大量请求，成为瓶颈。

防御要从协议栈和应用层同时入手，重点是对单连接流数量、流速率和请求并发度做精细化控制。以Nginx为例，关键参数需要根据业务实际承载能力调整，而不是使用默认值。

首先，限制单连接的并发流数量：

http {
    http2_max_concurrent_streams 128;
}

这个参数直接控制一条HTTP/2连接上允许的最大并发流数。默认值通常是128，但很多高并发场景下管理员会调大，这恰恰给攻击留下了空间。建议根据后端处理能力严格评估，如果业务不需要极高并发流，可以进一步降低到64甚至32。

其次，控制请求处理速率和连接级资源：

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;
    limit_conn_zone $binary_remote_addr zone=perconn:10m;
    
    server {
        limit_req zone=perip burst=20 nodelay;
        limit_conn perconn 10;
    }
}

limit_req基于IP做请求速率限制，但面对单连接高并发流时，这个模块仍然有效，因为Nginx会按请求维度计数，而不是按连接。limit_conn限制同一IP的连接数，虽然攻击者连接数少，但结合流限制可以形成多层防线。

对于Apache，HTTP/2模块提供了H2MaxWorkers、H2MaxSessionStreams等指令，同样需要严格限制：

Protocols h2 http/1.1
H2MaxSessionStreams 100
H2StreamMaxMemSize 128k

这些配置可以防止单会话占用过多内存和流资源。

应用层配置只是第一道防线，TCP/IP协议栈的参数同样关键。攻击者即使被应用层拒绝，其维持的大量流仍然会消耗内核的socket buffer和文件描述符。建议调整以下内核参数：

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 5000

这些参数能提升服务器在遭受突发流量时的缓冲能力，但更重要的是限制单连接的资源占用。使用HAProxy或Envoy作为反向代理时，可以在代理层直接对HTTP/2连接做流控。HAProxy从2.0版本开始支持HTTP/2的流限速：

frontend https_in
    bind :443 ssl crt /etc/ssl/cert.pem alpn h2,http/1.1
    http-request set-var(txn.client) src
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }

这种配置在代理层就按来源IP做请求速率限制，恶意流量在到达后端之前就被丢弃。Envoy则可以通过HTTP connection manager的stream_idle_timeout和max_concurrent_streams来精确控制。

HTTP/2攻击工具通常使用特定的TLS库，其握手特征与真实浏览器存在明显差异。JA3和JA4指纹技术可以识别客户端TLS协商时的密码套件、椭圆曲线参数和扩展字段组合。通过在CDN或反向代理层集成JA3指纹库，可以直接在TLS握手阶段识别并拦截已知攻击工具的流量。

部署时，可以将JA3指纹与IP信誉库联动。例如，某个IP使用Python requests库的JA3指纹，却声称自己是Chrome浏览器，这种不一致直接触发拦截。目前主流的做法是在Nginx上通过模块或Lua脚本获取JA3指纹，然后查询本地或远程指纹库进行判断。这种防御手段对HTTP/2多路复用攻击尤其有效，因为攻击工具很难完美模拟浏览器的TLS指纹，且指纹检测在请求处理之前完成，资源消耗极低。

对于穿透协议栈和TLS指纹检测的高级攻击，需要在业务层引入动态验证。最有效的方式是302重定向配合Cookie挑战。当某个来源的请求速率或流密度超过阈值时，暂时将所有请求重定向到一个验证页面，要求客户端执行JavaScript计算并回传Token。HTTP/2多路复用攻击工具通常不具备完整的JavaScript执行环境，无法通过验证，后续请求会被直接丢弃。

这种机制可以集成在CDN边缘节点，也可以部署在反向代理层。关键是阈值设置要足够灵敏，避免正常用户在突发访问时被误伤。建议采用滑动窗口算法，统计最近1到5秒内的流创建速率，超过阈值即触发挑战，验证通过后将该IP或会话加入白名单，有效期设置为10到30分钟。

面对HTTP/2多路复用攻击，传统的监控指标需要扩展。除了QPS和连接数，必须增加单连接平均流数、单连接最大流数、流创建速率和HPACK解压失败次数等指标。Nginx的stub_status模块不提供这些数据，需要结合VTS模块或通过解析访问日志中的HTTP/2相关变量来获取。

在日志中记录connection和stream标识，可以事后分析攻击特征。Nginx配置中可以添加：

log_format h2 '$remote_addr - $http2_stream_id - $request_time';
access_log /var/log/nginx/h2_access.log h2;

通过分析stream_id的分布，能快速识别单连接高并发流的异常行为。正常用户的stream_id分布均匀，而攻击流量会在短时间内出现大量密集的stream_id。

告警规则应基于流速率突变。例如，正常情况下单连接并发流数不超过50，突然出现单连接并发流超过500的情况，即使总QPS没有明显上升，也应触发告警。这种告警逻辑能比传统QPS告警提前数分钟发现攻击。

将HTTP/2终结前置到专门的代理层，后端服务仅处理HTTP/1.1或内部协议，可以在代理层集中做流控和安全检测。这种架构下，即使攻击者打满代理层的HTTP/2流，后端服务也不会直接暴露在协议栈压力下。代理层可以使用C语言编写的高性能组件，如H2O或nghttp2，它们在处理大量流时有更好的内存效率。

另外，Anycast网络和分布式防御仍然是应对大流量CC攻击的有效手段。通过将攻击流量分散到多个边缘节点，每个节点独立做流控和验证，可以成倍提升整体防御容量。结合BGP FlowSpec，可以在网络层直接丢弃来自特定源的攻击流量，但这需要上游ISP的支持，适用于超大规模攻击场景。

HTTP/2多路复用放大的本质是攻击者用极低的协议开销撬动防御方巨大的资源消耗。防御的关键不是追求绝对的协议安全，而是通过多层限速、指纹识别和动态验证，将攻击成本拉高到攻击者无法承受的水平。每一层防御都在增加攻击者的实现复杂度，最终让自动化工具无法规模化地发起有效攻击。