流量小得可怜，却能精准卡死应用。它不是靠海量请求淹没服务器，而是用极低速率、长时间不完整的连接占满连接资源，当连接池被耗尽时，正常用户的请求只能排队甚至被直接拒绝。 这种攻击拼的不是带宽,而是耐心和连接数。
为什么慢速攻击能用“少量流量”拖垮应用
很多运维人员第一次遇到这种攻击时都会困惑：带宽监控曲线几乎是平的，CPU和内存占用也不高，网站却大面积打不开,问题就出在服务器的连接处理机制上。
服务器为每个进来的HTTP连接分配线程、进程或内存槽位，一个普通的Apache或Nginx工作进程，能同时处理的连接数是有上限的，即使物理带宽还剩很多，连接槽位一旦占满,新的请求就进不来。
慢速攻击正是利用了这个软肋，攻击者不急着把请求发完，而是每隔十几秒才发一小块数据，或者干脆把请求头写一半就停住，让服务器一直等，服务器以为客户端网络不好，好心保持连接不释放，于是大量连接被这些“半死不活”的会话吊住。
用餐厅来打比方：一家店只有二十张桌子，如果每张桌子都坐着一个只点一杯白水、一坐就是四小时的顾客，门口排队的正常食客自然进不来,慢速攻击就是这样把应用拖垮的。
连接资源消耗的三种常见方式
- 不完整请求头：攻击者发送一个HTTP请求头，故意不发送结束标志，服务器等待剩余的头字段,连接一直被占用。
- 极慢的请求体：攻击者声明一个很大的
Content-Length，然后以极慢的速度发送body，服务器预留连接等待完整数据,线程无法释放。 - 慢速读取响应：攻击者正常发送请求，但读取响应时把TCP窗口调得很小，导致服务器发送缓冲阻塞,连接长时间无法结束。
这些方式共同的特点是：单个连接产生的流量很小，但占用的服务器资源却很实在，当攻击者同时发起数百条这样的连接，服务器很快就会进入“连接饥饿”状态。
慢速攻击和CC攻击区别在哪里
很多站长会混淆慢速攻击和CC攻击，因为它们都能让网站打不开，但原理完全不同，把两者拆开看,防御思路才不会跑偏。
| 对比维度 | 慢速攻击 | CC攻击 |
|---|---|---|
| 流量特征 | 流量很低，连接时间长 | 请求量大，流量相对较高 |
| 攻击目标 | 连接槽位、线程、超时机制 | CPU、数据库、动态页面处理能力 |
| 资源消耗点 | 连接数、内存、文件描述符 | 服务器计算资源、后端接口 |
| 请求完整性 | 大多不完整或极慢 | 多数是完整请求 |
| 常见表现 | 连接数激增，带宽空闲 | 带宽或CPU飙升，访问变慢 |
| 防御重点 | 超时时间、连接数限制、最小传输速率 | 频率限制、验证码、行为分析 |
简单说，CC攻击是“人多势众”，用大量请求砸向应用；慢速攻击是“赖着不走”，用极少数连接占住关键位置，一个拼速度,一个拼时长。
服务器被慢速攻击有哪些症状
服务器是否正在遭受慢速攻击,可以从几个反常现象入手判断。
- 连接数很高，流量很低：这是最典型的信号。
netstat里能看到大量ESTABLISHED连接,但带宽监控几乎没有波动。 - 服务无法访问，但重启后短暂恢复：重启服务会强制断开所有慢速连接，所以刚重启完正常一小段时间,很快又被占满。
- 日志里出现大量超时记录：Nginx或Apache错误日志中频繁出现
client timed out、connection reset等记录。 - 正常用户访问极慢或直接超时：浏览器一直转圈，最终出现504、502或连接重置。
- CPU和内存不一定高：多数情况下服务器系统资源看起来并不紧张,但连接表已经满了。
如果一个网站既没有流量突增，也没有明显的高CPU报警，却大面积打不开,第一时间应该排查连接数是否被慢速连接占满。
慢速攻击怎么防御：从Timeout到反向代理
防御慢速攻击的核心思路只有一条：不让任何连接无限期占用资源，围绕这条思路,可以按层设置防线。
Nginx防慢速攻击的关键参数
Nginx是目前使用最广的反向代理和Web服务器，它自带几个超时参数非常适合对抗慢速攻击，建议在http块或server块中进行调整。
client_header_timeout 5s; client_body_timeout 10s; keepalive_timeout 10s; send_timeout 10s; lingering_timeout 5s;
各参数作用：
client_header_timeout：客户端必须在指定时间内发完请求头，调小后,慢速发头的连接会被快速断开。client_body_timeout：客户端发送请求体的超时时间,适合对抗慢速POST。keepalive_timeout：长连接保持时间,减少空闲连接占用时间。send_timeout：服务端发送响应的超时时间,用于对抗慢读攻击。lingering_timeout：处理关闭连接时的残留数据时间。
限制单个IP的并发连接数也是有效手段。
limit_conn_zone $binary_remote_addr zone=slowconn:10m; limit_conn slowconn 10;
这样同一IP最多同时保持10个连接，慢速攻击需要大量连接才能造成威胁,限制并发后攻击效果会大幅下降。
Apache与IIS的调整思路
Apache用户可以启用mod_reqtimeout模块,核心参数包括：
RequestReadTimeout header=5-10,MinRate=500 body=10-20,MinRate=500
这表示请求头必须在5到10秒内读完，且最低速率不能低于每秒500字节，达不到就断开连接，对于慢速POST，可以用LimitRequestBody限制请求体大小，防止攻击者声明极大的Content-Length。
IIS服务器则可以在站点级别调整连接超时时间和头读取超时，将默认的较长时间缩短到10秒左右,同时可以配合Windows防火墙限制单个IP的并发半开连接数。
反向代理与WAF的缓冲价值
把Nginx或HAProxy放在应用前面，让反向代理先把请求完整收下来，再转发给后端，这是很实用的一层防护，慢速请求在代理层就会被超时断开,根本到不了应用服务器。
WAF设备或云防护服务也能识别慢速攻击特征，比如请求头发送间隔异常、传输速率持续过低等，行业共识认为，多层防护组合比单点设置更可靠,因为攻击者会不断调整发包节奏来绕过单一阈值。
慢速攻击检测工具与排查思路
排查慢速攻击不需要复杂的商业软件,几条命令和开源工具就能定位问题。
用netstat和ss统计异常连接
登录服务器后先看当前连接状态：
netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
如果某个IP建立了大量ESTABLISHED连接，且这些连接持续时间很长,就需要重点关注。
使用ss命令可以查看连接的详细状态和持续时间：
ss -tan state established
观察Recv-Q和
Send-Q列，如果大量连接的Recv-Q数值很小但状态长期不结束，说明数据接收速率非常慢,符合慢速攻击特征。
抓包确认慢速行为
用tcpdump抓取可疑IP的流量：
tcpdump -i eth0 host 可疑IP -w slow.pcap
之后用Wireshark打开分析，主要看HTTP请求是否长时间不完整，或者TCP窗口是否持续很小，慢速攻击的包间隔通常很有规律，比如每隔10秒或15秒发一次数据,就是为了刚好卡在服务器超时阈值之内。
用慢速攻击工具验证防御效果
slowhttptest是一款开源的压力测试工具，可以模拟Slowloris、慢速POST和慢读攻击，运维人员可以在测试环境用它对目标服务器发起慢速请求,然后观察连接数变化和防御参数是否生效。
slowhttptest -c 200 -H -g -o slowloris_report -i 10 -r 200 -t GET -u http://目标地址
参数含义大致是：200个连接、10秒间隔、每次发送200字节，如果防御配置正确,这些连接应该在几秒内被服务器主动断开。
Q&A：慢速攻击相关问题解答
慢速攻击对网站影响多大？
慢速攻击如果持续成功，影响会从局部蔓延到整体，刚开始可能只是登录、支付等需要较长连接的业务变慢，随后连接表被占满，整个域名下的页面都无法访问，对于依赖长连接的API接口、WebSocket应用，影响会更明显，由于流量小，很多基础监控不会触发告警,攻击往往能持续较长时间。
怎么判断服务器被慢速攻击还是CC攻击？
先看流量和连接数，CC攻击通常伴随明显的请求量上升，带宽或CPU会有波动；慢速攻击的流量曲线上几乎看不到变化，但连接数会异常偏高，再看日志里的请求是否完整，CC攻击大部分是完整的HTTP请求，慢速攻击则普遍存在不完整请求或极低传输速率，最后看单个IP的行为，慢速攻击的IP连接数不一定多,但每个连接持续时间特别长。
慢速攻击检测工具哪个更有效？
没有单一工具能解决所有问题，实际排查中通常是组合使用。netstat和ss负责快速查看连接数量和来源IP，tcpdump用于深入确认慢速行为特征，slowhttptest适合在测试阶段验证防御配置，把这些工具配合起来，基本可以完成慢速攻击的发现、取证和防御验证，慢速攻击检测最终依赖的是对连接行为持续观察,而不是某一款独立软件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637347.html
