慢速攻击不是靠流量洪水淹没服务器，而是用极慢的请求速率长时间霸占连接，把应用服务的连接池、线程池和文件句柄一点点耗光，最终让正常请求排队到超时。
慢速攻击和DDoS的区别在哪？一个像洪水，一个像慢性病
传统DDoS打的是带宽和请求量,几百G的流量瞬间涌进来，机房入口就被堵死，慢速攻击走的是另一条路：流量小到几乎可以忽略，单个IP可能只吃几Kbps，但它建立的每一个连接都故意不结束，把服务器有限的连接名额全部占住。
比较直观的理解是：
- 传统DDoS像一群人同时冲进营业厅,把大门堵得水泄不通。
- 慢速攻击像少数人坐在窗口前,每隔半分钟才说一个字，窗口永远轮不到下一个人。
从技术上看,常见的慢速攻击有三类：
- Slowloris：对服务器发起大量TCP连接，每个连接只发送不完整的HTTP请求头，服务器一直等头结束，连接被悬置。
- Slow POST：请求头里声明一个很大的
Content-Length，但正文每次只发一个字节，发送过程可以拖到几分钟甚至几小时。 - Slow Read：客户端把TCP接收窗口设得极小，服务器想返回响应也写不出去，于是连接、缓冲区和业务线程一起被拖住。
据OWASP公开资料,这几类都归入应用层拒绝服务攻击，共同点是攻击成本极低、隐蔽性强。
| 对比维度 | 传统DDoS | 慢速攻击 |
|---|---|---|
| 流量大小 | 大，可能打满带宽 | 极小，带宽占用几乎不变 |
| 攻击目标 | 网络层、传输层 | 应用层连接资源 |
| 单IP特征 | 包量异常高 | 连接多但包数少 |
| 服务器CPU | 往往升高 | 多数情况下CPU不高 |
| 防御重点 | 流量清洗、扩容 | 超时、并发限制、速率控制 |
为什么传统防火墙对慢速攻击经常失灵
多数防火墙和DDoS清洗设备按流量阈值或包速率触发策略,慢速攻击每个连接的包间隔可以拉到十几秒，包量很小，流量图上看不出异常，防火墙一看，带宽没打满，CPU也不算高，就放过去了，等到业务侧出现大面积超时，攻击可能已经持续了相当一段时间。
网站被慢速攻击什么症状？先别急着重启服务器
很多运维第一次遇到慢速攻击,第一反应是重启服务器，重启确实能短暂清空连接，但攻击者只要不停止发包，几分钟后症状会再次出现。
更典型的症状是这些：
- 网站页面长时间转圈,但
ping不丢包，带宽曲线也很平稳。 - 登录接口、API接口随机返回
502、504。 - 用
ss -tan state established | wc -l一看，连接数顶到了上限。 - 错误日志里反复出现
request timed out reading client request body
client sent too long header line。 - 磁盘IO、CPU、内存并没有明显瓶颈，但正常请求就是进不来。
可以跑一条基础命令快速判断：
ss -tan state established | awk '{print $4}' | sort | uniq -c | sort -rn | head
如果某个源IP对同一个端口建立了大量长连接,并且这些连接长时间不释放，就要高度怀疑慢速攻击。
判断是不是慢速攻击，看这三个时间差
- 连接建立时间：TCP握手完成后，请求是否长时间不进入正文传输。
- 请求体发送持续时间：一个POST请求是否用了几十秒甚至几分钟才发完几KB数据。
- 响应传输时间：服务器已经生成响应，但客户端读取极慢，导致连接长时间处于写等待状态。
大量连接卡在“读取请求头”或“读取请求体”阶段，是慢速攻击最典型的特征。
慢速攻击是怎么一点点拖垮应用服务的？从连接池到线程池的挤占链条
一台应用服务器可以理解成一个窗口数量有限的办事大厅,每来一个请求，就分配一个窗口和一名办事员，正常情况下，用户把材料一次递完，窗口很快办结。
慢速攻击者进来之后,材料递一半就停住，窗口不能关，办事员只能等，一个攻击者可以占用几十个窗口，几十个攻击者就能让整个大厅瘫痪，后面排队的正常用户只能等超时。
这条挤占链条在技术实现上很具体：
- 每个TCP连接建立后,内核要分配socket缓冲区，占用文件描述符。
- Nginx或Apache为连接分配worker进程或线程,Apache的prefork模式下，一个连接往往对应一个进程，默认能处理的并发请求数有限。
- 应用服务到数据库的连接池同样是稀缺资源,慢速请求把业务线程长时间阻塞在等待请求体的阶段，数据库连接就被挂在半空，其他请求拿不到连接后直接报错。
- 容器或云主机环境中,文件描述符耗尽时会出现
too many open files，连健康检查接口都可能失败，负载均衡把节点摘掉，服务直接不可用。
行业共识认为,慢速攻击最大的破坏不在于单次请求的复杂度，而在于它专门攻击服务器“等待”的耐心，任何没有设置硬超时的环节，都会被它利用。
Apache和Nginx被Slowloris拖垮的路径差异
Apache的prefork模式在默认配置下,一个慢速连接足够占住一个进程，攻击者只要建立几百个连接，就能把MaxRequestWorkers占满，Nginx对请求头读取有默认缓冲机制，相对能扛一些，但如果client_body_timeout没有显式设置，遇到Slow POST同样会被慢慢耗尽worker连接。
所以不能简单说某个中间件“天然免疫”，关键还是看是否针对慢速行为做了超时和并发约束。
应用层慢速攻击检测方法：盯住连接时长而不是流量峰值
只看流量图,慢速攻击基本就是一条直线，真正有用的信号是连接维度：
- 活跃连接数是否长时间接近上限。
- 单个IP建立的连接数是否异常偏高。
- 连接的平均持续时间是否明显变长。
- 请求体传输速率是否极低。
实操检测可以分几步走：
统计当前连接数和每个IP的连接数：
ss -tanp | grep ':80' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
- 查看Nginx访问日志里的
$request_time，找出处理时间异常长的请求：
log_format slow '$remote_addr - $request_time $request'; access_log /var/log/nginx/slow.log slow;
- 用
tcpdump抓取80端口的包，观察同一连接内两个数据包的时间间隔，正常HTTP请求的包间隔很短，慢速攻击的间隔可能长达十秒以上：
tcpdump -i eth0 -nn 'tcp port 80 and (tcp[13] & 0x08 != 0)' -l
在监控平台对“活跃连接数/带宽”的比值设置告警，带宽没涨但连接数顶格，基本就是慢速行为。
Wireshark怎么看出慢速攻击特征
抓包后直接过滤http.request，按连接流查看时间列，如果大量TCP流长时间处于半开或半关闭状态，每个请求包之间间隔均匀且偏长，就符合慢速攻击的流量特征，这个方法适合事后留存证据，实时拦截还是得上防护配置。
慢速HTTP攻击解决方案：参数调优是地基，WAF是外墙
慢速攻击能得手,多数是因为服务器“太有耐心”，解决方案的核心思路只有一句话：给每个等待环节设置不可商量的小超时和硬上限。
Nginx防慢速攻击怎么配置
直接在http块或server块加入：
client_header_timeout 10s; client_body_timeout 10s; keepalive_timeout 30s; limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20; limit_req_zone $binary_remote_addr zone=req:10m rate=30r/s; limit_req zone=req burst=50 nodelay;
保存后执行nginx -t校验配置，再systemctl reload nginx，这样单个IP并发连接超过20就会被拒绝，请求头和请求体超过10秒没发完就断开。
Apache防慢速攻击配置
启用mod_reqtimeout模块，加入类似配置：
RequestReadTimeout header=10-20,MinRate=500 body=10-20,MinRate=500
同时把Timeout和KeepAliveTimeout调低，避免一个连接长期占用进程。
Tomcat和应用层连接池配置
Tomcat的Connector设置：
<Connector port="8080" connectionTimeout="10000" maxThreads="200" />
数据库连接池也要检查maxWait、removeAbandonedTimeout等参数，防止业务线程无限等待连接。
这些自建手段基本不需要额外软件费用,但需要运维对参数理解到位，改错超时时间可能影响大文件上传或慢网络用户，所以上线前要在测试环境验证。
慢速攻击防御成本怎么算？自建规则和上云防护的账要这样算
慢速攻击的防御成本可以很低,也可以很省心，关键是看业务容忍多长时间的不可用。
- 自建Nginx参数调优：软件成本为0，主要花运维半天到一天时间，适合中小站点和具备服务器权限的团队。
- 开源WAF方案：ModSecurity配合自定义规则，部署和调优需要一到三天，规则需要定期更新。
- 商业WAF防护：按防护域名数、带宽和地域节点收费，北京地区服务器接入商业WAF时，通常可以选择就近的北京防护节点，额外延迟只有几毫秒到十几毫秒，入门级套餐年费从几千元起步，高防套餐可能到几万元一年。
- 游戏服务器或API接口场景：这类业务对延迟敏感，一旦被慢速攻击拖住，玩家掉线或接口超时带来的损失按分钟计算，此时接入商业WAF或云厂商的应用层防护，通常比纯粹自建更划算。
业内专家指出,慢速攻击的防御不是一次性项目，而是需要在超时、并发、速率限制和应用层监控之间形成组合，单靠某一个参数，很容易被攻击者换一种慢法绕过。
关于慢速攻击的常见问题
慢速攻击一般持续多久才能拖垮服务器？
没有固定时长,主要取决于服务器连接池大小、中间件超时配置和攻击者维持的连接数，多数情况下，如果服务器没有针对慢速请求做硬超时，攻击者在几分钟到几十分钟内就能把连接数顶满，攻击者只要维持低速发包，正常用户就会被持续挤在排队队列外面，直到业务完全不可用。
nginx防慢速攻击怎么配置？
核心配置是限制请求头和请求体的读取超时,以及限制单IP并发连接数和请求速率：
client_header_timeout 10s; client_body_timeout 10s; limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20; limit_req_zone $binary_remote_addr zone=req:10m rate=30r/s; limit_req zone=req burst=50 nodelay;
保存后执行nginx -t确认配置正确，再执行systemctl reload nginx让配置生效，配置完成后，单个IP并发连接超过20条会被拒绝，请求头或请求体超过10秒仍未完成传输的连接会被直接断开。
慢速攻击和CC攻击的区别是什么？
CC攻击属于应用层DDoS,攻击者通常控制大量肉鸡模拟正常请求，短时间内制造高频率访问，主要消耗目标服务器的CPU、数据库和带宽，慢速攻击则不一定需要大量请求，它靠少数连接长时间占用连接池和线程，带宽和CPU往往不高，但正常请求无法获得连接资源，两者最终都会导致网站无法访问，但检测指标和防御重点不同：CC攻击重点看请求频率和验证码拦截，慢速攻击重点看连接时长、超时设置和并发限制。