速率限制

本文约需 2 分钟阅读

速率限制 (Rate Limiting) 是指对一定时间内接受的请求数量设定上限，从而保护服务免受过载和滥用的机制。它被广泛采用，以缓解 DDoS 攻击、抑制暴力破解攻击，并实现 API 的公平使用。截至 2025 年，随着 API 经济的扩张，速率限制已成为 API 安全的基本要求。

没有限制时变慢的是谁

在没有速率限制的 API 中，处理能力实际上是按先到先得来分配的。如果某一个客户端持续发送大量请求，该客户端就会占用连接数、 CPU 时间、数据库连接等共享资源，而被迫等待的却是与此无关的其他用户。作为故障浮现出来的症状是整体响应变慢，而造成这一状况的具体客户端并不会显现在表面。而且这种状态并不需要恶意：重试实现过于简单的客户端，或执行首次批量同步的批处理作业，都会带来相同的结果。因此，速率限制不只是阻断攻击的手段，也是切断一个用户的行为波及其他用户体验这一路径的机制。若明确给出上限，超出上限的客户端也会得知自己已触及限制，从而无需把该情况当作原因不明的延迟来处理。

速率限制流程

主要算法

固定窗口方式像“每分钟最多 100 个请求”那样以固定的时间窗口进行计量。实现简单，但存在请求在窗口边界处突发集中的问题。滑动窗口方式以最近的时间窗口进行计量，从而缓解突发问题。令牌桶方式是一种以恒定速度补充令牌、每个请求消耗一个令牌的模型，可以在限制平均速率的同时允许短时间的突发。

实现场景

在登录端点上，将来自同一 IP 地址的登录尝试限制为“5 分钟内最多 10 次”，以抑制凭据填充。对于 API，设置分层限制，例如对已认证用户限制为“每小时 1,000 个请求”，对未认证用户限制为“每小时 100 个请求”。超过限制时，返回 HTTP 429 (Too Many Requests) 响应以及 Retry-After 标头，告知客户端适当的等待时间。将 API 密钥管理与速率限制相结合，可以有效防止 API 的滥用。

设计要点

速率限制的阈值需要通过分析正规用户的使用模式来设定。阈值过低会损害正规用户的体验，过高则无法防御攻击。在分布式环境中，使用 Redis 等共享存储来管理计数器，从而在多台服务器之间应用一致的限制。将强随机密码与速率限制相结合，可以大幅提升登录页面的安全性。