3. API网关延迟的常见根因

API网关作为南北向流量的统一入口，其延迟直接决定端到端响应时间。在WAF策略观测体系中，延迟根因的精准定位是标签设计的核心输入。根据生产环境故障排查与性能压测数据，网关延迟主要归因于以下四类根因：规则匹配耗时、正则回溯、后端响应等待、连接池耗尽。

3.1 四类根因的延迟特征对比

3.2 根因一：规则匹配耗时

WAF引擎在接收到HTTP请求后，需要遍历所有启用的安全规则。每条规则包含多个匹配条件（URI、Header、Body、参数等）。规则匹配耗时主要受以下因素影响：

• 规则数量：每增加100条规则，平均匹配耗时增加约0.8ms – 1.5ms。
• 规则复杂度：包含多个逻辑运算符（AND/OR/NOT）的复合规则比简单规则耗时高3–5倍。
• 请求体大小：对POST/PUT请求进行Body解析时，大Payload（>1MB）会显著增加匹配时间。

3.3 根因二：正则回溯

正则回溯（Catastrophic Backtracking）是WAF延迟中最危险的偶发根因。当正则表达式存在嵌套量词（如 (a+)+b）且输入字符串接近匹配但不完全匹配时，引擎会尝试所有可能的组合路径，导致时间复杂度从O(n)退化为O(2^n)。

// 危险的正则模式示例
// 输入: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaac"
// 匹配耗时: 从 0.1ms 飙升到 3000ms+
Pattern dangerous = Pattern.compile("^(a+)+b$");

// 优化后的安全模式
Pattern safe = Pattern.compile("^a+b$");

正则回溯的典型特征：

• 偶发性：正常请求延迟正常，特定Payload触发后延迟飙升。
• CPU尖刺：单次回溯可消耗单核CPU 100%持续数秒。
• 无后端依赖：即使后端服务正常，网关自身延迟也会急剧上升。

3.4 根因三：后端响应等待

当WAF将请求转发至上游服务后，网关需要等待后端响应。这部分延迟并非WAF自身计算导致，但会直接计入API总延迟。后端响应等待的常见场景：

• 上游服务过载：后端线程池或数据库连接池耗尽，请求排队。
• 网络抖动：网关与后端之间的网络延迟增加。
• 慢SQL或外部API调用：后端自身依赖的下游服务响应慢。

在WAF观测标签体系中，需要将 upstream.response_wait 与 waf.rule.match_time 分开标记，避免将后端延迟错误归因于WAF策略。

3.5 根因四：连接池耗尽

网关与后端服务之间通常维护一个连接池（Connection Pool）以复用TCP连接。当并发请求数超过连接池最大连接数时，新请求必须等待空闲连接，导致排队延迟。

3.6 四类根因的延迟传播关系图

下图展示了API网关延迟从客户端请求到后端响应的完整链路，以及四类根因在链路中的位置与传播关系：

3.7 四类根因的观测标签设计原则

基于上述四类根因，WAF策略观测标签体系应遵循以下设计原则：

1. 延迟来源分离：必须区分“网关计算延迟”与“后端依赖延迟”，避免将后端慢响应归因于WAF策略。
2. 偶发尖刺捕获：正则回溯等偶发根因需要P99/P999延迟标签，不能仅依赖平均延迟。
3. 连接池水位标记：连接池耗尽前应有预警标签（如high_watermark），而非仅标记已耗尽状态。
4. 规则级可观测性：规则匹配耗时标签应细化到规则组或单条规则级别，支持快速定位慢规则。