企业官网建设流程全解析

做过运维或者自己搭过网站的朋友，大概都遇到过这种场面：服务器突然ping不通、网站打不开，机房值班电话打过来问“你被打了，是DDoS还是CC？”这时候你要是支支吾吾答不上来，对方也没法帮你下手，只能先默认按大流量攻击处理，把你IP做个黑洞止损。等业务恢复一大截，你才反应过来——原来大部分流量根本不是大带宽，而是一堆“看起来很正常”的HTTP请求在反复挤占业务接口。

本文就想把这件经常被混淆的事彻底讲清楚：DDoS攻击和CC攻击到底有什么区别。我会从术语源头、攻击层、服务器症状、排查实操、防护选型几个角度去拆，顺便聊聊很多人在概念上常见的误区。适合刚入门的安全工程师、站长，还有需要对接高防和WAF采购的技术负责人。顺便提醒一句，讨论攻击原理是为了防御，任何未经授权的攻击测试都有法律风险，本文只讲识别和防护思路。

1. 从名字拆起：DDoS和CC根本不在同一个网络层

1.1 DDoS是个“伞形”分类，而不是某一种具体手法

DDoS的全称是Distributed Denial of Service，分布式拒绝服务。把两个关键词拆开看：Denial of Service是“拒绝服务”，目标是让合法用户无法访问；Distributed是“分布式”，指攻击来源分布在大量主机上，不是一台机器在单挑。单台的DoS攻击，无论带宽还是连接数都有限，打一会儿可能自己先挂了；分布式攻击靠的是数量，成千上万台机器同时发数据，才能形成规模化的杀伤力。

这个词的真正含义是一个“家族名”。从网络层、传输层到应用层，凡是利用多源流量或请求导致服务不可用的，都能被归到DDoS这个大类下。所以严格来说，DDoS不是一种具体的攻击方法，而是一扇大门，门里面装着很多子类型。

1.2 CC攻击的“挑战黑洞”这个老名字，现在代表了什么

CC攻击的全称是Challenge Collapsar，这个词是从一个老故事来的。Collapsar是早期一款知名的抗DDoS防护产品的英文名，中文圈叫“黑洞”。当时有一种攻击专门针对Web应用层发起大量会让防护设备也吃不消的请求，设计目标就是“挑战黑洞设备”，于是就叫Challenge Collapsar，缩写为CC。

随着时间推移，早期那款产品虽然不流行了，但“CC”这个叫法在国内安全圈扎下了根。现在的CC攻击，基本等价于国际语境里的HTTP Flood和Application Layer DDoS Attack，也就是专门打应用层的HTTP洪泛攻击。攻击者模拟正常浏览器访问，把目标网站的页面、接口当作打击对象，消耗的是Web服务器和应用业务的计算能力。

1.3 从OSI模型看层级，是整个概念最核心的区分

注意看表格，CC攻击被归属于DDoS大类的L7子集。换句话说：CC攻击一定是DDoS，但DDoS不一定是CC。现实中和云厂商沟通时，对方经常问“你这个是四层还是七层”，就是这个概念在实际工作中的投射。四层和七层的防御设备选型完全不同，报错类型会让清洗策略走弯路。

发布后的实际工作经验是：如果客户说“被打了”，我一般先让他确认是通过什么访问不了的——如果是整个IP都ping不通，多半是四层及以下；如果是网站能连上但页面一直转圈、接口超时，那大概率是七层。

2. 攻击原理的核心差异：塞满管道与拖垮应用

2.1 网络层和传输层DDoS的杀伤链路

网络层和传输层的DDoS，目的是让“数据根本上不了路”，或者“中间设备先垮掉”。它的一条完整链路是：

1. 用海量数据包填满服务器接入带宽，造成链路拥塞，合法流量进不来。
2. 如果没有把带宽打满，就尝试打网络设备或安全设备的处理极限，比如快速的空连接把防火墙会话表占满，后续所有新建连接都被丢弃。
3. 如果中间设备没垮，大量协议栈半开连接还能拖死服务器自身的TCP处理能力。

这种攻击的特征是：包数量巨大、单位时间内的收发量远超正常值、对抗的是“带宽大小”和“并发处理能力”。所以我们在监控上看到的现象往往是带宽占用飙到接近端口上限，但不一定有明显的业务层痕迹。

之前处理过一个案例：一台业务服务器接在100M的接入链路上，深夜突然所有监控失联。远程登录都做不了，只能联系机房看交换机的上联端口流量，发现已经持续满速跑了十几分钟，机房出于保护直接把IP黑洞了。这就是典型的流量型DDoS思路——不是直接针对业务进程，而是让整个链路失去可用性，维护人员连门都进不去，更别提反击。

