CC攻击与DDoS攻击有什么区别？从流量特征判断防护重点

很多人看到带宽升高就称为“CC攻击”，看到大量请求又统称为“DDoS攻击”，这两个判断都可能失准。两者并不是完全并列的概念：DDoS强调分布式流量造成服务不可用，覆盖网络层、传输层和应用层；CC通常指针对HTTP/HTTPS应用层的请求型攻击，重点是消耗Web服务器、程序进程、数据库或连接池资源。

因此，选择防护产品时可以先按流量特征判断：带宽或包速率接近链路上限，优先看上游清洗和网络层DDoS防护；带宽并不高，但请求速率、连接数、CPU、数据库或接口延迟明显异常，优先看CC防护、WAF或应用层流量控制；网络层和应用层同时异常，则需要具备分层防护能力的组合方案。

概念边界：CC是攻击方式，DDoS是更大的类别

DDoS关注“从哪里来”和“是否造成拒绝服务”

DDoS是分布式拒绝服务攻击的统称。攻击者通常利用大量被控制的主机、设备或代理来源，同时向目标发送流量、连接或请求，使目标出现以下一种或多种情况：

• 网络入口带宽被占满，正常数据包无法进入；
• 防火墙、负载均衡器或服务器处理能力被耗尽；
• TCP连接表、连接队列或端口资源被占满；
• Web服务、应用进程、缓存或数据库无法及时响应。

DDoS并不限定具体协议。UDP洪泛、ICMP洪泛、SYN洪泛、连接耗尽以及HTTP请求洪泛，都可能被归入DDoS的范围。判断重点是攻击是否来自多个来源，以及它是否造成了服务不可用或明显降级。

CC关注“请求做了什么”

CC通常是对网站或Web应用发起大量HTTP/HTTPS请求。请求本身可能符合正常协议格式，甚至能够完整建立TCP连接、完成TLS握手并进入应用程序，因此它不一定表现为特别大的网络带宽。

攻击请求常见的消耗点包括：

• 反复访问动态页面，导致应用进程持续执行；
• 重复查询搜索、登录、商品列表等高成本接口；
• 触发数据库查询、缓存未命中或复杂计算；
• 建立大量并发连接，消耗连接池和工作线程；
• 使用大量来源、路径或参数，降低简单限速规则的效果。

“CC”这个名称在实际运维语境中更多是对应用层请求洪泛的通俗称呼，并不是所有HTTP流量异常都能严格归入同一种技术类型。正常活动高峰、配置错误的爬虫、接口重试风暴，也可能表现出类似特征。

两者的关系不是二选一

用同一组维度比较，可以得到更清晰的边界：

例如，多个来源每秒向一个动态接口发起数万次请求，这既可以称为CC，也可以称为应用层DDoS。单个来源持续请求一个高成本接口，更接近CC或请求滥用，但不一定符合“分布式”的严格定义。相反，多个来源发起UDP洪泛属于DDoS，但不能称为CC，因为它没有以Web请求为主要攻击内容。

从流量特征判断防护重点

判断时不要只看“流量大不大”，而要同时观察链路、连接、请求和应用资源。不同攻击会在不同层留下痕迹。

带宽和包速率异常：优先排查网络层DDoS

如果入口带宽快速接近服务器或机房端口上限，且应用请求日志没有同比增加，重点通常不在CC规则，而在网络层或传输层防护。

需要关注的指标包括：

• bps：每秒传输的比特数，反映带宽压力；
• pps：每秒数据包数量，反映设备处理小包的压力；
• SYN速率：TCP连接建立请求的数量；
• 新建连接数和并发连接数：反映连接表、队列和会话资源消耗；
• UDP、ICMP或其他异常协议的流量占比；
• 正常业务端口是否仍能获得稳定的有效连接。

例如，某个示例时段出现约2Gbps的UDP流量，服务器网卡入口接近上限，但Web访问日志中的请求数基本不变，CPU和应用进程反而没有明显升高。这种现象更接近网络层洪泛。即使应用本身没有处理这些数据包，链路也可能已经被占用，单靠WAF或应用内限流无法解决。

SYN洪泛则可能表现为SYN包速率升高、半连接数量增加、已建立连接比例下降。此时服务器是否能够正常执行PHP、Java或其他应用代码，并不是第一判断点；应先确认连接和上游入口是否已经受到影响。

请求数和应用资源异常：优先排查CC

CC更常见的特征是：

• HTTP/HTTPS请求速率远高于平时；
• 总带宽没有达到链路上限，但应用响应时间明显变长；
• CPU使用率、工作线程、进程数或连接池快速上升；
• 数据库连接、缓存访问或磁盘I/O出现异常；
• 某些动态路径、查询参数或未缓存接口访问集中；
• 5xx、超时和排队请求增加。

