一句话版本
很多攻击并不利用漏洞，而是利用"量"：用泄露的密码批量尝试登录（撞库）、反复请求短信验证码让你付巨额短信费、批量注册账号薅羊毛、高频调用昂贵的 AI 接口。每一次请求都是"合法"的，合起来就是灾难。 防御靠限流（限制单位时间内的请求次数）和抗滥用（识别并区别对待可疑流量）。关键是选对限流的维度：按 IP、按账号、按手机号、按设备，以及在哪一层限。
全文分三层：
- 通俗理解：限购和排队
- 实际用处：撞库、短信轰炸与短信费用攻击、AI 接口被盗刷
- 原理与工程要点：令牌桶算法、限流维度、渐进式摩擦
第一层：通俗理解
1.1 限购和排队
超市搞特价时会"每人限购两件"，银行柜台会"取号排队"。这些规则对正常顾客影响不大，却能防止有人一次性扫光货架、或者让柜台瘫痪。
网络服务也一样：一个正常用户一分钟最多登录失败几次、最多请求一两次验证码；一个脚本一分钟可以尝试上万次。
1.2 "合法"请求的滥用
| 攻击 | 每次请求看起来 | 合起来的后果 |
|---|---|---|
| 撞库 | 一次普通的登录尝试 | 用其他网站泄露的账号密码批量试，试中就接管账号 |
| 短信轰炸 | 一次正常的"发送验证码" | 受害者手机被验证码淹没 |
| 短信费用攻击（SMS pumping） | 同上 | 攻击者让你向他控制的高价号码段发大量短信，和运营商分成，你付账单 |
| 薅羊毛 | 一次正常的注册 | 批量注册新账号领取优惠 |
| 接口盗刷 | 一次正常的 API 调用 | 偷到的 API 密钥被用来跑大量昂贵的 AI 请求 |
第二层：实际用处
- 23andMe（2023）：攻击者用其他网站泄露的密码进行撞库，登录了约 1.4 万个账号；再通过平台的"亲属匹配"功能，间接获取了约 690 万用户的个人信息。这说明撞库的影响会被产品功能放大。
- 短信费用攻击：多家互联网公司公开表示曾因验证码接口被滥用而损失大笔短信费。攻击者往往专挑单价高的国际号码段。
- AI 接口被盗刷：开发者把 API 密钥泄露在前端代码或公开仓库里（见《秘密扫描》），几小时内就被用来跑大量请求，产生高额账单。很多云平台因此提供了用量上限和预算告警。
- 登录页的标配：失败若干次后要求人机验证、延迟响应、或临时锁定，几乎是所有大型网站的默认配置。
第三层：原理与工程要点
3.1 令牌桶算法
最常用的限流算法：
- 每个"桶"（比如每个 IP、每个账号）最多装 个令牌；
- 每秒自动补充 个令牌，满了就不再加；
- 每个请求消耗一个令牌，没有令牌就拒绝（或排队）。
登录接口：，（每分钟补 1 个）
- 正常用户偶尔输错一两次密码：桶里有余量，毫无感觉；
- 攻击脚本连续尝试：5 次之后，每分钟只能再试 1 次，一天最多约 1440 次。
对于需要尝试成千上万个密码的撞库来说，速度被压低了几个数量级。
它的好处是允许短时间的突发（桶容量 ），同时限制长期平均速率（）。
3.2 限流的维度
| 维度 | 能防什么 | 弱点 |
|---|---|---|
| 按 IP | 单一来源的高频请求 | 攻击者用大量代理 IP；大量正常用户可能共享一个 IP（公司、学校、移动网络） |
| 按账号 | 针对某个账号的暴力破解 | 撞库是"每个账号只试一次"，按账号限不住 |
| 按手机号 / 邮箱 | 短信轰炸 | 攻击者换号码 |
| 按号码段 / 国家 | 短信费用攻击 | 需要业务判断 |
| 按设备指纹 | 换 IP 不换设备的攻击 | 指纹可以伪造；隐私问题 |
| 全局 | 整体异常（比如登录失败率突然上升 10 倍） | 需要告警而不是直接拒绝 |
实践中要多个维度叠加，并且把全局指标作为告警信号（见《安全监控与告警疲劳》）。
3.3 渐进式摩擦
不要一上来就封禁，而是逐级加码（和风控评分与摩擦设计的思路相同）：
- 正常放行；
- 增加延迟；
- 要求人机验证；
- 要求额外验证（邮件确认、passkey）；
- 临时锁定；
- 封禁并人工审查。
3.4 针对具体场景
| 场景 | 措施 |
|---|---|
| 撞库 | 检查密码是否出现在已知泄露库中；推广 passkey（见《Passkey与防钓鱼》）；登录成功但设备、地点异常时要求额外验证 |
| 短信费用 | 只向业务覆盖的国家发短信；同一号码段、同一 IP 的请求设上限；改用邮件、App 推送、passkey |
| 接口盗刷 | 密钥不放前端；设置用量上限和预算告警；按密钥限流（见《最小权限与密钥管理》） |
| 注册滥用 | 邮箱、手机号验证；新账号功能逐步开放 |
3.5 在哪一层限
| 层 | 说明 |
|---|---|
| CDN / 边缘 | 最早拦截，保护后端；但看不到业务语义（比如"这次登录失败了") |
| API 网关 | 统一按密钥、按路径限流 |
| 应用 | 能结合业务逻辑（失败次数、账号状态），最精确 |
通常三层都要有，越往后越精细。
总结
| 层次 | 要点 |
|---|---|
| 本质 | 每次请求都合法，靠"量"造成伤害 |
| 算法 | 令牌桶：允许突发，限制平均速率 |
| 维度 | IP、账号、号码、号码段、设备、全局，多维叠加 |
| 策略 | 渐进式摩擦；按场景定制；多层部署 |