3. Envoy 延迟来源分析：网络延迟、队列延迟、处理延迟、上游服务延迟

Envoy 作为数据面代理，其端到端延迟由多个独立阶段叠加而成。理解每一类延迟的来源与特征，是精准诊断与优化延迟的前提。本章将延迟拆解为四个核心类别：网络延迟、队列延迟、处理延迟与上游服务延迟，并逐一分析其成因与观测方法。

3.1 延迟分类总览

下表对比了四类延迟的典型来源、影响范围与诊断切入点：

3.2 网络延迟

网络延迟是请求在物理链路或逻辑连接上传输所消耗的时间。Envoy 场景下，网络延迟主要出现在两个阶段：客户端到 Envoy 与 Envoy 到上游。

• TCP 握手延迟：新建连接时的三次握手耗时，尤其在短连接场景下影响显著。
• TLS 协商延迟：证书验证、密钥交换带来的额外 RTT，通常增加 1~3 个 RTT。
• 带宽与拥塞：大包传输时受限于带宽，丢包导致 TCP 拥塞控制退避。
• 地理位置：跨区域部署时物理距离带来的固有延迟。

3.3 队列延迟

队列延迟指请求在 Envoy 内部等待资源（如连接、流控许可）所花费的时间。这是 Envoy 作为代理引入的额外延迟，通常与连接池配置和负载突发相关。

• 连接池等待：当上游连接池耗尽时，新请求进入等待队列，直到连接释放或超时。
• HTTP/2 流控：上游接收窗口不足时，Envoy 暂停发送数据帧，造成排队。
• 请求缓冲区：当 Envoy 处理速度低于请求到达速度时，请求在缓冲区中堆积。

3.4 处理延迟

处理延迟是 Envoy 自身处理请求所消耗的 CPU 时间，包括 Filter 链执行、路由匹配、日志记录等。这部分延迟通常较小（微秒到毫秒级），但在高并发或复杂 Filter 场景下可能成为瓶颈。

3.5 上游服务延迟

上游服务延迟是请求到达上游服务后，服务自身处理所消耗的时间。Envoy 通过 upstream_rq_time 指标可以观测到完整的上下游交互耗时，但需要排除网络与队列延迟才能得到真实的上游处理时间。

• 业务逻辑慢：数据库查询、计算密集型操作、外部 API 调用。
• 资源竞争：线程池耗尽、锁竞争、GC 暂停。
• 依赖故障：下游服务超时或熔断，导致上游等待。

3.6 延迟来源全景图

下图展示了请求从客户端到上游服务的完整路径，并标注了四类延迟的分布位置：

3.7 延迟诊断优先级

在实际诊断中，建议按以下优先级排查延迟来源：

1. 先排除上游服务延迟：通过 upstream_rq_time 与上游自身监控对比，确认是否业务慢。
2. 再检查网络延迟：使用 tcp_rtt 指标与 ping 工具验证网络质量。
3. 然后分析队列延迟：观察 upstream_rq_pending_total 与连接池使用率。
4. 最后评估处理延迟：通过 Worker CPU 与 Filter 耗时统计定位内部瓶颈。