UD5工具箱
速率限制（Rate Limiting）
速率限制是一种控制客户端在给定时间窗口内可以发送的请求数量的技术。它是API保护服务器资源、防止滥用和保证服务质量的核心机制之一。速率限制通常在API网关、负载均衡器或应用服务器层面实现，通过计数器或令牌桶等算法来跟踪和限制请求。当客户端的请求频率超过预设的阈值时，服务器会返回429 Too Many Requests状态码，并在响应头中包含速率限制相关信息（如剩余请求数、窗口重置时间等）。合理的速率限制策略既能保护服务器免受过载，又能为合法用户提供稳定的服务。速率限制的粒度可以是全局的（所有客户端共享限制），也可以是按客户端、按IP、按API密钥等维度分别限制。
固定窗口算法（Fixed Window）
固定窗口算法是最简单的速率限制实现方式。它将时间划分为固定长度的窗口（如每分钟），在每个窗口内维护一个计数器。每当收到一个请求，计数器加一。如果计数器超过阈值，则拒绝请求并返回429。当窗口结束时，计数器重置为零，开始新的窗口。固定窗口的优点是实现简单、内存占用低。但它存在明显的边界突发问题：如果客户端在第一个窗口的末尾和第二个窗口的开头各发送了最大请求数量的请求，那么在短时间内实际发送了两倍于限制的请求。这种"边界突发"可能导致服务器在短时间内承受超出预期的负载。固定窗口的典型实现包括Apache的mod_ratelimit和Nginx的limit_req_zone。
滑动窗口算法（Sliding Window）
滑动窗口算法是固定窗口的改进版本，通过滑动时间窗口来平滑请求分布。与固定窗口在固定时间点重置计数器不同，滑动窗口的计数器随时间连续滑动。在任意时刻，窗口覆盖的是"当前时间减去窗口大小"到"当前时间"之间的请求。滑动窗口有两种常见实现：滑动窗口日志（Sliding Window Log）记录每个请求的精确时间戳，在窗口滑动时删除过期的时间戳，准确但内存开销大；滑动窗口计数器（Sliding Window Counter）使用两个相邻窗口的加权平均来近似滑动窗口，内存效率高但有一定误差。滑动窗口有效避免了固定窗口的边界突发问题，是目前主流API服务（如GitHub、Stripe）的首选算法。Nginx的limit_req模块实际上实现的就是滑动窗口计数器。
令牌桶算法（Token Bucket）
令牌桶算法是一种经典的速率限制算法，由George Polya在1926年提出。算法维护一个容量固定的"桶"，以恒定速率（如每秒10个）向桶中添加令牌。每个请求需要消耗一个令牌才能被处理。如果桶中有足够的令牌，请求立即通过；如果桶为空，请求被拒绝或等待。桶满时，多余的令牌被丢弃。令牌桶的独特之处在于它允许一定程度的突发流量：如果桶中积累了大量令牌，客户端可以一次性发送多个请求。这在处理突发请求场景（如用户快速点击按钮）时特别有用。AWS API Gateway、Google Cloud Endpoints和Cloudflare等服务都使用令牌桶算法。令牌桶的参数通常包括：令牌添加速率（tokens per second）、桶容量（burst size）和令牌消耗速率（每个请求消耗的令牌数）。
漏桶算法（Leaky Bucket）
漏桶算法将请求视为"水"，将处理队列视为一个底部有小孔的桶。水（请求）以任意速率流入桶中，但以固定速率从桶底漏出（被处理）。如果桶满了（队列满了），多余的水（请求）溢出（被丢弃）。漏桶算法的特点是输出速率恒定，无论输入速率如何变化，处理速率始终保持平稳。这使得漏桶非常适合需要平滑请求突发的场景。与令牌桶相比，漏桶不允许突发处理，所有请求都以固定速率被处理。漏桶的参数包括：桶的容量（队列大小）和漏出速率（处理速率）。Nginx的limit_req模块的burst参数就借鉴了漏桶的思想：当请求速率超过限制但在burst范围内时，请求会被排队延迟处理而非直接拒绝。
429 Too Many Requests
HTTP 429状态码是RFC 6585定义的标准HTTP状态码，表示客户端在给定时间内发送了过多请求（即超出了服务器的速率限制）。当服务器返回429时，通常会在响应头中包含以下信息：Retry-After头指示客户端应该等待多少秒后重试；RateLimit-Limit头表示当前窗口的请求上限；RateLimit-Remaining头表示当前窗口剩余的请求数；RateLimit-Reset头表示当前窗口的重置时间（通常为Unix时间戳或秒数）。客户端在收到429响应后，应该停止发送请求，等待Retry-After指定的时间后再重试。如果多次收到429，应该使用指数退避策略逐渐增加等待时间。一些API服务还会在429响应体中包含详细的错误信息和重试建议。
指数退避（Exponential Backoff）
指数退避是一种处理速率限制和网络错误的重试策略。当客户端收到429或5xx响应时，不是立即重试，而是等待一个与重试次数成指数增长的时间。典型的实现是：第一次重试等待1秒，第二次等待2秒，第三次等待4秒，第四次等待8秒，以此类推。指数退避通常会加入"抖动"（Jitter）来避免多个客户端同时重试导致的"惊群效应"。抖动的实现方式有三种：Full Jitter（在[0, 指数时间]范围内随机等待）、Equal Jitter（在[指数时间/2, 指数时间]范围内随机等待）和Decorrelated Jitter（基于上一次的等待时间随机化）。AWS在其SDK中推荐使用Decorrelated Jitter。指数退避通常与最大重试次数限制（如3-5次）配合使用，超过最大次数后放弃重试并向用户报告错误。
Retry-After 响应头
Retry-After是HTTP标准响应头，用于指示客户端在重试请求之前应该等待多长时间。它有两种格式：一种是秒数（如Retry-After: 120表示等待120秒），另一种是HTTP-date格式（如Retry-After: Wed, 21 Oct 2015 07:28:00 GMT表示等到该时间点再重试）。Retry-After通常与429（Too Many Requests）和503（Service Unavailable）状态码一起使用。在429场景下，Retry-After告诉客户端窗口何时重置或何时可以再次发送请求；在503场景下，Retry-After告诉客户端服务器预计何时恢复。客户端应该尊重Retry-After的指示，在指定时间之前不要重试请求。需要注意的是，并非所有服务器都会返回Retry-After头，客户端应该有自己的默认退避策略作为后备方案。RFC 7231第7.1.3节定义了Retry-After头的规范。
RateLimit 系列响应头
速率限制相关响应头有多种命名变体，但语义相似。IETF草案draft-ietf-httpapi-ratelimit-headers定义了标准的RateLimit头族：RateLimit-Limit（当前窗口的最大请求数，如RateLimit-Limit: 100）、RateLimit-Remaining（当前窗口剩余请求数，如RateLimit-Remaining: 42）、RateLimit-Reset（当前窗口重置的秒数，如RateLimit-Reset: 30）。此外，许多API服务使用X-RateLimit-前缀的自定义头（如X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset），语义与标准头相同。一些服务还使用X-RateLimit-Reset使用Unix时间戳格式而非秒数，需要注意区分。GitHub API使用X-RateLimit-前缀加上X-RateLimit-Used和X-RateLimit-Resource。Twitter API使用x-rate-limit-limit、x-rate-limit-remaining和x-rate-limit-reset。Stripe API使用RateLimit-Limit、RateLimit-Remaining和RateLimit-Reset。本工具会自动识别所有常见的速率限制头变体并展示其含义。
CORS 与 Access-Control-Expose-Headers
跨源资源共享（CORS）是浏览器的安全机制，限制网页从不同源获取资源。默认情况下，浏览器只能读取"简单"的响应头（如Content-Type、Cache-Control等），对于速率限制相关的自定义头（如X-RateLimit-Remaining），浏览器默认不会暴露给JavaScript代码。服务器需要在响应中包含Access-Control-Expose-Headers头来显式声明哪些头可以被JavaScript读取。例如：Access-Control-Expose-Headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After。如果没有这个头，即使服务器返回了速率限制头，前端代码通过XMLHttpRequest或fetch API也无法读取这些值。这就是为什么本工具在测试跨域API时会显示CORS警告。解决方案包括：让后端服务器配置正确的CORS策略、使用后端代理转发请求、或者使用命令行工具（如cURL）绕过浏览器限制。