CC防护之IP频率限制与滑动窗口算法实现

CC攻击防护的核心手段之一就是IP频率限制，而滑动窗口算法是实现精准限流最实用的技术方案。简单来说，CC攻击就是攻击者用大量请求在短时间内压垮目标服务器，而IP频率限制的逻辑是：统计每个IP在一定时间窗口内的请求次数，超过阈值就拒绝或延迟响应。滑动窗口相比固定窗口的最大优势在于，它能避免"窗口边界"问题——比如固定窗口在第59秒和第61秒各来一波请求，明明1秒内超过了限制，但因为跨了窗口反而被放行。滑动窗口通过细粒度的时间切片，把请求按时间戳精确归类，真正做到"任意时间段内都不超限"。下面我会从原理、实现、优化、部署四个层面把这套东西讲透。

一、CC攻击与IP频率限制的基本逻辑

CC攻击（Challenge Collapsar）本质上是应用层的DDoS，攻击者模拟正常用户行为，用高频请求消耗服务器资源。常见的目标包括登录接口、搜索接口、API接口等。防御的第一道防线就是在网络层或应用层对单个IP做频率管控。

IP频率限制的规则通常这样设定：单个IP在1分钟内最多允许60次请求，或者在10秒内最多允许10次请求。超过阈值后，可以选择直接返回429状态码、加入队列等待、或者触发验证码挑战。这套逻辑看似简单，但实现方式的选择直接决定了防护的精准度和系统性能。

常见的实现方式有三种：固定窗口计数器、令牌桶算法、滑动窗口算法。固定窗口最简单但有边界漏洞；令牌桶适合控制平均速率但对突发流量不够敏感；滑动窗口在精准度和性能之间取得了最好的平衡，是目前中大型系统最推荐的方案。

二、滑动窗口算法的核心原理

滑动窗口的核心思想是：不按固定的时间块（比如每分钟一个桶）来统计，而是维护一个按时间排序的请求记录列表，每次新请求到来时，先清除过期的旧记录，再统计当前窗口内的请求总数。窗口是"滑动"的，因为它的起止时间随每个请求动态变化。

举个具体例子：假设限制是10秒内最多5次请求。当第6个请求在第9秒到来时，系统会检查时间戳列表，把第0秒之前的记录删掉，然后发现窗口内已经有5条记录，于是拒绝第6个请求。这样无论请求集中在窗口的哪个位置，都能被精确拦截。

从数据结构角度看，滑动窗口通常用一个有序队列（或双端队列）来实现，队列中每个元素存储请求的时间戳。入队时清理过期数据，然后判断队列长度是否超限。这个操作的时间复杂度是O(n)，但因为每次只清理一次，实际性能非常好，在高并发场景下完全够用。

三、滑动窗口算法的代码实现

下面给出一个基于Python的滑动窗口限流器实现，逻辑清晰，可以直接用于生产环境的参考：

import time
from collections import deque

class SlidingWindowRateLimiter:
    def __init__(self, max_requests, window_seconds):
        """
        max_requests: 窗口内允许的最大请求数
        window_seconds: 滑动窗口的时间长度（秒）
        """
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.request_timestamps = deque()
    
    def is_allowed(self, client_ip):
        current_time = time.time()
        # 清理过期的时间戳
        while self.request_timestamps and self.request_timestamps[0] < current_time - self.window_seconds:
            self.request_timestamps.popleft()
        # 判断是否超限
        if len(self.request_timestamps) >= self.max_requests:
            return False
        # 记录本次请求
        self.request_timestamps.append(current_time)
        return True
    
    def get_remaining(self, client_ip):
        """返回当前窗口内剩余可请求次数"""
        current_time = time.time()
        while self.request_timestamps and self.request_timestamps[0] < current_time - self.window_seconds:
            self.request_timestamps.popleft()
        return self.max_requests - len(self.request_timestamps)

# 使用示例
limiter = SlidingWindowRateLimiter(max_requests=10, window_seconds=60)

for i in range(15):
    if limiter.is_allowed("192.168.1.100"):
        print(f"请求 {i+1}: 允许通过")
    else:
        print(f"请求 {i+1}: 已限流，拒绝")

上面的代码是单机版本，适合小规模应用。但在分布式环境下，每个节点各自维护计数器会导致限流失效——攻击者可以把流量分散到多台服务器上绕过限制。这时候就需要引入分布式存储来共享计数状态。

四、分布式场景下的滑动窗口实现