一个简单的估算可以说明为什么CC不一定需要很大带宽。假设每秒有8,000个请求，每个请求平均产生6KB响应，按十进制近似计算：

• 8,000 × 6KB = 48,000KB/s；
• 48,000KB/s约等于48MB/s；
• 48MB/s × 8 = 384Mbps。

384Mbps并不一定能够立即占满一条更大带宽的链路，但如果每个请求都需要查询数据库或执行复杂业务逻辑，应用可能先于网络入口达到瓶颈。反过来，如果请求主要命中静态缓存，带宽虽然很高，源站应用压力未必同步增加。

因此，判断CC时不仅要看请求量，还要看请求的“成本”。每秒1,000次静态文件请求，与每秒1,000次复杂搜索请求，对源站的影响可能完全不同。

两类指标同时上升：考虑混合型攻击

在实际事件中，攻击者可能同时发送大流量包和HTTP请求，或者先用网络层流量干扰监控，再用应用层请求压垮源站。此时可能同时看到：

• 入口带宽、pps和连接数上升；
• HTTP请求量明显高于业务基线；
• Web服务器、应用进程和数据库资源也接近上限；
• 防护接入后，链路恢复但应用延迟仍然很高，或反过来。

这类情况不能只购买一个“带宽型”或“WAF型”能力。前者可能看不懂应用请求，后者可能来不及处理已经把入口打满的流量，通常需要上游流量清洗与应用层防护共同介入。

产品怎么选：先匹配攻击层，再比较容量

“DDoS防护”或“CC防护”只是产品名称，不能直接代表实际能力。采购时应该把攻击类型转换成可验证的指标。

1. 不要只比较“多少Gbps”

供应商常用Gbps描述防护规模，但采购时至少还要询问以下维度：

• 支持的pps范围；
• 可处理的新建连接速率和并发连接数；
• 是否支持SYN、UDP等传输层攻击；
• 是否能识别HTTP/HTTPS请求；
• 应用层的请求速率、规则数量和并发处理能力；
• 标称防护带宽与实际可交付的清洗后业务带宽是否是同一个概念。

例如，两个方案都标注“可防护大流量”，其中一个侧重网络层清洗，另一个侧重HTTP请求分析，它们解决的瓶颈可能不同。前者适合入口带宽和包速率异常，后者适合源站CPU、接口和数据库被请求拖慢，不能仅凭一个带宽数值判断优劣。

2. 确认防护是否覆盖实际入口

防护产品必须位于攻击流量经过的路径上。如果业务域名经过防护，但攻击者仍能直接访问暴露的源站IP，应用层防护可能被绕过。比较方案时应确认：

• 防护对象是域名、IP，还是指定端口；
• HTTPS是否在防护侧终止并进行应用层识别；
• 源站回源地址和访问路径如何保护；
• 是否能区分正常回源流量与绕过防护的直连流量；
• IPv4、IPv6或其他实际使用入口是否都纳入范围。

如果HTTPS只在源站终止，防护侧无法读取URL、参数、Cookie等应用信息，那么它可以处理连接或网络层异常，但未必能够完成精细的CC识别。是否启用解密、证书如何管理，也应纳入技术和运维成本评估。

3. 比较误拦截与处置方式

CC防护通常需要在“拦截攻击”和“保留正常用户”之间取平衡。采购时可以关注：

• 是否支持按IP、会话、路径、请求频率或行为组合限速；
• 是否能对登录、搜索、下单等高成本路径分别配置策略；
• 是否提供日志，便于查看命中的规则、来源和请求路径；
• 是否支持白名单、灰度策略和人工放行；
• 触发挑战、限速或封禁后，恢复条件是什么；
• 对移动网络、共享出口和大量NAT用户是否容易误伤。

简单地按IP封禁并不总是有效。企业出口、运营商NAT和校园网络可能让大量正常用户共享一个公网IP；另一方面，攻击来源也可能频繁变化。更可靠的判断通常需要结合请求频率、路径、Cookie、会话行为、响应状态和资源消耗，而不是只看来源地址数量。

4. 把长期成本拆开看

防护成本不应只看购买或租用费用，还要看流量、请求和运维带来的持续成本。比较时可以要求方案明确：

• 按峰值带宽、清洗后流量、请求量还是其他维度计费；
• 攻击流量和正常业务流量是否采用不同统计口径；
• HTTPS处理、日志留存和规则管理是否包含在服务范围内；
• 防护切换、策略调整和事件响应是否需要人工介入；
• 源站扩容、数据库优化和应用改造是否仍需单独投入。