2.2 CC攻击的杀伤逻辑：用“正常”的请求耗死应用

CC攻击的核心不是体积，而是频率和合理性。一次HTTP请求本身很小，哪怕一百万个请求，带宽可能也就几十M，正常机柜完全扛得住。但它真正消耗的是后端应用资源：每个动态请求需要Web服务器分出线程或进程来处理，处理过程中很可能要查询数据库、执行排序、渲染模板。

这里有一个非常经典的杀伤链条：

1. 攻击者选定目标站点里最耗资源的一个或几个动态接口，例如搜索、筛选、登录、报表。
2. 大量请求同时涌向这些接口，每个请求都带不同的随机参数，让缓存完全失效。
3. 后端线程池、进程池被占满，新来的正常用户请求只能排队。
4. 数据库连接池被耗尽，慢查询堆积，最终整个应用像死掉一样，但实际上服务器进程还在，只是在空转。

CC攻击的厉害之处在于，它伪造的请求很难被普通网络层清洗设备识别。网络层根本看不出它“坏”，因为TCP握手是完全正常的，数据包也不畸形。只能靠业务特征来识别，这就把防御难度拉高了。

2.3 一个容易记住的比方，帮你把关系理顺

我给新同事讲这两者的关系时，常用两个场景打比方：

• DDoS（四层及以下）像是往小区门口所有路上堆满了土方和垃圾，快递员根本进不了小区大门，连物业保安都联系不上。
• CC攻击则像是放了一大群人进小区大厅，每个人都拿号排队、反复向窗口咨询问题，把服务窗口全占满。真正有事的业主来了，发现窗口前面全是无关人员，事情也办不成。

这个比方很直白。实际攻击中也经常会看到两者配合：先用四层流量打一轮，逼着你启用高防；等你高防还没调好，再用七层请求轰业务接口。所以判断“是哪种类型”和“采取了多大规模”，不能只看一个时间点，要观察攻击的演进趋势。

3. 站在服务器上看症状：两种攻击完全是两张面孔

3.1 网络型DDoS留下的监控特征

从运维监控面板和服务器状态，能整理出比较典型的网络型DDoS指纹：

• 出口带宽曲线直接顶满，就算在凌晨业务低谷也一条直线。
• ping外网地址时丢包率骤增、延迟上下抖动剧烈，甚至完全不通。
• 远程管理通道不可用，想登录服务器排查得靠带外管理卡或者机房同事协助。
• 中间设备在“硬扛”，比如防火墙、负载均衡器的会话数飙升，但后端服务器的CPU使用率反而未必高，因为流量根本没送到应用层。

最后这一点值得特别留意。很多人在服务器上看到CPU不高，就觉得“没被攻击”，但实际上带宽已经饱和了，流量在更前面的链路节点被丢弃。判断网络层攻击，首先看带宽、看中间设备，不要只盯着自己那台服务器的CPU。

3.2 CC攻击留下的监控特征

CC攻击的指纹明显不同，更容易体现在应用侧：

• 带宽占用不明显，一小时下来可能只有几十M流量，但Web服务的并发连接数一直顶在高位。
• 应用服务器CPU占用飙升，进程列表里大量处于忙碌状态的Worker。
• 动态接口响应时间从正常的几十毫秒拉长到几秒甚至几十秒，页面转圈。
• 数据库慢查询数量猛增，连接数持续打满，连接池报错。
• Nginx访问日志里出现大量指向相同URL、参数却随机化明显的请求，User-Agent要么高度统一、要么高频轮换。

我在排查中遇到过最典型的情况：带宽明明还有80%的空余，但是网站的搜索页已经打不开了。登上去看top命令，CPU被PHP-FPM进程占满，再一查日志发现同一时间同一接口被访问了几万次，参数值是毫秒级时间戳加随机串，每次都不一样。这种就是标准的应用层消耗，拿带宽去衡量只会有错觉。

3.3 一张症状对照表，快速区分两种攻击

实际做判断时，建议把这几个指标放在同一个时间轴上对比：带宽、CPU、连接数、响应时间和日志。单一指标会骗人，组合起来看基本不会走偏。

4. 接到告警后的实战判别：先看这些指标再决定方案

4.1 第一步：别急着翻业务日志，先看网络和连接状态

告警一响，人的本能是马上打开应用日志想找异常请求，但我的建议是先登到服务器上看两类数据：实时带宽和TCP连接状态分布。命令不复杂，就是标准的排查命令：

# 查看端口/网卡实时流量 nload iftop -i eth0 # 查看TCP连接状态分布 netstat -an | awk '{print $6}' | sort | uniq -c | sort -rn # 查看当前并发最高的TCP连接对端IP netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

