摘要：# 慢刀子割肉：CC慢攻击，为什么你流量正常业务却崩了？ 我前两天帮一个做电商的朋友看服务器，他一脸懵地问我：“奇了怪了，带宽没跑满，CPU内存也正常，但用户就是死活打不开商品页，后台登录也卡成PPT。这算哪门子攻击？” 我看了眼监控图，流量曲线平稳得…

慢刀子割肉：CC慢攻击，为什么你流量正常业务却崩了？

我前两天帮一个做电商的朋友看服务器，他一脸懵地问我：“奇了怪了，带宽没跑满，CPU内存也正常，但用户就是死活打不开商品页，后台登录也卡成PPT。这算哪门子攻击？”

我看了眼监控图，流量曲线平稳得跟心电图似的——这恰恰就是问题所在。很多老板以为攻击就是洪水猛兽，流量瞬间飙红，实际上，最高明的攻击，往往静悄悄。

今天咱就聊聊这种“阴险”的打法：CC慢攻击。它不像DDoS那样锣鼓喧天，更像是在你系统里放了一只蜗牛，每天半夜爬两步，最后让你整个业务地基都酥了。

---

一、什么是CC慢攻击？说白了，就是“装成好人的流氓”

传统的CC攻击（HTTP Flood）你知道，模拟大量用户疯狂刷新页面，目标是把服务器CPU或连接数打满，属于“急性病”。

而慢速攻击（Slow Attack），是它的“阴险版”。攻击者不再追求“快”和“多”，转而追求“慢”和“持久”。

它怎么玩？ 我打个比方你就懂了：

想象一下，你开了一家网红面馆，只有10个座位（服务器连接数）。

正常顾客：吃完面，结账走人，15分钟翻台一次。

慢攻击者：他也来了，点了一碗面。然后……他开始用一根头发丝细的吸管，一根一根地嘬汤。你催他，他说“在吃呢在吃”。法律规定不能轰客人，于是这个座位就被他占了几个小时甚至几天。

只要来10个这样的“流氓顾客”，你店里所有座位都被占满。门外排长队的真实顾客（正常用户）一个也进不来，但你的厨房（CPU）看起来一点都不忙。

这就是慢攻击的核心：用极低的成本（每秒几KB的流量），占用你昂贵的系统资源（并发连接、线程、内存），直到把你的服务“拖死”。

二、它到底阴在哪儿？三个让你“查无此症”的隐蔽点

为什么常规防护经常对它失灵？因为它完美地避开了大多数警报阈值。

1. 流量“隐身术”：低到尘埃里 普通的DDoS/CC防护，主要看流量阈值。每秒100G流量打进来，告警肯定嗷嗷叫。但慢攻击呢？可能每秒就几K、几十K的流量，跟你一个正常用户看网页产生的流量没区别。流量监控图稳得一匹，在你眼里就是“业务低峰期”的正常表现。 你让防护设备怎么告警？没法告警。

2. 协议“模仿秀”：比真人还真 这种攻击完全基于标准的HTTP/HTTPS协议。攻击者慢悠悠地发一个合法的HTTP请求，然后每隔几十秒才发一个字节，保持连接不断。在Web服务器（比如Nginx、Apache）看来，这就是一个网速极差的“真用户”，按照协议规范，你必须耐心等着他传完数据。结果，一个连接就被挂起几分钟。

3. 目标“精准打击”：专挑软肋捏 它不搞全面轰炸，就盯着你最耗资源的动态页面打。比如：

• 商品搜索页（带复杂数据库查询）
• 用户登录接口
• 购物车结算页
• 后台管理入口

这些页面一处理就是几十毫秒，占用一个后端工作线程。攻击者用几百个这样的慢连接，就能把你有限的应用线程池全部耗光。你的静态图片、CSS文件照常访问，但核心业务功能已经瘫痪。 用户反馈“网站图片能显示，就是点不动”，运维一看前端资源都正常，排查方向全错。

三、怎么把它揪出来？光看流量图你就输了

既然常规指标没用，我们得换“侦探”视角。

（一）看这些“反常”的指标：

