HTTP慢速攻击如何用极低速率耗尽连接池，慢速攻击原理是什么

HTTP慢速攻击靠极低速率发送数据占用服务器连接，让连接池在无声无息中填满耗尽，逼得服务器拒绝所有新访客这不是流量轰炸，而是一场“耐心”的消耗战。

HTTP慢速攻击怎么做到“偷”走连接池

要理解这个攻击，得先搞明白连接池是什么，服务器为了省去反复握手的开销，把建立的TCP连接放在一个池子里复用，连接池是有容量上限的，就像餐馆的座位数一样，坐满了,后来的客人只能排队等位。

慢速攻击干的事，就是一个人占着桌子，既不点菜，也不付钱，就慢慢嘬那杯水，具体的做法是：攻击者建立大量TCP连接，然后以极慢的速率向服务器发送数据，每个连接只发一点点数据，刚好维持在服务器超时阈值之内，让服务器觉得“这个连接还有活，不能释放”。

以经典的Slowloris攻击为例，攻击者建立HTTP连接后，持续发送不完整的HTTP请求头，例如每隔几十秒发送一行随机字段，让服务器一直等待请求完成，服务器为每个连接分配了线程、内存和文件描述符，连接池被这些僵尸连接占满,正常用户的请求就进不来了。

从TCP层到应用层，慢速攻击的三种常见变形

慢速攻击家族不只有Slowloris一个成员,业内通常把它们分成三类：

• Slowloris（慢请求头）：发送不完整的HTTP头部，让服务器等待请求结束,Apache和Nginx早期版本容易中招。
• 慢请求体（Slow Post）：发起POST请求，把Content-Length声明得很大,然后以极慢的速度一点点发送请求体内容。
• 慢读取（Slow Read）：客户端正常发起一个大文件下载请求，但故意把TCP接收窗口调得很小，导致服务器发送的数据卡在缓冲区里,传输长时间无法完成。

这三类攻击本质上都在做同一件事：占据连接不放，慢慢消耗资源，区别在于慢的是请求头、请求体还是读取速度。

行业共识认为，这类攻击在2010年前后开始大规模出现，当时CVE-2012-0217等漏洞让不少知名开源服务器陷入被动，后来各大Web中间件厂商陆续做了补丁加固,但依然有大量对性能不做调优的站点暴露在风险中。

慢速攻击检测方法与误报处理

识别慢速攻击比识别普通DDoS流量难得多，高带宽DDoS一眼就能看出来，因为流量曲线异常陡峭，而慢速攻击的流量特征接近正常用户的弱网行为,甚至比普通用户上网产生的流量还小。

检测手段主要依赖以下几个维度：

1. 连接时长分布：正常用户访问一个页面通常几秒到几十秒完成交互,慢速攻击的连接往往维持几分钟甚至几小时。
2. 请求完成率：统计单位时间内完成的HTTP请求数与连接数的比值，正常情况比值较高，慢速攻击时大量连接“只挂机，不干活”。
3. 连接状态堆叠：查看服务器上的CLOSE_WAIT、ESTABLISHED状态的连接数量，如果短时间内积累大量ESTABLISHED连接且每个连接的收发字节数极低,那就是典型的慢速攻击特征。
4. IP分布规律：慢速攻击通常使用大量IP分散流量，但连接建立时间高度集中,存在明显的时间同步特征。

排查过程中常见的三个误判

实践中不少管理员会误判慢速攻击为CC攻击或者DDoS攻击，进而用了完全错误的防御策略,以下几点在处置时值得留意：

• 误判为网络故障：服务器资源占用不高但访问很慢，容易让人以为是带宽或路由问题，实际是连接池满了,新连接无法建立。
• 误判为CC攻击：CC攻击通常伴随大量应用层请求，CPU和数据库负载很高，慢速攻击下CPU负载往往不高,但连接数持续高位。
• 误判为正常爬虫：部分搜索引擎爬虫和监控工具请求速率很慢，容易与慢速攻击混淆,需要在检测中叠加UA识别和行为基线。

HTTP慢速攻击怎么防御才有效

防御慢速攻击，思路要从“堵”转向“耗”，攻击者赌的是服务器不愿意主动断开连接，那我们就在协议规则允许的范围内,制定更严格的连接管理策略。

应用层：在Web服务器层面做细粒度限制

以Nginx为例,有几项参数直接决定服务器对慢速请求的容忍度：

client_header_timeout 10s;
client_body_timeout 10s;
keepalive_timeout 15s;
server_tokens off;

其中client_header_timeout控制读取请求头的最长等待时间，设置过短会误伤弱网用户，设置过长又给攻击者留了窗口，通常在10-30秒之间取舍，对于慢请求体攻击，还可以限制client_body_size来减少缓冲占用。

Apache环境下,对应的配置是：

RequestReadTimeout header=10-20 body=10-30
Timeout 30

这些配置的意图很明确：不再无限等待，规定时间内请求没完成就主动断开,占着茅坑不拉屎的会被请出去。

网络层：用负载均衡器和云防护前置

单靠Web服务器自带参数往往不够，比较稳妥的做法是把防护能力前置到负载均衡设备或云服务上，行业共识认为，这层防护的核心是去同步和限速：

• 在LB层对单IP设置每秒新建连接数限制,防止单点大量建连。
• 开启TCP栈的更加激进的超时策略，对超过N秒无数据载荷的连接发送探测包,必要时重置连接。
• 网关层开启HTTP规范化校验，拒绝畸形头部字段,减少协议解析层面的消耗。

目前主流的云厂商都提供应用层DDoS防护，防护策略中内置了慢速攻击识别模块，关于云防慢速攻击价格，一般在基础流量包之上叠加按QPS或防护域名数计费，不同厂商差异较大，通常从每月几百到几千元区间,具体取决于防护带宽和域名数量。

架构层面：无状态化改造是治本之策

不少高并发站点已经做了无状态改造，连接被多个实例拉平，单台服务器被拖垮后负载均衡会自动剔除节点，内部维持长连接的组件即使被攻击，只要节点可横向扩展，业务整体不受影响,这种架构本身就对连接类攻击有较高的免疫力。

常见问题：慢速攻击多久能拖垮一台服务器？

慢速攻击多久能拖垮一台服务器？
这取决于连接池上限和超时配置的严格程度，默认配置下，Nginx和Apache的worker进程数通常在几百到上千的规模，攻击者用几百个慢速连接就能占满大多数默认配置的worker，实际攻击见效时间往往在几分钟到几十分钟之间，具体与服务器的并发规格有关，配置了严格超时和连接数限制的服务器,攻击成本会大幅上升。

慢速攻击和DDoS攻击有什么区别？
DDoS攻击靠海量流量或请求冲击网络带宽和应用层资源，特征明显，慢速攻击走的是“少而慢”的路线，占用的是连接资源而不是带宽，流量密度低，传统DDoS清洗设备未必能识别出来，两者的防御策略侧重点不同，前者需要扩大带宽和清洗流量,后者讲究连接池的精细化管理。

网站被慢速攻击了有什么征兆？
最典型的征兆是：服务器CPU和内存占用不高，但网站突然打不开或响应极慢，查看连接数时会发现大量处于ESTABLISHED状态的连接，而每个连接几乎没有数据传输，另一个信号是重启Web服务后网站马上恢复，过一会儿又变慢，这说明攻击者在持续建连,而不是一次性打进来。

慢速攻击的防御本质上是和攻击者比耐心，比谁更愿意先放手，合理配置超时参数、建立连接数基线、借助成熟的防护资源,就能把这类攻击挡在门外。