什么是速率限制：保护提问箱免受大量发帖的机制

更新：2026-05-06 · 阅读约 3 分钟

为什么需要限制发帖频率

不只是提问箱，凡是用户可以自由发送数据的网络服务，都面临大量发帖攻击的风险。如果恶意用户或机器人程序（Bot）在短时间内发来几百、几千条帖子，可能会产生 2 个问题。

第一，提问箱箱主的管理页面会被垃圾信息塞满。正当的提问被埋没在大量垃圾信息里，找不到了。箱主不得不一条一条地删除垃圾信息，也许会连运营提问箱本身都厌烦起来。

第二，服务器会承受过大的负荷。如果 1 秒内集中涌来几百个请求，就会超出服务器的处理能力，连正当用户的访问都可能变慢，最坏的情况下服务甚至可能停止。这是 DDoS（Distributed Denial of Service，分布式拒绝服务）攻击的一种形式。

速率限制，就是用“给发帖频率设上限”这一简单的方法来抑制这些问题的机制。

速率限制的实现方法有好几种，其中直观上容易理解的是一种叫“令牌桶（Token Bucket）”的模型。

请想象一个水桶（容器）里装着令牌（硬币）。每发送 1 条提问，就消耗 1 枚令牌。令牌会以一定的速度自动补充。水桶空了，在令牌补充之前就不能发帖。

假设把来自同一 IP 地址的发帖限制为每分钟最多 5 条。水桶里最多装 5 枚令牌，每分钟最多补充到 5 枚。以人发送提问的速度（每条几十秒到几分钟），令牌几乎不会耗尽。但是，如果机器人程序想在 1 秒内发送 100 条，前 5 条就会把令牌用光，剩下的 95 条会被拒绝。

这个机制的优点在于，几乎不影响正当用户，又容易拦住恶意的大量发帖。

速率限制需要识别“发帖来自谁”。像提问箱这样不注册账号也能发帖的服务，有一种方法是用发帖者的 IP 地址作为识别标志。来自同一 IP 地址的发帖超过上限后，超出的部分会被拒绝。

基于 IP 地址的限制也有局限。第一，共用同一网络（公司的 Wi-Fi、学校的 Wi-Fi）的多个用户，会从同一个 IP 地址发帖。这种情况下，1 个人发帖达到上限后，同一网络上的其他用户也可能暂时无法发帖。不过，上限是按正常使用来设定的，会成为问题的场合应该很有限吧。

第二，如果攻击者使用 VPN 或代理频繁更换 IP 地址，就能绕过速率限制。每换一次 IP 地址就会分配一个新的水桶，限制就被重置了。

弥补这个局限的方法之一，是不单独使用速率限制，而是把它和工作量证明（Proof of Work）或蜜罐字段组合起来。即使更换 IP 地址绕过了速率限制，每次发帖也要付出工作量证明的计算成本，蜜罐对机器人程序的检测也会发挥作用。作为多层防御中的一层，速率限制发挥着重要的作用。

正当用户被速率限制拦住的情况很少见，但并不是零。在短时间内连续给多个提问箱发提问，或者连续猛按发送按钮时，就可能发生。

被速率限制拦住后，服务器会返回 HTTP 429（Too Many Requests）这个状态码。画面上会显示“发帖太多了，请稍候”的消息。

应对方法很简单。请等 1 分钟左右再重新发送。过一段时间限制就会解除，所以只要等待就能恢复到可以发帖的状态。输入的提问内容不会消失，所以不需要重新输入。

发帖频率的上限，基本上要设在以人正常发送提问的速度很难达到的水平。发送 1 条提问，从想内容、输入到发送，至少需要几十秒，所以正常使用时很少会碰到上限。

设计速率限制的难点之一，是阈值（上限值）的设定。阈值定得太严，会损害正当用户的便利性；定得太松，又难以防住攻击。

阈值要以人的行动速度为基准来考虑。人发送 1 条提问所需的时间，即使是固定格式的简短提问也要几十秒。只要把上限放在“即使是人的最快速度也刚好达不到的水平”，应该就不会损害正当用户的便利性。另一方面，机器人程序会尝试在 1 秒内发送几十条到几百条帖子，所以仅靠这个水平的限制，发帖速度也会大大降低。

速率限制和工作量证明是互补的关系。工作量证明通过施加“每条的计算成本”来抑制大量发帖，速率限制则直接限制“单位时间内的发帖数”。即使用高性能的 GPU 快速解出了工作量证明，只要有速率限制，发帖频率就会被封顶在上限。反过来，即使更换 IP 地址绕过了速率限制，每次发帖仍然需要进行工作量证明的计算。

在这种双重约束下，攻击者必须同时承担“计算成本”和“时间成本”，垃圾信息的性价比就会变差。我们认为，比起完全防住攻击，提高攻击的成本让它划不来，才是现实的防御策略。速率限制，是这一策略的重要组成部分。