当CC攻击（Challenge Collapsar）来袭，攻击者会模拟真实用户请求，持续消耗应用资源，导致服务不可用。相比DDoS攻击打满带宽，CC攻击更隐蔽，因此防护方案需要精准识别并限制异常流量。本文聚焦于使用Redis实现滑动窗口限流这一成熟方案，给出可落地的操作步骤、参数取舍和失败条件，帮助你在应用层构建第一道防线。
首先明确边界：滑动窗口限流并非万能。它主要防御单IP或单用户的超高频率请求，对于分布式攻击（大量IP协同低频请求）效果有限。Cloudflare的DDoS防护体系中也强调，应用层攻击需要结合多种信号（如行为分析）才能有效应对。因此，本文方案适合作为基础防护层，需与其他手段配合使用。
为什么选择滑动窗口限流
常见的限流算法有固定窗口、滑动窗口和令牌桶。固定窗口实现简单，但存在临界问题：在窗口切换瞬间，请求量可能达到两倍阈值。令牌桶允许突发流量，适合流量整形，但对于精确控制CC攻击的请求速率，滑动窗口能更平滑地限制速率，避免突发穿透。
滑动窗口本质是记录每个请求的时间戳，并统计窗口内请求数。Redis的ZSET（有序集合）天然适合存储时间戳，并支持范围查询和计数，配合Lua脚本可实现原子操作，避免并发竞争。
基于Redis ZSET的滑动窗口实现
核心思路：为每个限流对象（如IP、用户ID）维护一个ZSET，成员为请求唯一标识（如UUID），分数为请求时间戳。每次请求时，移除窗口外的旧成员，统计剩余数量，若超过阈值则拒绝。
-- Lua脚本：滑动窗口限流
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2]) -- 窗口大小，单位秒
local limit = tonumber(ARGV[3]) -- 最大请求数
-- 移除窗口外数据
redis.call('ZREMRANGEBYSCORE', key, 0, now - window * 1000)
-- 统计当前窗口请求数
local count = redis.call('ZCARD', key)
if count < limit then
redis.call('ZADD', key, now, now .. '-' .. math.random(1000000))
redis.call('EXPIRE', key, window)
return 1
else
return 0
end调用时传入当前毫秒时间戳、窗口大小（如10秒）和阈值（如20次）。脚本原子执行，保证并发安全。使用毫秒时间戳可提高精度，但需注意ZSET的分数为双精度浮点，毫秒级足够。
参数调优与取舍
窗口大小和阈值需要根据业务场景调整。例如，一个API接口正常用户每秒最多请求2次，可设置窗口10秒、阈值20。如果业务允许突发（如秒杀），可适当增大窗口或阈值，但会增加CC攻击的容错空间。
另一个关键参数是ZSET的过期时间。脚本中设置了EXPIRE，防止键无限增长。对于活跃IP，每次请求都会刷新过期时间，因此内存占用可控。但若攻击者使用大量随机IP（IP伪造），每个IP都会创建键，可能导致Redis内存暴涨。此时可考虑只对已识别的高危IP启用限流，或使用IP+URI组合键，减少键数量。
部署与集成要点
在实际部署中，通常将限流逻辑放在API网关或Web应用的前置中间件。以Nginx+Lua为例，可在access阶段调用Redis脚本，若返回0则返回429状态码。若使用Cloudflare Workers这类边缘计算平台，也可通过其KV或Durable Objects实现类似逻辑，但Redis方案更适合自建服务器。
需要注意Redis的可用性。如果Redis故障，限流会失效，因此需配置Redis高可用（如哨兵或集群），或设置降级策略（如失败放行）。同时，尽量减少网络开销，使用Redis Pipeline或连接池。
失败条件与常见误区
滑动窗口限流并非银弹，存在以下失败条件：
- 分布式攻击：攻击者分散在大量IP，每个IP请求量低于阈值，但总量巨大。滑动窗口无法识别这种模式，需结合其他手段（如行为分析、指纹库）。
- 代理池：攻击者使用代理IP，导致IP变化频繁，限流效果大打折扣。
- 误杀正常用户：如果阈值设置过小，可能影响正常用户（如校园网出口IP共享）。需通过灰度发布和监控调整参数。
常见误区包括：仅依赖IP限流，忽视用户身份；忽略Redis性能瓶颈；未设置键过期导致内存泄漏；脚本逻辑错误导致原子性失效。
与其他防护手段协同
滑动窗口限流应作为纵深防御的一环。Cloudflare的DDoS防护文档指出，其自动系统会结合多种规则检测和缓解应用层攻击，包括速率限制、行为分析和挑战页面。对于高防场景，可将Redis限流与WAF、CDN配合使用，例如在边缘节点先过滤明显恶意流量，再对源站应用限流。
此外，可结合Cloudflare Workers等边缘计算，将限流逻辑部署在离用户更近的位置，减少回源压力。但需注意，边缘计算平台可能有自身的速率限制和计费规则，需评估成本。
总结
使用Redis实现滑动窗口限流是抵御CC攻击的有效手段，但需明确其边界，合理配置参数，并与其它防护措施协同。本文提供了完整的实现方案和调优思路，你可以根据业务场景进行适配。记住，安全防护是持续的过程，需要不断监控和调整。
参考资料
延伸阅读