CC攻击与业务高峰并存的智能识别与灰度限流方案

CC攻击的本质是耗尽服务器资源，而业务高峰的本质是真实流量涌入，两者在表象上高度相似——都是高并发请求，都可能触发CPU飙升、带宽占满、响应延迟。区别在于，一个是无效的恶意消耗，一个是有效的商业价值。把两者分开处理是传统思路，但现实场景中它们往往是叠加发生的，攻击者恰恰喜欢挑选业务高峰时段下手，因为此时运维团队注意力分散、阈值告警容易被淹没、封禁策略稍有不慎就会误伤真实用户。

所以真正要解决的问题不是“怎么防CC”，也不是“怎么扛高峰”，而是“在攻击与高峰并存的混合流量中，如何精准识别恶意请求并实施不影响正常业务的限流”。这需要一套智能识别模型加灰度限流机制的组合方案。

智能识别的第一步不是上算法，而是把特征工程做扎实。混合流量中，我们需要从三个维度分层提取特征：

网络层特征：请求频率、连接持续时间、SYN包比例、TLS握手完成率、空连接占比。CC攻击工具往往在TLS握手阶段就暴露问题，大量只握手不传输数据的连接是重要信号。

应用层特征：URL访问分布、请求方法分布、User-Agent熵值、Referer合法性、Cookie有效性。正常业务高峰时，热门URL的访问量会成比例增长，而CC攻击通常集中在少数几个高消耗接口，形成明显的长尾断层。

行为层特征：页面停留时间、二次请求概率、鼠标轨迹上报频率、验证码通过率。这一层是区分人与机器的核心，但需要前端埋点配合，数据采集成本较高。

三层特征交叉组合后，可以构建一个多维特征向量。关键是特征要实时计算，不能依赖离线批处理，因为攻击窗口往往只有几分钟。

静态阈值在混合场景下基本无效。设一个固定的“每秒500请求就封IP”的规则，业务高峰时真实用户可能轻松突破这个数字，而攻击者可以控制在499来绕过。必须用动态基线。

具体做法是：对每个特征维度维护一个时间滑动窗口，窗口长度建议取5分钟到15分钟，步长1分钟。在每个窗口内计算该特征的统计分布，不只用均值，还要用分位数。比如P95、P99的请求频率，P5、P1的页面停留时间。当某个IP的特征值偏离当前窗口的P99或P1分位数超过一定倍数时，标记为异常。

这里有一个容易被忽视的细节：基线更新频率要自适应。如果检测到当前窗口内异常流量占比已经超过30%，说明基线本身可能已被污染，此时应冻结基线更新，改用上一个正常窗口的基线继续检测。否则攻击者可以通过缓慢抬升请求量的方式“训练”基线，最终让恶意流量被纳入正常范围。

单靠规则引擎处理不了复杂混合场景，需要引入机器学习模型做多维决策。推荐使用轻量级集成模型，比如XGBoost或LightGBM，推理速度快，适合在线部署。

训练数据构建是难点。正样本取历史业务高峰期的真实用户行为数据，负样本取已知CC攻击的日志，再加上一部分正常低谷期的数据作为补充。标签需要人工审核，避免把之前的漏报攻击当成正常流量喂给模型。

模型输出的不是二分类，而是一个0到1之间的风险分数。这个分数不直接决定封禁，而是作为灰度限流引擎的输入参数。模型需要每天增量训练，因为攻击手法在变，业务模式也在变。特征重要性分析可以定期输出，帮助安全团队理解当前攻击的主要特征是什么。

识别出风险之后，传统的做法是直接封IP或者弹验证码，这在混合场景下太粗暴。灰度限流的核心思想是：根据风险分数，对请求实施不同程度的降级处理，而不是二元化的放行或阻断。

具体实现上，可以把限流动作分为四个灰度等级：

等级0（风险分0-30）：正常放行，不做任何干预。

等级1（风险分30-60）：优先级降级。请求仍然处理，但进入低优先级队列，在高负载时可能延迟增加，但不会被拒绝。用户侧几乎无感知。

等级2（风险分60-85）：功能降级。返回缓存内容或精简版页面，关闭个性化推荐、实时计算等非核心功能模块，减少后端资源消耗。

