一个有缺陷的脚本在紧密循环中调用您的 API。如果没有限制，它可能会减慢其他每个用户的服务速度，或者产生大量云费用。 API 速率限制 是防止单个客户端获取超过其公平份额的护栏。

为了展示常见算法的行为方式，我们编写了小型 Python 版本并为其提供模拟请求计时。下面的输出来自该运行。它们是教学模型，而不是生产代码，真正的网关具有更多功能。

什么是速率限制？

速率限制对每个客户端的请求进行计数，并拒绝或延迟超过商定限制（例如每分钟 100 个请求）的请求。一个相关的想法，节流，通常意味着减慢请求而不是拒绝请求。 配额通常是较长时期内的较大限额，例如定价计划每月 10,000 次通话。

为什么 API 需要它

• 稳定性：流量峰值不会压垮数据库或下游服务。
• 公平性： 一个重度客户不能让其他客户挨饿。
• 安全性：限制减慢暴力登录尝试和抓取的速度。
• 成本控制：昂贵的操作，例如AI模型调用，保持在预算范围内。

在不限制资源消耗的情况下，速率限制是 OWASP API Security Top 10 中的核心控制。我们的 使用 Postman 进行 API 测试 指南展示了如何发送检查所需的重复请求。

令牌桶

想象一个最多可容纳 5 个令牌的桶。每个请求都需要一个令牌。令牌以每秒 1 个的速度重新填充，并且桶中的令牌永远不会超过 5 个。如果桶为空，则请求将被拒绝。

class TokenBucket:
    def __init__(self, capacity, refill_per_sec):
        self.capacity = capacity
        self.rate = refill_per_sec
        self.tokens = capacity
        self.last = 0.0

    def allow(self, now):
        elapsed = now - self.last
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

我们一次发送了 7 个请求，然后又发送了更多请求：

burst of 7 at t=0:  [True, True, True, True, True, False, False]
t=2.0:              [True, True, False]
t=10:               5 allowed of 10

前 5 个爆发了，然后桶就空了。两秒后，2 个令牌已重新填充，因此又通过了 2 个请求。长时间停顿后，桶又满了，但上限为 5。这种先突发后稳定的行为适合真实流量，这就是令牌桶在 API 网关中常见的原因。 漏桶 是一个近亲，它以固定速率处理请求，平滑输出而不是允许突发。

固定窗与推拉窗的比较

固定窗口计数器是最简单的方法：每分钟允许 10 个请求，并在分钟发生变化时重置计数器。它在边界处有一个已知的缺陷。我们在 59.9 秒时发送了 10 个请求，在 60.0 秒时又发送了 10 个请求，每 60 秒窗口限制为 10 个：

fixed window allowed around boundary: 20 of 20
sliding log allowed around boundary:  10 of 20

固定窗口在十分之一秒内允许所有 20 个请求，是预期速率的两倍，因为它们落入两个不同的窗口。 滑动日志会记住最近每个请求的时间并计算过去 60 秒内的请求，因此它正确地只允许 10 个请求。

权衡是内存。滑动日志存储每个请求的时间戳。 滑动窗柜台是一种流行的中间立场。它通过混合当前和先前的窗口计数来估计速率，使用很少的内存且具有良好的准确性。

算法对比

限制什么

• API 密钥或用户 ID： 经过身份验证的 API 的最公平选项。
• IP 地址： 对于公共端点很有用，但许多用户可以共享一个 IP，攻击者可以轮换它们。
• 端点：昂贵的操作，例如搜索、导出或登录，应该受到更严格的限制。
• 计划等级：免费和付费客户通常会获得不同的限制。

登录端点需要特别小心。按帐户和 IP 进行限制，因此攻击者无法简单地将猜测传播到多个 IP 或多个帐户。

429 响应

当客户端超出限制时，返回 HTTP 429 Too Many Requests，而不是 500 或 403。包含告诉客户端发生了什么以及何时重试的标头。我们的模拟为没有留下任何请求的客户生成了这套：

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30
Retry-After: 30

Retry-After 是标准的 HTTP 标头。 RateLimit-* 标头来自 IETF 草案，许多 API 使用自己的 X-RateLimit-* 变体。无论您选择什么，都记录下来。有关状态代码的更多信息，请参阅我们的 HTTP 状态代码备忘单。

作为客户处理限制

收到 429 后立即重试会使情况变得更糟。如果数千个客户端同时执行此操作，它们就会以同步的方式访问服务器。解决方法是带有抖动的指数退避：每次失败后等待更长时间，并添加随机性。

def backoff(attempt, base=0.5, cap=30, rng=random.Random(4)):
    return round(min(cap, base * 2 ** attempt) * rng.random(), 2)

[backoff(a) for a in range(6)]
# [0.12, 0.1, 0.79, 0.62, 0.53, 6.43]

这是“完全抖动”：在零和指数增长上限之间的随机等待。等待看起来不规律，这就是重点。客户端分散开来而不是一起重试。我们为随机生成器播种，以便可以重现输出。

分布式限速

由于负载均衡器后面有多个 API 服务器，每个服务器都依靠自己，从而让客户端通过在它们之间分散请求来超出限制。团队通常将计数器保存在共享存储（例如 Redis）中，并使用原子操作或简短的脚本，因此两个服务器不能同时获取最后一个令牌。 Kong、NGINX、Envoy 和云 API 网关等网关提供此配置。我们没有为本文运行分布式设置。

测试速率限制

• 发送请求直至达到限制并确认它们成功。
• 再发送一封并确认 429 的标头正确。
• 等待重置时间并确认请求再次成功。
• 检查每个密钥的限制：一个客户端的使用不得阻止另一个客户端的使用。
• 测试双突发问题的窗口之间的边界。
• 使用负载工具（如负载测试与压力测试中所述）来检查高并发下的行为。

在单元测试中，注入当前时间，就像我们的模拟在 now 中所做的那样，因此测试永远不必休眠。

设计限制了用户可以忍受的范围

选择数字和选择算法一样重要。从真实流量开始：查看最重的合法客户每分钟发出的请求数，并将限制设置在该值之上。阻止正常使用的限制会产生支持请求，而不是安全。

• 在 API 文档中发布每个端点和每个计划的限制。
• 阻塞前发出警告。 显示剩余请求的标头可以让行为良好的客户端自行减慢速度。
• 提供繁重轮询的替代方案，例如 webhook、批量端点或更大的页面。
• 监控 429 速率。 突然上升可能意味着攻击、有问题的客户端版本或现在太严格的限制。
• 故意授予例外情况，例如对合作伙伴提出限制，记录在配置中而不是硬编码中。

还要决定如何处理刚刚超过限制的请求。一些 API 会短暂地对少量额外请求进行排队，而不是拒绝它们，从而消除短暂的峰值。其他人则优先考虑支付等重要端点，而不是分析等不太重要的端点，以便在系统面临压力时重要流量保持流动。

最后的话

良好的速率限制是 API 和客户端之间的契约。服务器选择一个公平的算法，通常是令牌桶或滑动窗口，并用 429 和 Retry-After 清楚地解释其限制。客户端尊重这些信号并通过抖动退出。从每个 API 密钥的限制开始，观察实际使用情况，然后仅在需要的地方收紧。

常见问题

继续学习