CC 攻击全解：原理、特征与防御

原创

于 2026-10-26 11:41:35 发布 · 210 阅读

本文系统解析CC攻击（应用层HTTP Flood）的原理、特征与防御策略。重点阐述其利用合法HTTP请求高频消耗服务端计算资源的机制，揭示其协议合法、分布式低速、资源不对称三大难防根源。提出覆盖架构层、接入层、Web层、应用层及检测应急的五层防御矩阵，强调缓存静态化降本、人机识别分流、多级限流熔断等关键技术，并指出常见防御误区。

0 · 导读：为什么 CC 是"最烦人"的一类攻击

CC 攻击（HTTP Flood 的典型形态）只做一件事：伪装成正常用户，向"处理成本最高的页面"发起高频请求。它值得单独成篇，是因为四个特点：

维度	CC 攻击的地位
最"合法"	每个请求都是标准 HTTP——GET/POST、UA、Referer 一应俱全，防火墙看到的全是 80/443 正常业务流量
最省钱	不需要大带宽。几百 Mbps 甚至几十 Mbps 就能打瘫一个重业务站点（对比流量型攻击动辄数百 Gbps）
最难防	请求本身无恶意特征，防御只能靠"行为/频率/人机识别"间接判断，永远存在误伤与绕过的拉锯
最常见	个人站长、小游戏、电商大促、竞对互殴的高发攻击形态；DDoS 黑产按小时计费的"入门款"

本篇路线图：

出身：Collapsar → Challenge Collapsar 的命名，CC 在 DDoS 家族中的位置，难防的三个结构性原因；
原理：单请求成本模型与攻击放大比、攻击链路、载荷分类、"像真人"的伪装与"不像真人"的破绽、慢速攻击家族；
特征：流量层、日志层、资源层三个维度的可量化判据，以及与流量型/慢速攻击的区分表；
变种与成本：CC 变种、工具与黑产、攻防成本的不对称性；
防御：五层矩阵（架构/接入/Web/应用/检测应急），Nginx 配置实战，五个常见误区；
实战：日志统计命令、连接观测、三分钟判断树；
面试高频题 + 小结速查。

合规声明： 实施 CC/DDoS 攻击在我国属于违法犯罪行为（《刑法》第二百八十六条"破坏计算机信息系统罪"，后果严重的处五年以下有期徒刑），公安机关"净网"专项行动持续打击 DDoS 黑产。本文仅讨论防御技术与授权场景下的测试方法。

1 · 出身与定位：从 Collapsar 到 Challenge Collapsar

1.1 命名由来

Collapsar：2002 年前后出现的一款 DDoS 攻击工具（国内开发者所为，曾是当年最有影响力的 DDoS 工具之一）。Collapsar 本意是天文学术语"坍缩星"，也就是黑洞。
Challenge Collapsar：该工具面向 HTTP 协议的攻击方式，被业界称为"挑战黑洞"。流传较广的解释：运营商/机房常用"黑洞策略"（null-route，把流向受害者的流量直接丢弃）来抗 DDoS，而 CC 的请求与正常流量无异，黑洞设备难以识别清洗、被迫"两害相权"——等于挑战了黑洞防护。
今天"CC 攻击"一词已脱离原工具，成为应用层 HTTP Flood 攻击的通称：凡是"用合法 HTTP 请求高频消耗服务端资源"的攻击，都被归为 CC。

1.2 CC 在 DDoS 家族中的位置

DDoS（分布式拒绝服务）按攻击层与耗尽的资源分三类，CC 属于第三类：

类型	攻击层	典型手法	耗尽的资源	特征
体积型（Volumetric）	L3/L4	UDP Flood、反射放大（DNS/NTP/Memcached）、ACK Flood	链路带宽	流量 Gbps~Tbps 级，一力降十会
协议型（State-Exhaustion）	L4	SYN Flood、连接耗尽、碎片攻击	连接表/状态机（防火墙、负载均衡）	半连接、畸形包
应用层型（Application Layer）	L7	CC / HTTP Flood、Slowloris、RUDY、DNS 查询 Flood	CPU、数据库连接、应用线程、缓存	单请求合法、低速分散、以巧破力

CC 是应用层型里最主流的一种。它与 SYN Flood 的根本差异在于：SYN Flood 的包是畸形的（永远握不完的手），CC 的请求是完整的（握手、请求、响应全都有）——防火墙基于包特征的检测对它基本失效。

1.3 为什么 CC 难防：三个结构性原因

协议完全公开，报文完全合法。HTTP 是明文公开协议，一个 GET /search?q=手机 与真人请求在报文层面毫无区别。防 DDoS 设备赖以生存的"恶意特征"不存在。
分布式 + 低速。肉鸡/代理池动辄数千 IP，每个 IP 每秒只发几个到几十个请求——低于绝大多数限速阈值；总量却足以堆满后端。基于"单 IP 频率"的规则天然被动。
资源不对称（放大效应）。动态页面的服务端处理成本比请求本身的传输成本高 3~5 个数量级（见 2.1 节定量计算）。攻击者用最小的投入，购买服务器最贵的"劳动"。

这三条决定了防御思路——既然"报文"看不出来，就只能从频率、行为、人机、架构成本四个侧面设防，这正是第 5 节五层矩阵的由来。

2 · 攻击原理：最小的请求成本，最贵的服务端劳动

2.1 成本模型：一个请求，两种代价

把一次 HTTP 请求拆成"攻击者的付出"和"服务器的付出"：

请求类型	服务端 CPU（量级估算）	数据库/后端	单机处理容量（量级估算）
静态文件（Nginx 直返）	~0.1 ms	无	单核 10⁴+ rps
典型动态页（查 1 次库、渲染模板）	1~10 ms	1 次查询	单机 10²~10³ rps
搜索/聚合/报表页（多表 JOIN、排序分页）	50~500 ms	多次重查询，可能全表扫描	单机 10~10² rps

攻击者发一个 GET 的成本：构造报文约 10 µs 级 CPU + 几百字节流量。于是攻击放大比 = 服务端成本 ÷ 攻击者成本：

打静态页：≈ 10~100×——没什么意义，不如直接做流量攻击；
打动态页：≈ 500×~10⁴×（CPU 时间维度）；
打重页面：10⁵× 以上。

一个具体的心算例子： MySQL 连接池 100，某搜索接口单次查询 200 ms（慢查询）。攻击者以 500 rps 打这个接口：

占用连接数 = 500 rps × 0.2 s = 100 个连接 → 连接池瞬间打满
→ 后续所有查询排队等待 → 页面 RT 从 50 ms 劣化到 5 s+
→ 真实用户批量超时离开 → 业务死亡

这就是"几百个小代理打瘫一个日活十万的站点"的算术本质——攻击者从不与带宽搏斗，他们与服务器的"单笔业务成本"搏斗。

2.2 攻击链路

┌──────────┐  下发指令   ┌────────────────┐  HTTP 请求：单 IP 低速、总量分散  ┌─────────────────┐
│ 攻击者    │ ─────────▶ │ 肉鸡群 / 代理池 │ ─────────────────────────────▶ │  源站服务器      │
│(自建/租用)│            │分布各地运营商网段│     集中在少数"重"URI           │ Web / App / DB   │
└──────────┘             └────────────────┘

标签