在分布式系统中，通常用Redis来实现全局共享的滑动窗口。核心思路是：用Redis的有序集合（Sorted Set）存储每个IP的请求时间戳，利用ZREMRANGEBYSCORE命令清理过期数据，用ZCARD命令获取当前窗口内的请求数量。

import redis
import time

class DistributedSlidingWindowLimiter:
    def __init__(self, redis_client, max_requests, window_seconds):
        self.redis = redis_client
        self.max_requests = max_requests
        self.window_seconds = window_seconds
    
    def is_allowed(self, client_ip):
        current_time = time.time()
        key = f"rate_limit:{client_ip}"
        pipe = self.redis.pipeline()
        # 清理窗口外的旧记录
        pipe.zremrangebyscore(key, 0, current_time - self.window_seconds)
        # 获取当前窗口内的请求数
        pipe.zcard(key)
        results = pipe.execute()
        current_count = results[1]
        
        if current_count >= self.max_requests:
            return False
        
        # 添加当前请求的时间戳
        self.redis.zadd(key, {current_time: current_time})
        # 设置key的过期时间，避免内存无限增长
        self.redis.expire(key, self.window_seconds + 10)
        return True

# 使用示例
r = redis.Redis(host='localhost', port=6379, db=0)
limiter = DistributedSlidingWindowLimiter(r, max_requests=20, window_seconds=60)

分布式方案的关键细节有三个：第一，必须用Pipeline批量执行Redis命令，减少网络往返；第二，要给key设置合理的过期时间，防止Redis内存暴涨；第三，在高并发下可以考虑用Lua脚本把清理和计数合并成原子操作，避免并发竞争。

五、滑动窗口的性能优化与注意事项

滑动窗口在高并发下的性能瓶颈主要在内存和清理操作。如果单个IP的请求量极大，deque或Sorted Set中的元素会很多，清理操作会变慢。优化方案有几个：

第一，分片处理。把IP按哈希分到多个计数器实例中，每个实例只处理一部分IP，降低单点压力。第二，近似滑动窗口。不精确到每一秒，而是用多个固定小窗口（比如每秒一个桶，共10个桶）来近似滑动窗口的效果，计算更快但精度略有损失。第三，异步清理。不每次请求都清理，而是用后台定时任务定期清理过期数据，减少主路径的计算开销。

另外需要注意的是，IP频率限制不能只看IP地址。攻击者可能使用代理池轮换IP，这时候单靠IP限流效果有限。更完善的方案应该结合设备指纹、行为分析、会话Token等多维度信息来综合判断。同时，对正常用户的误杀也要控制，比如同一个NAT网关下可能有几十个用户共享一个公网IP，阈值设置要合理，或者对超限用户降级为验证码而不是直接拒绝。

六、滑动窗口在实际CC防护中的部署策略

在实际生产环境中，滑动窗口限流通常不是孤立使用的，而是作为多层防护体系的一环。典型的部署架构是：第一层在CDN或WAF上做粗粒度的IP限流，拦截明显的攻击流量；第二层在API网关上用滑动窗口做细粒度的接口级限流；第三层在应用内部做业务逻辑层面的防护，比如登录失败次数限制、图形验证码触发等。

阈值的设定需要根据业务特点来调整。对于登录接口，通常1分钟内5-10次就算异常；对于查询接口，可以放宽到每分钟60-120次。建议上线后持续监控限流触发的比例，如果正常用户被误限的比例超过1%，就需要调高阈值或优化判断逻辑。

还有一个容易被忽视的点：滑动窗口的时间精度。如果用秒级精度，在极端高并发下可能出现同一秒内大量请求同时到达的情况，导致短暂超限。可以把时间精度提升到毫秒级，或者在超限时加入一个微小的随机延迟（jitter），打散请求峰值，保护后端服务。

七、总结与实战建议

IP频率限制配合滑动窗口算法是CC防护中性价比最高的技术手段之一。它实现相对简单、精准度高、对正常用户影响可控。核心要点归纳：单机用有序队列实现，分布式用Redis Sorted Set加Lua脚本保证原子性，阈值根据业务动态调整，多层防护协同工作。不要指望单一手段解决所有问题，把滑动窗口放在整个安全体系中去定位，才能发挥最大价值。对于中小团队，先从单机滑动窗口做起，跑通逻辑后再升级到分布式方案，是最稳妥的路径。

CC防护之IP频率限制与滑动窗口算法实现

服务指南

帮助中心