基于滑动窗口限流算法对抗短时CC攻击

短时CC攻击的本质不再是拼带宽，而是拼服务器处理逻辑的漏洞。攻击者利用极短时间内的海量并发请求，榨干后端数据库连接池或应用线程。传统的固定窗口限流，比如每秒限制100次请求，存在致命的边界临界问题。假设我们在时间窗口的最后一毫秒和下一窗口的第一毫秒分别涌入100次请求，实际上服务器在两毫秒内承受了200次请求的压力，这足以让没有做并发优化的服务瞬间熔断。要对抗这种脉冲式的短时攻击，必须引入滑动窗口限流算法，它不重置计数器，而是基于时间轴的连续滚动统计，彻底抹平了固定窗口的突刺风险。

滑动窗口限流并不是一个复杂的数学游戏，它的核心在于将时间轴视为一个不断向前滚动的数据流。我们可以把时间窗口切分成更细粒度的格子，比如把1秒的窗口切分为10个100毫秒的小格子。每一个请求到来时，算法会计算当前时间点往前推1秒这个区间内，所有小格子的请求总数。随着时间流逝，窗口不断向前滑动，过期的格子被丢弃，新的请求落入当前的格子。这种机制保证了任意时间点的统计范围都是过去整整1秒，而不是人为割裂的固定区间。对于短时CC攻击，攻击流量往往集中在毫秒级爆发，滑动窗口能精准捕捉到这种瞬时密度，因为它在统计时永远看的是“刚刚过去的这一秒”，没有死角。

实现滑动窗口限流，数据结构的选择直接决定了抗攻击时的系统开销。最直观的做法是使用Redis的ZSET，也就是有序集合。每个用户或IP作为key，请求的时间戳作为score，member可以用唯一标识或时间戳本身。每次请求进来，先插入当前时间戳，然后移除窗口外的过期记录，最后统计集合内的元素数量。这种方法精度极高，可以做到毫秒级控制，但在高并发下，ZSET的插入和删除操作会产生不小的内存和CPU开销。另一种更轻量的方案是使用Redis的List结合定时修剪，但精度稍差。如果追求极致性能，可以采用令牌桶算法的变种，在本地内存中使用环形缓冲区，每个槽位存储该时间片的计数，通过原子操作更新。不过本地内存方案在分布式环境下需要解决一致性问题，通常配合一致性哈希做流量路由，让同一IP的请求始终落到同一台机器。

下面给出一个基于Redis ZSET的滑动窗口限流实现，这段代码可以直接用于生产环境，前提是做好连接池配置和异常降级。

import redis
import time

class SlidingWindowRateLimiter:
    def __init__(self, redis_client, window_size=1, max_requests=100):
        self.redis = redis_client
        self.window_size = window_size  # 窗口大小，单位秒
        self.max_requests = max_requests  # 窗口内最大请求数

    def is_allowed(self, user_key):
        current_time = time.time()
        window_start = current_time - self.window_size
        
        # 使用管道保证原子性
        pipe = self.redis.pipeline()
        # 移除窗口外的过期记录
        pipe.zremrangebyscore(user_key, 0, window_start)
        # 添加当前请求的时间戳
        pipe.zadd(user_key, {str(current_time): current_time})
        # 统计当前窗口内的请求数
        pipe.zcard(user_key)
        # 设置key的过期时间，避免内存泄漏
        pipe.expire(user_key, self.window_size + 1)
        
        results = pipe.execute()
        current_count = results[2]
        
        return current_count <= self.max_requests

这段代码的精髓在于使用了Redis的Pipeline机制，将多个操作打包成一个原子事务。zremrangebyscore负责清理过期数据，zadd插入新记录，zcard统计总数。最后设置一个略大于窗口的过期时间，防止冷数据占用内存。在实际压测中，这套逻辑在普通云服务器上可以轻松支撑每秒数万次判断，完全满足中小型业务的防护需求。