这三个命令可以快速给出一个方向性结论：如果外网流量已经接近端口上限，大概率是流量型攻击，先把止损优先级提上来；如果流量不高但大量连接堆积在同一组源IP上，就开始看是不是应用层问题。SYN_RECV状态大量堆积，倾向传输层半开连接类攻击；ESTABLISHED状态居高不下且集中在相同路径，那CC嫌疑就很大。

4.2 第二步：结合访问日志，找“人办不到”的请求节奏

网络状态只能缩小范围，最终定性还是要看业务日志。CC攻击留下的日志特征有几条非常明显：

• 请求频率远超人手操作水平，单个IP一秒钟能发几十上百个请求，再快的用户也做不到。
• 动态URL的参数大量随机化，例如“/product?id=5830346c-...”，这些随机参数专门用来绕开缓存。
• User-Agent出现明显的“整齐感”，要么所有请求完全一样，要么在一个小列表里循环。
• 页面平均响应时间快速劣化，告警前后的时延从正常的几百毫秒涨到几秒钟。
• Cookie或Session的新建比例异常高，因为攻击者一般不会去维持会话状态。

还有个辅助技巧：把被访问最集中的URL列出来看看。CC攻击一般只围着几个高消耗接口打，如果你看到80%的异常请求集中在两三个带查询条件的URL上，那七层攻击的可能性就非常高。

4.3 第三步：区分“攻击”和“业务高峰”，别误伤正常流量

这块是最容易背锅的经验。遇到过双十一大促场景下带宽打满、用户大量涌入的情况，表面看起来跟DDoS几乎一模一样——流量高、连接数高、延迟升高。但区分点在于：正常业务高峰的流量曲线是平滑爬坡、有周期性的，请求成功率高，URL分布符合业务规律；而攻击流量通常是断崖式上涨，且集中在特定接口，用户成功率和正常业务指标明显下滑。

还有一种容易被误判的场景是搜索引擎爬虫和商业数据采集。部分爬虫程序的抓取频率和并发量，比人肉用户高得多，日志特征也很像CC。这时候先不要急着封IP，看对方是不是遵守了robots约定、请求是否规律、UA是否规范。直接封爬虫的代价可能是SEO流量一夜回到解放前。

4.4 向云厂商或机房汇报时，提前备齐这些信息

如果业务需要用高防或向IDC申报，接电话的人最希望听到的是很有条理的描述。我的习惯是整理成五条：

• 攻击起始时间点和持续时间跨度。
• 目标IP、域名、端口和被攻击的具体接口。
• 带宽峰值、连接数峰值、请求速率等监控数据。
• 当前已做的处置，例如是否开启了WAF、是否封禁了某个网段。
• 流量到达最高峰的时段截图和访问日志样本。

把这些提前准备好，可以大幅减少来回确认的时间。很多防御策略的前置动作（切换清洗线路、加高防护阈值等）都依赖这些信息，效率会直接影响故障时长。

5. 防护思路的分岔路：流量清洗挡四层，访问控制挡七层

5.1 应对四层DDoS：核心是“让流量不进源站”

带宽型DDoS的枪口对准的是链路，单靠加带宽属于烧钱式防御，而且永远追不上攻击者的节奏。常态化的方案是把流量引到专门的清洗节点，清洗节点过滤掉异常报文，只把干净流量送回源站。这个技术路径里，有几个概念需要理解：

• 高防IP或DDoS高防服务：业务域名通过解析切到高防IP，所有流量先走高防节点，清洗后再转发到真实源站。
• 清洗策略：大包校验、分片重组、源IP信誉、速率限制等，把明显畸形的报文丢弃。
• 黑洞机制：超过一定阈值后，机房直接把IP流量丢弃，防止整个机房被拖下水。这本质上是止损机制，不要指望黑洞期间业务还正常，它保护的是基础设施。

针对SYN Flood这种连接型攻击，可以适度启用操作系统的SYN Cookie机制、调整TCP半连接队列长度、限制单IP并发，这些属于服务端加固范畴，效果明显但不要指望能扛住大规模流量。

5.2 应对CC攻击：核心是“让机器现出原形”

CC攻击之所以难防，是因为请求本身合法。防护思路必须往前推一步——区分发起者到底是人还是机器。常见的成熟做法有这么几类：

• 客户端验证：给动态页面加入JavaScript计算挑战，浏览器能自动通过，用脚本直接发HTTP请求的客户端却没有计算能力，会被挡在外面。
• 人机验证：对可疑高频请求弹出滑块或语义验证码，干扰成本高到让攻击者放弃。
• 频率控制：按IP、按Cookie、按设备指纹分别做请求速率限制，超限后临时封禁或降级响应。
• WAF自定义规则：把日志里观察到的异常UA、异常Referer、请求频率阈值写成规则，实现自动拦截。
• 缓存与前端化：能缓存的结果绝不穿透到后端，能静态化的页面绝不动态生成，从根上减少可打的接口数量。