• 并发连接数异常高： 流量不大，但同时保持的HTTP/HTTPS连接数却持续处于高位，且只增不减。
• 连接持续时间离谱： 统计一下，发现大量连接的存活时间长得不正常（比如平均超过几分钟）。正常用户浏览一个页面，连接很快会关闭。
• 请求速率极低： 监控单个IP的请求速率，会发现有些IP每秒就发零点几个请求，但一直在线。
• 服务器线程池/工作进程全满： 这是最直接的受害者。检查你的Web服务器（如Tomcat、PHP-FPM）的工作线程，是不是全部处于“忙碌”（Busy）状态，但实际CPU使用率并不高。

（二）用点“土办法”和专业工具：

1. Netstat命令看一眼： 在服务器上执行 netstat -an | grep :80 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n。这能帮你快速看看，有没有某个IP地址建立了远多于常人的连接。
2. Web服务器日志分析： 重点找那些响应时间（request_time）超长，但发送字节数（body_bytes_sent）极少的访问记录。
3. 专业的WAF或应用层防护设备： 好的WAF（Web应用防火墙）都有慢速攻击防护模块。它能识别出这种不符合正常人行为模式的“慢连接”，并主动将其中断或加入黑名单。（这里得插一句，很多便宜货或云平台自带的简易WAF，这个功能形同虚设，真被打的时候就露馅了。）

四、怎么防？思路得从“抗洪”切换到“治安管理”

防御这种攻击，不能靠堆带宽，得靠“精细化管控”。

1. 【源头】设置严格的连接超时时间 这是第一道，也是最重要的防线。在你的Web服务器配置里，把各种超时时间调低。

• 连接超时： 客户端建立TCP连接的时间限制。
• 首包等待超时： 客户端发送第一个HTTP请求头的时间限制。
• 请求体读取超时： 传输POST数据的时间限制。 比如在Nginx里，可以这样设置（数值仅供参考，根据业务调整）：

  server {
  client_header_timeout 10s; # 接收客户端请求头的超时
  client_body_timeout 10s;   # 接收客户端请求体的超时
  keepalive_timeout 30s;     # 长连接超时
  send_timeout 10s;          # 向客户端发送响应的超时
  }

  原理就是： 正常用户不可能10秒都不发一个完整请求头。慢攻击者做不到，连接就会被你主动掐断。

2. 【中间】启用专业的慢速攻击防护 如果你用了高防IP、高防CDN或云WAF，一定要去后台把这个功能打开并调好参数！ 很多用户买了高防就以为万事大吉，其实默认策略可能很宽松。 这个功能通常叫“慢速攻击防护”或“CC防护-慢速模式”。你需要设置：

• 单个连接的最大持续时间
• 允许的最小传输速率
• 单个IP的最大并发连接数

3. 【后端】限制单IP并发与频率 在应用层面或防火墙层面，对敏感接口（登录、搜索、提交订单）做严格的限速和并发控制。

• 比如，一个IP每秒只能请求1次登录接口。
• 一个IP同时只能有10个到服务器的活跃连接。 这能极大增加攻击者的成本，他们需要操纵海量僵尸IP才能生效，而搞海量IP的难度和成本就高多了。

4. 【架构】做好业务隔离与弹性伸缩 这是治本之策，但成本也高。

• 动静分离： 把静态资源扔到CDN，Web服务器只处理动态API，减少攻击面。
• 微服务隔离： 别把用户登录、商品查询、支付都堆在一个应用里。一个服务被慢攻击拖死，不影响其他服务。
• 自动扩容： 在云上，设置基于并发连接数或应用线程池使用率的告警和自动扩容。虽然不能根治，但能为你争取排查和响应的时间。

---

最后说句大实话

防御CC慢攻击，技术配置只占三成，剩下七成是意识和监控。很多运维的监控大盘只盯着流量和CPU，这玩意儿一出来，你盯着看一天也发现不了问题。

你得知道有这种攻击存在，然后去调整你的监控告警指标：把应用层并发数、连接持续时间、错误日志增长率这些指标放到最醒目的位置。

这种攻击就像蛀牙，发现的时候往往已经疼了。别等到用户骂娘了才去找原因，平时就多拿“手电筒”照照那些阴暗的角落。

行了，关于这种“慢刀子”就先聊到这。如果你发现服务器一切正常但业务就是不对劲，不妨先按上面说的几点查查看，说不定就有惊喜（或者说，惊吓）。