基于TokenBucket算法的CC攻击平滑限流

CC攻击之所以难防，根本原因在于它不像洪水攻击那样单纯靠带宽取胜，而是通过模拟正常用户的HTTP请求，精准消耗服务器的CPU、数据库连接和内存资源。传统的基于固定阈值的IP黑名单方案，在面对精心构造的低频慢速CC攻击时，往往显得力不从心——阈值设高了拦不住，设低了又误杀正常用户。更棘手的是，攻击者现在普遍使用代理池，每个IP只发寥寥数个请求，单看IP维度的频率统计完全失效。要解决这个问题，我们需要把思路从“封禁”转向“平滑限流”，而TokenBucket算法正是实现这一转变的核心利器。

提到限流，很多人第一反应是滑动窗口计数器。滑动窗口确实能解决固定窗口的边界突刺问题，但它本质上依然是一个“硬限流”方案。假设你设定1秒内允许10个请求，滑动窗口会在第11个请求到来时直接拒绝，这种非黑即白的处理方式在防御CC攻击时存在两个致命缺陷：一是攻击者可以通过不断试探阈值，精确控制攻击频率刚好卡在阈值之下，持续消耗资源；二是正常用户在流量突发时会被误伤，比如页面刷新、批量操作等场景。

TokenBucket的精妙之处在于引入了“桶”和“令牌”的抽象。想象一个容量固定的桶，系统以恒定速率向桶中放入令牌，每个请求到达时必须先从桶中取走一个令牌才能被处理，桶满则令牌丢弃。这个模型天然支持突发流量——只要桶里有足够的令牌积攒，短时间内可以处理远超平均速率的请求；而一旦令牌耗尽，请求就会被延迟处理或直接拒绝，但拒绝是渐进的、可预期的。对于CC攻击来说，TokenBucket的平滑特性使得攻击者无法通过精确控制频率来规避限制，因为桶的填充速率和容量共同决定了系统的承受能力，攻击者很难同时探测出这两个参数。

从数学角度看，TokenBucket算法描述的是一个带有上限的速率积分过程。设桶容量为C，令牌填充速率为r（个/秒），当前令牌数为T。每个时间间隔Δt内，令牌数增加r×Δt，但不超过C。请求到达时，若请求所需令牌数n≤T，则T=T-n，请求通过；否则请求被限流。这个模型的关键在于，r决定了系统的长期平均处理速率，C决定了系统能承受的最大突发量。

在CC防御场景下，参数设计不能拍脑袋。r的值应该基于后端服务的真实处理能力来设定，而不是简单地设一个“看起来合理”的数字。我的建议是：先对业务接口做压力测试，找到响应时间开始明显恶化的临界QPS，然后取这个临界值的60%-70%作为r。这样做是为了给系统留出缓冲空间，避免在限流生效前服务就已经被打垮。C的值则取决于业务对突发流量的容忍度，通常可以设为r的1.5到2倍，这样既能应对正常的流量波动，又不会给攻击者留下太大的利用空间。

一个经常被忽视的细节是令牌的消耗粒度。大多数实现默认每个请求消耗1个令牌，但对于CC攻击防御，我强烈建议根据请求的资源消耗权重来消耗不同数量的令牌。比如，一个涉及复杂数据库查询的API调用可以消耗3-5个令牌，而一个静态资源请求只消耗1个。这样可以让限流策略更精准地保护后端瓶颈资源，而不是一刀切地限制所有请求。

理论说完了，我们来看具体实现。下面是一个基于Redis的生产级TokenBucket限流器，使用Lua脚本保证原子性操作：

-- token_bucket.lua
-- KEYS[1]: 桶的key
-- ARGV[1]: 桶容量C
-- ARGV[2]: 令牌填充速率r（个/秒）
-- ARGV[3]: 当前请求需要消耗的令牌数n
-- ARGV[4]: 当前时间戳（秒，可以是小数）

local bucket_key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local requested = tonumber(ARGV[3])
local now = tonumber(ARGV[4])

-- 获取桶的当前状态
local bucket = redis.call('HMGET', bucket_key, 'tokens', 'last_refill_time')
local tokens = tonumber(bucket[1])
local last_refill_time = tonumber(bucket[2])

-- 首次访问，初始化桶
if tokens == nil then
    tokens = capacity
    last_refill_time = now
end

-- 计算应该补充的令牌数
local elapsed = math.max(0, now - last_refill_time)
local refill_tokens = elapsed * rate
tokens = math.min(capacity, tokens + refill_tokens)
last_refill_time = now

-- 判断令牌是否足够
local allowed = false
if tokens >= requested then
    tokens = tokens - requested
    allowed = true
end

-- 更新桶状态，设置过期时间防止内存泄漏
local ttl = math.ceil(capacity / rate) + 1
redis.call('HMSET', bucket_key, 'tokens', tokens, 'last_refill_time', last_refill_time)
redis.call('EXPIRE', bucket_key, ttl)