这些措施在实践中的最大教训是“先保业务，再求严格”。验证码和JavaScript挑战如果配置不当，会把大量正常用户也拦住。上线前一定要小流量灰度，自己先用浏览器和手机真机各走一遍完整流程。

5.3 混合攻击下的联动兜底

真实攻防中，DDoS和CC经常交替出现。攻击者先用四层把流量打掉一轮，逼你启防护，再趁防护策略尚未收敛，用七层请求轰打核心接口。如果防御架构只覆盖了其中一层，就会出现“明明上了高防还在被打”的错觉。

我的建议是形成一套组合防御：

• 四层由高防IP清洗，七层由WAF加业务层限流兜底。
• 源站IP严格隐藏，所有回源都走白名单，防止攻击者绕过清洗直接打源站。
• 配置分级告警阈值，比如链路使用率、应用响应时间、连接数分别设阈值，而不是等到服务器宕机才收到通知。
• 准备一套备用的切换方案，比如备用域名、备用源站或第二清洗线路，被打急眼了能快速切过去。

联动方案听起来复杂，但核心逻辑只有一句话：不要让单点扛所有类型的伤害。

6. 关于CC与DDoS的常见误区和我的防御实践心得

6.1 误区一：CC不算DDoS

这个误区在非专业圈子很常见。有些人认为DDoS是纯粹的带宽攻击，CC是另一种东西。从分类学上说，CC就是应用层的DDoS，英文里直接叫Application Layer DDoS Attack。之所以很多产品把“DDoS防护”和“CC防护”分开卖，是因为七层防护的实现手段和成本跟四层差距很大，分拆有利于按需采购，并不代表它们是两类完全无关的攻击。

6.2 误区二：只有带宽被占满才是DDoS

没有大带宽照样可以完成拒绝服务。利用大量半开连接把服务器协议栈拖死，或者把防火墙并发会话表占满，同样让业务彻底不可用，这也是DDoS的一种形态。判断是不是DDoS，标准是“服务有没有被分布式攻击搞到不可用”，而不是“流量是不是超过某个数字”。

6.3 误区三：上了高防IP就万事大吉

高防IP解决的是四层链路和协议层攻击，对七层的“合理请求”并不灵光。七层攻击请求包是正常的HTTP语义，清洗节点在传输层看不出异常，放过来之后源站依然会扛不住。正确态度是把高防IP当成第一道大坝，把WAF和业务接口限流当成第二道大坝，做好纵深防御，少依赖单一产品护体。

6.4 误区四：把一切异常访问都当成攻击

这个问题我处理过太多次了。有些时候看到的“大量请求”其实是商业爬虫、搜索引擎抓取、甚至内部同事跑批量脚本。处理前先看请求有没有业务意图，再看是否源于固定IP段，最后才决定是封禁还是限流。把所有异常流量一概封禁，很容易伤到真实用户和搜索引擎收录，属于防御过度。

6.5 关于“攻击源码”这类热词，我想多说一句

每次看到社交平台上有人在聊“Python CC攻击源码”、“DDoS攻击实验”之类的东西，我都想提醒一下：这类内容大部分是过时脚本，或者干脆是将计就计的“后门投递器”，把它下载下来在自己机器上跑，等于把自己变成别人下一步攻击的肉鸡。真正要做实验，正确的做法是在自有授权环境里做防护演练：搭一套测试业务，制造高并发访问，观察服务器指标的变化，然后调优WAF阈值、缓存策略和限流方案；这叫攻防演练，前提是环境严格隔离、有明确授权、不触网。方向反了，就是在给自己挖坑。

6.6 最后分享几个让我少踩坑的习惯

第一，一切从“业务基线”出发。我维护的每套系统都记录正常状态下带宽、连接数、CPU、响应时间的最低值和典型值。没有基线，告警就是一堆噪音；有了基线，异常到来时一眼就能发现问题。第二，日志和监控都要开，而且日志保留周期要覆盖攻击事件的复盘需求。第三，攻击发生后，先启动粗粒度防护止损，等流量稳定了再精细化调整规则，不要一上来追求完美配置，业务可能等不到你配完。第四，无论公司规模大小，至少准备一页纸的应急响应步骤，写清楚“谁联系高防厂商、谁负责切换CDN、谁盯着监控屏”，这个比任何技术都管用。

概念拆解到最后，最有价值的从来不是背下来“DDoS是几层、CC是几层”这两个孤立知识点，而是遇到异常时能在第一时间做对判断、用对资源。看完这篇文章，下次再遇到网站打不开，你先看带宽还是先看CPU，就知道答案了。