慢速攻击在低带宽下仍能瘫痪服务，根本原因不在于“流量大小”，而在于它用极少的连接数长时间占住服务器的工作线程和连接池，让有限的计算资源被“熬干”，而不是被“冲垮”。换句话说，带宽越小，单条连接占用的资源比例越突出，慢速攻击的杠杆效应就越明显几十个、几百个低速连接,足以让一台小带宽服务器寸步难行。
慢速攻击为什么在低带宽下更危险
很多运维同学有个直觉：带宽小，攻击者能打进来的流量也少，应该更安全才对，事实恰好相反，低带宽场景下慢速攻击的性价比高得离谱，要理解这件事,先得看清慢速攻击和流量型攻击的本质差别。
慢速攻击与流量型DDoS的本质区别
流量型DDoS打的是“吞吐”，拼的是谁管道粗、谁清洗能力强，攻击者需要大量肉鸡同时发大包，成本高、动静大，慢速攻击打的是“并发”和“时间”，攻击者只需要一台普通电脑，就能用几十个连接把服务器拖进泥潭，业内专家指出，慢速攻击的典型特征是单连接速率极低、连接存活时间极长，服务器的大量线程被挂在“等他发完”的状态上,迟迟等不到完整请求。
用更直白的话说，流量型攻击像一群人堵在门口往店里冲，而慢速攻击更像几十个人进了店，每人占一张桌子，点一杯白开水,一坐一整天。
低带宽环境下的资源杠杆效应
低带宽服务器的资源配置本来就不宽裕，假设一台入门级云服务器只有2兆带宽、几百兆内存、有限的worker进程，正常情况下跑一个小网站绰绰有余，可慢速攻击一旦开动,情况就变了：
- 连接池被迅速占满：Nginx、Apache这类服务默认允许的并发连接数就那么几百个，攻击者用Slowloris手法发一半请求头就停住,连接一直挂着不释放。
- 工作线程被拖住：每个连接都要占用一个worker进程或线程去等数据，线程数一满,正常用户连进来也只能排队。
- 带宽占用反而很小：攻击者每次只发几个字节，2兆带宽根本用不满，监控上的带宽曲线平平无奇，运维人员看着一片“安静”,实际上服务已经不可用。
低带宽服务器就像一间小面馆，桌子本来就不多，慢速攻击的做法是每桌坐一个人只点一碟花生米，从开门坐到打烊，翻台率直接归零。
慢速攻击到底卡住了服务器的哪些命门
理解了杠杆效应，我们再往下拆一层，看看服务器在低带宽下被慢速攻击掐住的几个关键环节,这也是很多运维人员排查时容易忽视的地方。
连接队列与半开连接堆积
TCP握手的半连接队列（SYN queue）和全连接队列（accept queue）容量都有限，慢速攻击的变种，比如慢速HTTP头攻击，会在建立连接后迟迟不发完整头部，导致连接被accept后一直挂在worker上，另一类Slow POST攻击则是在请求体里以极慢的速度发送数据，服务端按Content-Length等它发完,等上几分钟甚至几十分钟。
- Nginx默认的
client_header_timeout是60秒，client_body_timeout也是60秒，攻击者只要在每个超时窗口内发一两个字节,就能一直续命。 - Apache的
Timeout和KeepAliveTimeout如果配置宽松,同样会被利用来维持长连接。
这些参数在带宽充足的大集群里问题不大，因为资源池厚，但在小带宽机器上，几个参数没调好,几十个慢连接就能把服务拖到无响应。
后端应用与数据库的连带压力
慢速攻击往往不止打在Web层，当一个慢请求被转发到后端应用，应用可能正在等数据库响应、等缓存返回、等外部接口，线程池同样被占用，低带宽服务器通常复用同一台机器跑应用和数据库，资源争抢更加剧烈，行业共识认为，慢速攻击造成的瘫痪往往是“连锁反应”，前端连接堆积引发后端线程池耗尽,最后整个链路雪崩。
中小城市企业如何应对慢速攻击
很多中小城市的中小企业、门店、工厂官网，预算有限，租的是低带宽云主机，运维力量也薄，这类场景正是慢速攻击的重灾区，因为攻击成本低、防范意识弱、监控不到位。
先做减法：收紧超时参数
最直接、零成本的一步，是把Web服务的超时参数收紧到合理范围，以Nginx为例，可以在nginx.conf的http或server块中设置：
client_header_timeout 10s; client_body_timeout 10s; keepalive_timeout 15s; send_timeout 10s;
Apache用户可以检查httpd.conf：
Timeout 15 KeepAliveTimeout 5 MaxRequestWorkers 150
参数不是越小越好，要结合业务实际响应时间，但把默认的60秒压到10到15秒，已经能大幅提高慢速攻击的“续命”成本。
限制单IP并发与请求速率
用Nginx的limit_conn和limit_req模块可以给每个IP设并发上限，超出直接回503,示例配置：
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_req_zone $binary_remote_addr zone=perreq:10m rate=5r/s;
server {
limit_conn perip 10;
limit_req zone=perreq burst=20 nodelay;
}
配合iptables对明显异常的源IP做限速,能进一步压住攻击面。
用监控日志把隐形攻击“显形”
低带宽下慢速攻击最隐蔽的地方是带宽曲线不报警，建议重点盯这几个指标：当前ESTABLISHED连接数、单个IP连接数排名、请求平均处理时长、worker进程占用率,Linux下常用排查命令：
ss -s看整体socket统计netstat -an | grep :80 | wc -l统计80端口连接总数netstat -an | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head找连接数异常的源IP
把这些命令写进定时脚本，超过阈值就告警,比盯着带宽图靠谱得多。
慢速攻击防护成本高吗
这是中小企业最关心的问题，防护成本取决于攻击规模和业务重要性,大致分几档：
| 防护方式 | 投入水平 | 适用场景 |
|---|---|---|
| 参数调优+限流 | 基本零成本 | 低带宽小站、攻击量不大 |
| 云WAF基础版 | 按年付费，相对可控 | 有公开业务、需要可视化 |
| 高防IP/清洗中心 | 费用较高 | 攻击频繁、业务不能停 |
多数情况下，先把免费的超时和限流做扎实，能挡掉相当一部分自动化慢速攻击脚本，真遇到持续攻击，再考虑按需采购云WAF或高防服务,避免一上来就买最贵的方案。
关于慢速攻击的常见疑问解答
慢速攻击和普通DDoS攻击到底有什么区别？
普通DDoS以流量洪峰为目标，靠大包和并发量瞬间压垮带宽或设备；慢速攻击以连接时长为武器，单连接流量极低，靠占用连接池、线程池和等待时间拖垮服务，前者拼带宽，后者拼耐心，防护思路也完全不同慢速攻击更依赖超时控制、连接数限制和行为分析。
带宽只有几兆的服务器需要专门防慢速攻击吗？
需要，恰恰因为带宽小、资源池薄，几十个慢连接就能让服务不可用，建议至少完成三件事：收紧Web服务的超时参数、限制单IP并发连接、建立连接数监控告警，这三步不花额外费用,能覆盖大部分低强度慢速攻击场景。
慢速攻击防护是不是一定要买高防IP？
不一定，高防IP主要解决大流量清洗，对慢速攻击的针对性有限，低带宽场景下，优先做本地参数调优和行为限流，再根据实际攻击频率和业务中断代价，评估是否叠加云WAF或高防服务，攻击尚未发生时，把基础配置和监控做到位,往往比直接购置高防更划算。
慢速攻击的可怕之处，从来不是它带来了多少流量，而是它精准地利用了“等待”这件事本身，带宽越小的服务器，越经不起这种慢性消耗，把超时收紧、把连接管住、把监控盯牢,才是低带宽环境下最实在的防线。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785438.html