-- 返回结果：是否允许，剩余令牌数，距离下次可能有足够令牌的时间（秒）
local retry_after = 0
if not allowed then
    retry_after = math.ceil((requested - tokens) / rate)
end

return {allowed and 1 or 0, tokens, retry_after}

这段Lua脚本在Redis中原子性地完成了令牌补充、判断和扣减的全过程，避免了分布式环境下的竞态条件。调用方可以根据返回的retry_after字段，在HTTP响应中设置Retry-After头，告诉客户端多久之后可以重试，这是一种更友好的限流反馈方式。

在实际部署中，桶的key设计至关重要。对于CC攻击防御，我建议采用多维度组合键：IP维度、用户ID维度、API路径维度，三者取交集。比如key可以设计为"ratelimit:ip:192.168.1.1:user:12345:api:/search"。这样即使攻击者更换IP，只要用户ID相同就会被限流；即使攻击者更换账号，只要IP相同也会被限流；而正常用户访问不同API时，限流是独立计算的，不会互相干扰。这种多维度组合策略极大地提高了攻击者绕过限流的成本。

基础版的TokenBucket已经能解决大部分问题，但要应对高级CC攻击，还需要做几项增强。首先是分层限流架构。在网关层部署全局TokenBucket，桶容量和填充速率根据整个集群的处理能力来设定，这是第一道防线。在服务层，每个后端实例再各自维护一个TokenBucket，参数根据单机处理能力设定，这是第二道防线。两层之间通过响应时间反馈动态调整——当后端实例的响应时间超过阈值时，主动降低网关层对应桶的填充速率，形成闭环控制。

其次是引入惩罚机制。当某个维度的请求被限流后，不仅仅是拒绝当前请求，还应该对该维度的桶容量进行临时削减。比如，正常桶容量是100，一旦检测到该IP连续3次触发限流，将桶容量临时降为20，持续30秒。这种“信任降级”策略能有效压制攻击行为，同时对偶尔触发限流的正常用户影响很小。

还有一个容易被忽略的点是令牌填充速率的动态调整。固定的r值无法适应业务的潮汐特性——凌晨时段的正常流量远低于白天，如果r值一成不变，攻击者在凌晨发起攻击时，相对影响会更大。解决方案是根据历史流量数据，分时段预设不同的r值，或者更智能地，通过实时监控请求的响应时间和错误率，用PID控制器动态调节r值，使系统始终运行在安全边界内。

TokenBucket不是银弹，它应该与现有的防御手段协同工作。IP黑名单依然有用，但触发条件应该从“超过固定阈值”改为“TokenBucket持续耗尽且retry_after超过某个值”。验证码挑战可以作为TokenBucket限流后的升级措施——当请求被限流时，返回验证码页面而不是直接拒绝，用户通过验证后获得临时的高容量令牌桶。这样既保证了安全，又最大程度保留了正常用户的访问体验。

对于应用层的CC攻击，比如针对搜索接口的慢查询攻击，TokenBucket可以与请求队列配合使用。当令牌不足时，请求不立即拒绝，而是进入优先级队列等待令牌补充。正常用户的请求可以标记为高优先级，优先获取令牌；而未登录用户或新用户的请求标记为低优先级。这种机制在流量高峰时能有效保障核心用户的体验，同时让攻击者的请求在队列中无限等待，自然耗尽攻击资源。

限流策略上线后，监控是持续优化的基础。需要重点关注的指标包括：令牌桶的耗尽频率、retry_after的分布、限流后的业务错误率变化、以及后端资源的实际负载。一个常见的误区是只监控被限流的请求数量，却忽略了限流是否真正保护了后端。如果限流触发频繁但后端负载依然很高，说明r值设置偏高；如果限流很少触发但用户投诉不断，可能是r值偏低或者突发容量C不够。

我的实践经验是，初期将r值设得相对保守，观察一周的业务数据和攻击数据后，逐步放宽参数。同时建立告警机制，当令牌桶耗尽频率在短时间内急剧上升时，大概率是攻击行为，可以自动触发更严格的限流策略或通知安全团队介入。这种“宽松基线+异常检测”的组合，比一开始就设置严苛的阈值要合理得多。

TokenBucket算法的优雅之处在于，它用极简的模型解决了限流场景中最核心的矛盾——安全性与可用性的平衡。在CC攻击防御中，它让我们从粗暴的封禁思维中跳脱出来，转而追求一种弹性的、自适应的流量整形能力。当攻击流量和正常流量混杂在一起时，TokenBucket不是试图精确区分二者，而是通过控制整体的资源消耗速率，确保系统始终运行在可承受的范围内。这种思路不仅适用于安全防御，对于任何需要保护后端服务稳定性的场景，都具有普适的借鉴意义。