单靠滑动窗口限流还不足以完全抵御高级CC攻击。攻击者往往会伪造大量IP，或者使用代理池分散请求，使得每个IP的请求量看起来都不超标。这时需要引入多层防御体系。第一层在网络边缘做IP信誉库过滤，直接丢弃已知的恶意IP。第二层在应用入口做滑动窗口限流，但统计维度不能仅仅是IP，还需要结合设备指纹、会话ID甚至请求路径特征。比如同一个IP在1秒内访问同一URL超过阈值，直接触发人机验证。第三层在业务逻辑层做深度行为分析，识别出那些虽然频率不高但请求模式异常的流量，比如总是访问需要大量数据库查询的接口。

固定阈值最大的问题是无法应对正常流量波动。比如电商大促期间，正常用户的请求频率可能是平时的十倍，如果限流阈值写死，就会误伤真实用户。滑动窗口算法可以结合机器学习做动态阈值调整。具体做法是实时采集每个时间窗口的请求量，使用指数加权移动平均算法计算流量基线。当实际流量超过基线的N倍时，才触发限流。这种自适应机制能有效区分正常流量尖峰和恶意攻击。实现时可以在Redis中额外存储一个基线值，每次请求时不仅判断是否超限，还更新基线。基线更新的频率和权重需要根据业务特点调参，一般取最近5分钟的数据，衰减因子设为0.9，这样既能平滑噪声，又能快速响应流量变化。

在多实例部署的场景下，滑动窗口限流面临数据一致性的挑战。如果每个实例都维护自己的本地计数器，那么总限流阈值就会被放大实例数量倍。集中式计数用Redis是常规解法，但Redis本身也会成为瓶颈。优化手段包括：对用户ID做哈希分片，让同一用户的请求路由到固定的限流实例，这样本地内存计数就能生效，避免了网络开销。如果必须使用集中式计数，可以考虑将窗口精度从1秒放宽到100毫秒，减少Redis的写入频率。具体做法是客户端预聚合，每100毫秒将本地计数批量推送到Redis，虽然牺牲了少量精度，但换来了数倍的性能提升。对于大多数业务，100毫秒的延迟在限流场景下完全可接受。

任何限流策略都存在误杀可能，滑动窗口也不例外。当用户被限流后，直接返回429状态码是最粗暴的做法，会导致用户流失。更合理的做法是分级处理。首次超限可以返回一个带有验证码的页面，用户完成验证后将其加入白名单，在一定时间内免限流。对于API接口，可以返回一个带有Retry-After头部的响应，告知客户端何时可以重试。同时，在限流触发时记录详细日志，包括用户标识、触发时间、当前窗口计数等，便于后续分析和调优。这些日志也是发现攻击特征的重要数据源，通过分析被限流的请求模式，可以反向提取攻击者的特征，更新防护规则。

部署滑动窗口限流后，必须通过严格的压测来验证效果。使用wrk或ab工具模拟短时CC攻击，观察服务器的CPU、内存和响应延迟变化。重点关注两个指标：一是在攻击流量下，正常用户的请求是否仍然能得到及时响应；二是限流模块本身的资源消耗是否在可接受范围内。压测时应该模拟多种攻击模式，包括固定频率攻击、脉冲式攻击和慢速连接耗尽攻击。滑动窗口对前两种效果显著，但对慢速连接攻击需要配合连接超时和最大连接数限制。压测结果要形成报告，记录不同攻击强度下的防护成功率和误杀率，这些数据是后续调参的依据。

滑动窗口限流算法之所以成为对抗短时CC攻击的首选，是因为它用极简的逻辑解决了固定窗口的边界缺陷，同时保持了高性能和易实现的特点。在实际应用中，结合多层防御、动态阈值和分布式优化，可以构建起一道坚固的防线。关键在于不要把它当成一个孤立的组件，而是融入到整体的安全架构中，与WAF、行为分析、威胁情报联动，才能发挥最大效能。