哪些安全检查会影响 API 延迟？
直接答案
安全检查可能影响 API 延迟，因为它们在请求路径中引入了额外的工作（例如完整性验证、身份验证、授权和安全故障转移）。如果您希望在不假设任何实时市场数据的情况下分析延迟，请将安全设计中稳定的部分与环境中变化的部分（网络距离、提供商行为和重试模式）区分开来。
对于一个 API 请求，您观察到的延迟通常包括：到达端点所需的时间、用于加密或完整性检查的时间、权限决策所花费的时间、在队列中等待的时间，以及因检查失败而导致的重试或超时所引起的任何延迟。
机制与定义
API 延迟是指发送 API 请求到接收到相应响应（或失败）之间所经过的时间。“安全检查”是确认以下内容的步骤：(1) 客户端是其所声称的身份，(2) 请求被允许，(3) 所涉及的软件和数据是真实且完整的。
可能影响延迟的常见安全检查包括：
-
可信下载与完整性 如果客户端获取二进制文件、配置包或证书，客户端可能在使用前验证签名或哈希值。该验证通常是稳定且本地的操作，但在冷启动、部署或重启期间可能增加数秒时间——然后间接增加感知请求延迟，如果系统必须重新初始化。
-
凭据与身份验证 当请求包含凭据（例如令牌或签名请求）时，服务器必须验证它们。验证可能涉及加密检查和密钥查找。该处理时间是请求-响应路径的一部分。
-
权限与授权 即使身份验证成功，授权仍需确保调用方可以执行所请求的操作。权限检查可能涉及策略评估。如果策略复杂或依赖额外查找，授权可能会增加可测量的时间。
-
更新与安全密钥/证书轮换 密钥轮换和配置更新是安全要求，但也可能造成临时不匹配窗口。在轮换期间，客户端可能提供服务器不再识别的凭据（反之亦然）。结果通常是由于重试、退避或故障转移而导致行为变慢。
-
备份与恢复路径 弹性功能（例如备用端点、缓存策略或恢复程序）可以减少中断影响。然而，故障转移本身可能改变延迟：请求可能在超时后被重新路由，从而增加端到端时间。
证据或示例（含明确假设）
考虑一个发送请求并等待最多超时时间的系统。假设以下稳定的安全设计选择：
- 身份验证验证在服务器端增加 Ta 毫秒的工作量。
- 授权策略评估增加 Tp 毫秒。
- 检查失败会触发最多 N 次重试，每次重试后有固定退避时间 B。
如果所有检查首次尝试即成功，简化的延迟模型为： L ≈ NetworkRoundTrip + Ta + Tp + queue_wait
如果身份验证失败且系统重试，延迟变为： L_retry ≈ NetworkRoundTrip + (Ta_fail + Tp_fail) + (N−1)·(B + NetworkRoundTrip)
一个关键材料限制：Ta 和 Tp 组件并非保证为常量。它们可能随密钥大小、策略复杂性、缓存命中率和提供商负载而变化。此外，观察到的 L 取决于您的超时和重试配置，这可能将快速失败转化为缓慢结果。
第二个示例涉及可信下载的完整性检查。如果服务重启且必须在提供请求服务前验证已下载的包，则在此期间的请求延迟会增加——不是因为每个请求变慢，而是因为服务尚未就绪。
局限性与风险（包括故障模式）
将安全检查与延迟关联的关键故障模式包括：
- 慢失败放大：小的安全故障（错误令牌、过期密钥、权限范围错误）可能触发重试，使延迟显著恶化。
- 缓存与策略可变性：授权决策可能依赖于缓存或策略源，这些源在负载下可能改变行为。
- 轮换不匹配窗口：凭据或证书的更新可能暂时破坏兼容性，增加错误率和延迟。
- 完整性验证延迟：可信下载检查可能在部署或重启后延迟可用性。
不确定性和验证限制：
- 此处未假设实时市场数据，因此这是关于延迟机制的概念性指导。
- 结果因网络条件、提供商实现细节、成本、执行环境和司法管辖区而异。
- 安全设置与延迟之间的历史关系不能确定未来性能。