这里不能把某一种计费方式直接判断为更便宜。对于带宽型攻击频繁的业务，网络侧的清洗成本更敏感；对于请求量不高但单次处理很重的业务，应用层能力和源站优化可能更重要。

用同一时间窗口验证判断，而不是凭单个指标下结论

第一步：建立正常业务基线

至少记录一个业务高峰期的正常范围，建议包括：

• 入口和出口带宽；
• pps和新建连接数；
• 并发连接数；
• HTTP请求数、响应时间和错误率；
• CPU、内存、工作线程和连接池；
• 数据库连接数、慢查询或缓存命中情况；
• 主要路径的访问占比。

基线不必精确到某一个固定数字，但要知道“正常高峰”与“异常时段”相差多少。例如，正常每秒约500至800个请求，促销期间升到2,000个请求仍能稳定响应；如果没有业务活动却突然达到10,000个请求，同时动态接口延迟明显升高，就需要进一步核查。

第二步：按三层采集数据

为了避免把不同问题混在一起，可以在相同的分钟或秒级时间窗口对照三层数据：

如果入口带宽已经打满，而Web日志几乎没有新增请求，优先往网络层查。如果HTTP请求增长数十倍，带宽只增长几倍，但应用CPU、数据库连接和接口耗时同步上升，CC的可能性更高。

需要注意，HTTPS未在当前节点终止时，服务器访问日志可能看不到完整URL和请求参数。此时“日志中没有请求”不能直接证明没有应用层攻击，还应查看TLS握手、连接数以及能看到请求内容的边缘节点数据。

第三步：排除正常流量和配置故障

异常请求不一定来自攻击。可以结合以下问题交叉判断：

• 是否刚发布了新版本、重试策略或定时任务；
• 是否有营销活动、内容热点或文件集中下载；
• 是否新增了爬虫、监控程序或第三方接口调用；
• 异常请求是否集中在某个路径、参数或客户端类型；
• 5xx增加前，应用本身是否已经发生死循环、连接泄漏或缓存失效。

例如，静态文件下载导致带宽上升，但应用CPU和数据库都稳定，重点可能是带宽容量和缓存承载；同样的带宽下，如果请求集中在一个未缓存的搜索接口，重点则应转向应用层限速和CC防护。

第四步：在授权范围内做验证

不要为了验证防护能力而直接向生产地址主动发起攻击流量。更稳妥的方式是使用供应商提供的测试环境、授权压测环境或经过批准的正常业务负载测试，验证以下结果：

1. 网络层异常发生时，链路是否仍能保持正常业务所需的清洗后带宽；
2. 请求量升高时，WAF或应用层策略是否能识别并限制异常请求；
3. 正常用户是否仍能访问核心页面和接口；
4. 触发防护后，日志能否定位到规则、来源和时间窗口；
5. 防护解除后，业务是否能够自动恢复，是否需要人工回切。

测试结果应记录在同一张表中，避免把“能处理多少Gbps”和“能承受多少请求每秒”混成一个数字。

几个容易踩坑的判断

带宽不高，不代表没有DDoS或CC。 小包高pps、SYN连接耗尽和高成本HTTP请求，都可能在带宽未跑满前使服务异常。

请求数高，也不代表一定是CC。 秒杀、热点内容、错误重试和爬虫都可能导致请求暴增，必须结合来源、路径、响应时间和业务事件判断。

来源IP多，不是唯一证据。 分布式攻击可能使用大量来源，但共享出口也会让正常用户呈现少量IP；IP数量只能作为辅助指标。

上WAF不能替代上游DDoS防护。 如果流量已经把服务器入口或接入线路堵满，应用层规则可能还没有机会处理请求。

CDN缓存也不是全部防护。 静态内容命中缓存时可以减少源站压力，但动态请求、缓存穿透和未缓存接口仍可能直接消耗源站资源。

扩容服务器不能解决所有问题。 增加CPU或实例数量对应用层请求可能有帮助，但无法解决入口带宽被占满、TCP连接资源耗尽或防护路径被绕过等问题。

判断CC攻击和DDoS攻击有什么区别，最终应回到同一条决策逻辑：先看带宽、pps和连接是否在网络层失控，再看HTTP请求是否在应用层制造资源压力，最后确认两者是否同时发生。 以链路和包速率为主的异常，防护重点是上游网络层能力；以请求、接口和业务资源为主的异常，防护重点是CC识别与应用层控制；两类指标同时异常，则不能用单一产品标签代替分层验证。