CC攻击的防御难点从来不在于“打回去”，而在于“分清楚哪些流量该打回去”。很多人一遇到流量高峰就急着封IP、上验证码、调阈值，结果误伤正常用户，攻击却照样穿透。根本原因是缺少一条可信的流量基线。没有基线，所有防御动作都是盲目的。构建业务流量基线，本质上是把“正常业务长什么样”量化成一整套可观测、可比较、可告警的指标集合，让异常流量在对比中自己暴露出来。
流量基线不是简单的“平时每秒多少请求”。一个真正能用于CC攻击防御的基线，至少包含四个维度：时间维度、行为维度、来源维度和业务逻辑维度。时间维度解决“这个时间点应该有多少流量”，行为维度解决“单个访问者应该怎么操作”，来源维度解决“流量从哪来、是否合理”，业务逻辑维度解决“哪些请求路径是合法且必要的”。四个维度交叉验证，才能把攻击流量从正常业务中剥离出来。
先建立时间维度的请求量基线取过去至少30天的访问日志，按分钟粒度聚合请求数。不要只看平均值，平均值会掩盖波动。要计算每个时间点的P50、P95、P99分位值，以及同比上周同期的波动区间。例如某个业务每天上午10点的P95是每分钟800请求，P99是1200请求，那么当实时流量突然冲到每分钟3000请求且持续超过3分钟，就可以判定为异常。这里的关键是“持续”，CC攻击往往是突发且持续的，而正常业务的抖动通常会在短时间内回归。
时间基线还要区分工作日、周末、节假日、活动日。电商大促、游戏版本更新、金融行业月底结算，这些时间点的流量模型完全不同。如果用一个固定阈值覆盖所有日期，要么频繁误报，要么攻击漏报。建议按日期类型分别建立基线，至少拆成“普通工作日”“普通周末”“特殊活动日”三类。特殊活动日的基线要单独建模，因为活动期间的流量可能是平时的5到10倍，用普通基线去衡量必然误判。
行为基线是识别CC攻击最核心的部分CC攻击模拟的是真实用户请求，但模拟得再像，行为模式也会露出破绽。正常用户访问一个网站，会有页面停留时间、会有点击跳转、会有资源加载顺序、会有随机的操作间隔。而CC攻击工具发起的请求往往是机械的、均匀的、目标单一的。构建行为基线时，需要统计每个会话的请求间隔分布、URL访问序列、User-Agent与请求特征的匹配度、Cookie是否完整、是否执行了JavaScript。
举例来说，一个正常用户从进入首页到点击商品详情，再到加入购物车，中间会有几秒到几十秒的间隔，而且会加载页面上的CSS、JS、图片等静态资源。CC攻击的请求流通常是密集且连续的，只请求动态接口，不加载静态资源，或者请求间隔高度一致。把这些特征量化：正常会话的请求间隔中位数通常在5秒以上，而攻击会话的间隔中位数可能不到1秒；正常会话的静态资源请求占比通常在40%以上，而攻击会话可能低于5%。这些数字就是行为基线的具体内容。
来源基线要关注IP、设备和网络属性单纯看IP已经不够了，因为攻击者大量使用代理池和僵尸网络，IP分散度很高。但来源基线仍然有价值，关键在于看IP的“行为历史”和“属性一致性”。一个IP过去30天从未访问过你的业务，突然在某一天发起大量请求，这就是可疑信号。一个IP声称自己是某个地区的用户，但请求头中的语言设置、时区信息、运营商归属与声称地区不匹配，也是可疑信号。
设备指纹是来源基线中更稳定的维度。通过浏览器指纹、TLS指纹、Canvas指纹等技术，可以识别出同一台设备即使更换IP也能被关联。正常业务中，同一设备在短时间内发起大量请求的概率很低。如果发现同一个设备指纹在1分钟内请求了200次登录接口，无论IP怎么变，都可以直接判定为攻击。来源基线还包括ASN（自治域编号）分布。正常业务的流量来源ASN通常相对稳定，如果突然出现大量来自陌生ASN的请求，尤其是来自IDC机房或云服务商的ASN，就需要重点排查。
业务逻辑基线是最容易被忽略但最有效的防线每个业务都有自己独特的逻辑链路。登录、注册、下单、支付、查询，这些操作的先后顺序和依赖关系是固定的。正常用户不可能在没有浏览商品的情况下直接提交订单，也不可能在没有获取验证码的情况下直接完成注册。业务逻辑基线就是把合法的状态机定义清楚，然后在流量入口处校验每个请求是否符合状态机的前置条件。
举个例子，一个正常的登录流程是：先GET登录页面，再POST账号密码，如果开启了验证码，还要先GET验证码图片。CC攻击工具往往直接高频POST登录接口，跳过了GET页面和验证码环节。如果在基线中定义“POST登录接口前5秒内必须有GET登录页面的记录”，那么那些直接POST的请求就可以被识别出来。业务逻辑基线需要与后端业务系统打通，获取会话状态和用户ID的关联信息，才能做深度校验。这部分工作量大，但误报率极低，因为攻击者很难完全模拟业务逻辑的每一个细节。
基线的落地需要一套自动化计算和更新机制流量基线不是一次性建好就一劳永逸的。业务在变化，用户行为在变化，攻击手法也在变化。基线需要定期自动更新，建议按天滚动计算过去30天的数据，每天生成新的基线快照。对于波动较大的业务，可以采用加权移动平均，让近期数据的权重更高。更新频率要平衡灵敏度和稳定性，更新太快会导致基线被攻击流量“污染”，更新太慢则无法适应业务变化。
在工程实现上，可以用Flink或Spark Streaming实时计算请求指标，与离线计算的基线快照进行比对。比对逻辑不要只用一个阈值，而是用多条件组合判断。例如：实时请求量超过基线P99分位值2倍，且来源IP中陌生IP占比超过60%，且请求间隔中位数低于1秒，三个条件同时满足才触发告警。这样可以大幅降低误报率。
基线构建完成后，要形成分层响应策略有了基线，防御动作就可以分级执行。第一级是观察，当流量超过基线但未达到告警阈值时，只记录日志不干预。第二级是挑战，当流量超过P95分位值且行为特征可疑时，对可疑会话弹出验证码或执行JavaScript挑战。第三级是限制，当流量超过P99分位值且多个维度同时异常时，对来源IP或设备指纹进行限速或封禁。第四级是切换，当攻击流量远超业务承载能力时，启用备用线路或静态化页面，优先保障核心业务可用。
分层响应的好处是避免“一刀切”。很多CC攻击防御失败的原因就是阈值设置得太敏感，一有风吹草动就全员验证码，结果正常用户全部流失。有了精细化的基线，才能做到精准打击，让正常用户无感知，让攻击流量被拦截在业务之外。
实际构建过程中常见的三个坑第一个坑是只统计请求数，不区分请求类型。一个页面请求和一个API请求的成本完全不同，攻击者往往集中打API接口，因为API响应慢、消耗资源大。基线必须按URL路径和请求类型分别统计，至少要把静态资源和动态接口分开。第二个坑是忽略HTTPS握手和TLS层面的特征。很多CC攻击工具在TLS握手阶段就会暴露特征，比如TLS版本过低、密码套件固定、SNI与Host不一致。这些特征在应用层看不到，但在流量基线中应该包含。第三个坑是基线数据被攻击流量污染。如果攻击持续了很长时间，而基线更新时把这些攻击流量也算了进去，基线就会被抬高，导致后续攻击无法被识别。解决方法是做异常数据剔除，在计算基线时先剔除那些明显偏离历史分布的时间段。
构建CC攻击防御业务流量基线，本质上是一个数据工程加安全运营的复合工作。它不需要多么高深的技术，但需要耐心和细致。把每一个维度的数据采集全、统计准、更新勤，让基线真正反映业务的真实面貌，CC攻击的识别就会从玄学变成科学。当攻击来临时，你不再需要猜测“这波流量是不是攻击”，因为基线会告诉你答案。
