📚 课程目录第2章限速策略基础

限速策略基础：核心概念与防御原理

大家好，我是你们的讲师。今天我们来聊聊限速策略的基础。说实话，很多做IoT安全的同行，一上来就搞什么机器学习、行为分析，结果连最基础的限速都没配好。我见过太多这样的案例了——设备被攻击，流量打满带宽，业务直接瘫痪。

限速这东西，听起来简单，但里面的门道不少。咱们今天就把令牌桶、漏桶这些核心概念掰开揉碎了讲清楚。

为什么限速能防御攻击？

先回答一个根本问题：限速为什么能防攻击？

你想想看，IoT设备有个特点——资源极其有限。一个智能灯泡，CPU可能就几十MHz，内存几MB。攻击者只要发送比正常请求多10倍的流量，设备就扛不住了。

限速的本质是什么？说白了，就是给流量装个水龙头。不管外面洪水滔天，我这边只放固定量的水进来。攻击流量再多，超过阈值的一律丢弃。

核心观点：限速不是让攻击消失，而是让攻击流量无法耗尽系统资源。你发100万包/秒，我只处理1000包/秒，剩下的全扔掉。这样设备就能正常服务合法用户。

我在一个智能门锁项目里遇到过这种情况。攻击者用僵尸网络发UDP洪水，门锁的Wi-Fi模块直接过热重启。后来加了限速，CPU占用率从95%降到了30%。效果立竿见影。

限速与QoS的关系

很多人搞混限速和QoS。我简单解释一下：

限速（Rate Limiting）：控制流量速率，超过阈值就丢包或排队。目标是保护系统不被压垮。
QoS（Quality of Service）：对流量分类分级，保证重要流量优先通过。目标是提升用户体验。

它们的关系是：限速是QoS的一种实现手段。你可以把QoS想象成交通管理，限速就是其中的限速标志和红绿灯。

维度	限速	QoS
核心目标	保护系统资源	保障服务质量
处理方式	丢弃/延迟超额流量	分类、标记、调度
典型场景	防DDoS、防爬虫	VoIP优先、视频流保障
实现算法	令牌桶、漏桶	WFQ、CBQ、LLQ

实战建议：在IoT场景下，我建议先做限速，再做QoS。因为IoT设备资源太紧张了，保命比优化更重要。等限速稳定了，再考虑给关键控制指令（比如开锁、关阀）设置高优先级队列。

令牌桶算法

令牌桶是我个人最常用的限速算法。它的原理很形象：

有一个桶，里面放令牌（token）
令牌以固定速率生成，比如每秒100个
每个请求来的时候，必须拿一个令牌才能通过
桶有容量上限，令牌满了就不再生成

这样做的好处是什么？允许突发流量。如果桶里攒了50个令牌，突然来一波50个请求的突发，都能通过。这很符合实际场景——正常用户偶尔也会点得快一些。

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate          # 令牌生成速率（个/秒）
        self.capacity = capacity  # 桶容量
        self.tokens = capacity    # 当前令牌数
        self.last_time = time.time()
    
    def allow_request(self):
        now = time.time()
        # 先补充令牌
        elapsed = now - self.last_time
        self.tokens = min(self.capacity, 
                         self.tokens + elapsed * self.rate)
        self.last_time = now
        
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

注意：令牌桶的容量设置很关键。容量太小，正常突发会被误杀；容量太大，攻击者能一次性消耗大量资源。我一般建议容量设为正常峰值流量的2-3倍。

漏桶算法

漏桶的思路正好相反。它像一个底部有洞的水桶：

水（请求）从上面倒进桶里
水从底部小洞以固定速率流出
桶满了，多余的水就溢出（丢弃）

漏桶的特点是输出速率绝对平滑。不管输入多猛，输出永远是恒定的。这适合对延迟敏感的场景，比如视频流、音频流。

class LeakyBucket:
    def __init__(self, rate, capacity):
        self.rate = rate          # 流出速率（请求/秒）
        self.capacity = capacity  # 桶容量
        self.water = 0            # 当前水量
        self.last_time = time.time()
    
    def allow_request(self):
        now = time.time()
        # 先漏水
        elapsed = now - self.last_time
        self.water = max(0, self.water - elapsed * self.rate)
        self.last_time = now
        
        if self.water < self.capacity:
            self.water += 1
            return True
        return False

两种算法的对比

特性	令牌桶	漏桶
突发处理	允许突发（桶内积攒令牌）	不允许突发（输出恒定）
输出速率	可变，最高到峰值	恒定，严格平滑
适用场景	Web API、数据库连接	视频流、实时通信
实现复杂度	中等	简单
内存占用	低（仅需3个变量）	低（仅需3个变量）

我的选择经验：在IoT网关层，我90%的情况用令牌桶。因为IoT设备的流量模式本身就有突发性——设备可能几分钟上报一次，也可能同时上报。漏桶会把这些突发全部削平，导致数据延迟。但如果是音频对讲这类实时流，漏桶更合适。

限速在IoT攻击防御中的实战逻辑

好了，理论讲完了。咱们看看实际怎么用。

假设你有一个智能家居网关，管理着50个设备。正常情况，每个设备每分钟上报1次数据。攻击者控制了其中10个设备，让它们每秒发送100次请求。

不加限速：网关CPU 100%，正常设备的数据全部丢失。

加限速：每个设备每分钟最多10次请求。攻击设备被限制，正常设备不受影响。

这就是限速的威力——把攻击流量压缩到可控范围内。

限速策略的部署位置

在IoT架构里，限速可以放在多个层级。我一般建议分层部署：

设备端：在设备固件里做本地限速，防止单个设备被攻陷后疯狂发包
网关层：对每个设备做独立限速，这是最常用的位置
云平台：对API接口做全局限速，防止大规模攻击

避坑指南：我曾经在一个项目里只做了网关层限速，结果攻击者直接绕过网关，用设备直连云平台。云平台被打瘫了。后来我学乖了——限速一定要做在攻击者能触及的所有入口。IoT设备可能通过Wi-Fi、蓝牙、Zigbee、4G多种方式连接，每个入口都要配限速。

限速参数怎么调？

这是大家最头疼的问题。阈值设高了防不住，设低了误杀正常流量。我的经验是：

先采集基线数据：跑一周正常流量，统计每个设备的峰值、均值、95分位值
阈值设为均值的3-5倍：给正常波动留空间
设置两级阈值：软阈值（告警不丢包）和硬阈值（直接丢包）
动态调整：根据时间、业务负载自动调整参数

嗯，这里要注意一点——不要一次性把阈值设得太严。我见过有人上来就设1包/秒，结果设备固件升级时多发了几个包，全被丢了，升级失败。建议从宽松到严格，逐步收紧。