等级3（风险分85-100）：交互验证。弹出无感验证码或要求完成一次客户端工作量证明，验证通过后降级到等级1重新进入。

这套灰度机制的关键在于：同一个IP的风险分是动态变化的，不是一成不变的。一个真实用户在业务高峰时可能因为请求频率高被短暂标记为等级1，但随着他正常浏览行为的积累，风险分会逐渐回落。而攻击脚本由于行为模式单一，风险分会持续攀升，最终被引导到等级3的验证环节。

灰度限流底层需要高效的计数和限流算法支撑。单机场景用令牌桶足够，但CC攻击和业务高峰都是分布式场景，需要跨节点的全局计数。

推荐使用Redis集群做分布式计数器，数据结构选择Sorted Set，以时间戳为score，每个请求写入一个member。查询时用ZREMRANGEBYSCORE清理过期数据，再用ZCOUNT统计当前窗口内的请求数。这个方案比简单的INCR+EXPIRE更灵活，可以支持任意滑动窗口的精确计数。

但Redis本身也会成为瓶颈。优化手段包括：使用Redis Cluster分片，按IP哈希分布到不同节点；对计数做概率性采样，比如只对10%的请求做精确计数然后推算总量，误差在可接受范围内；本地内存做一级缓存计数，每累积到一定量再批量同步到Redis，减少网络开销。

# Redis滑动窗口计数的Lua脚本示例
# 保证原子性操作
local key = KEYS[1]
local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local member = ARGV[4]

redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count < limit then
    redis.call('ZADD', key, now, member)
    redis.call('EXPIRE', key, window)
    return 1
else
    return 0
end

这段脚本在Redis服务端原子执行，避免了多次网络往返带来的竞态问题。实际部署时，key的粒度可以细化到IP+接口级别，window和limit参数由灰度等级动态决定。

等级3的交互验证不一定非要用传统验证码，用户体验太差。可以采用客户端工作量证明的方案：服务端下发一个随机挑战值，客户端需要用JavaScript计算一个哈希难题，比如找到一个nonce使得SHA256(challenge+nonce)的前N位为零。N的取值根据风险分动态调整，风险越高N越大，计算耗时越长。

这个方案对正常用户几乎无感，因为浏览器在后台执行计算，耗时几百毫秒到几秒不等，用户可能正在阅读页面内容。但对攻击脚本来说，每个请求都要消耗CPU资源做哈希计算，大幅抬高了攻击成本。而且这个计算是客户端完成的，不消耗服务端资源。

方案部署后必须通过全链路压测来验证，不能只靠线上灰度发布慢慢观察。压测需要模拟混合流量：一部分是正常业务请求，按照历史高峰的流量模型回放；另一部分是模拟CC攻击的恶意请求，包括HTTP Flood、Slowloris慢速攻击、针对特定接口的密集请求。

验证指标包括：真实流量的成功率是否保持在99%以上、P99延迟是否在可接受范围内、恶意流量的拦截率是否达到预期、误封率是否低于0.1%。压测过程中要特别关注灰度等级分布，理想情况下真实流量应该集中在等级0和等级1，恶意流量集中在等级2和等级3。

压测还会暴露工程层面的问题，比如Redis集群在高并发下的性能瓶颈、模型推理的延迟是否影响请求处理、跨机房场景下网络延迟对全局计数准确性的影响。这些问题在压测阶段解决比线上发现要安全得多。

这套方案不是一劳永逸的。攻击者会不断调整策略，业务模式也会变化，需要建立持续运营机制。每天分析前一天的误封申诉和漏报案例，把误封的真实用户行为补充到训练集的正样本中，把漏报的攻击流量补充到负样本中，模型每周重新训练上线。

同时要关注灰度等级的时间分布曲线。如果发现等级2和等级3的流量占比突然升高，可能是新的攻击手法出现，需要人工介入分析。如果等级1的占比持续偏高，可能基线过于敏感，需要调整异常检测的阈值参数。

这套智能识别与灰度限流方案的核心价值在于：不追求100%的准确识别，而是通过灰度机制容忍一定的不确定性，在误伤和漏过之间找到一个动态平衡点。业务高峰不再是安全防护的软肋，反而因为流量大、样本多，模型能够更准确地学习正常行为模式，让攻击者更难隐藏。