2、Envoy连接池基础：连接池工作原理、HTTP/1.1与HTTP/2连接池差异、连接池生命周期
2.1 连接池工作原理
Envoy 作为 Sidecar 代理，其核心职责之一是在上游集群（Upstream Cluster）与下游客户端之间高效地复用 TCP 连接。连接池（Connection Pool）正是实现这一复用的关键组件。它位于 Envoy 的 HTTP 连接管理器（HCM） 与 上游连接 之间，负责管理到每个上游主机的连接集合。
当 Envoy 收到一个 HTTP 请求时，它不会为每个请求都新建一个 TCP 连接，而是从连接池中获取一个已经建立好的连接。如果池中有空闲连接，则直接复用；如果没有，则根据配置创建新的连接。这种机制极大地减少了 TCP 握手的开销，降低了延迟，并提高了吞吐量。
核心目标： 通过连接复用，减少资源消耗，提升请求处理效率。
下图展示了 Envoy 连接池在请求处理流程中的核心位置与基本工作流：
2.2 HTTP/1.1 与 HTTP/2 连接池差异
Envoy 的连接池行为会根据上游集群配置的协议类型（HTTP/1.1 或 HTTP/2）而有显著差异。理解这些差异对于排查连接池相关故障至关重要。
| 对比维度 | HTTP/1.1 连接池 | HTTP/2 连接池 |
|---|---|---|
| 连接复用模型 | 一个连接同一时刻只能处理一个请求（串行）。请求完成后，连接返回池中供下一个请求使用。 | 一个连接可以同时处理多个请求（多路复用）。请求和响应在同一个连接上交错传输。 |
| 最大连接数 | 通常需要配置较大的连接池大小（如 100+）以支撑高并发，因为每个请求独占一个连接。 | 只需少量连接（如 1-10）即可支撑高并发，因为每个连接可承载数百个并发流。 |
| 连接创建策略 | 当所有连接都繁忙时，新请求会触发创建新连接，直到达到最大连接数限制。 | 通常预先创建少量连接，并在连接负载过高时按需创建新连接。 |
| 空闲连接管理 | 空闲连接会保持存活一段时间（Keep-Alive），超时后关闭。 | 空闲连接同样会保持存活，但通常存活时间更长，因为复用效率更高。 |
| 等待队列 | 当所有连接繁忙且达到最大连接数时，请求进入等待队列。 | 当所有连接的并发流达到上限（MAX_CONCURRENT_STREAMS）时，请求进入等待队列。 |
关键洞察： HTTP/2 的多路复用特性使得连接池的“连接数”不再是主要的性能瓶颈，取而代之的是“流数”和“窗口大小”。在 Service Mesh 升级场景中，如果上游服务从 HTTP/1.1 切换到 HTTP/2，连接池配置必须相应调整，否则可能导致连接数过少或流数受限。
下图直观对比了两种协议在连接池中的复用模式：
2.3 连接池生命周期
连接池中的每个连接都遵循一个明确的生命周期，从创建到销毁。Envoy 通过一系列配置参数来控制这个生命周期，这些参数直接影响连接池的行为和故障表现。
2.3.1 生命周期阶段
- 创建（Creation）： 当请求到达且没有空闲连接时，Envoy 发起新的 TCP 连接。此阶段可能因 DNS 解析失败、上游服务不可用或 TLS 握手失败而报错。
- 复用（Reuse）： 请求处理完成后，连接返回池中，标记为“空闲”。后续请求可以复用该连接。对于 HTTP/1.1，这是通过 Keep-Alive 实现的；对于 HTTP/2，连接始终处于复用状态。
- 空闲超时（Idle Timeout）： 如果连接在
idle_timeout时间内没有被使用，Envoy 会主动关闭该连接以释放资源。 - 最大生命周期（Max Lifetime）： 即使连接一直在被使用，达到
max_connection_lifetime后，Envoy 也会在请求处理完毕后关闭它，以防止长时间运行的连接导致负载均衡不均或内存泄漏。 - 销毁（Destruction）： 连接因超时、错误、重置或上游关闭而被销毁。连接池会从池中移除该连接。
2.3.2 关键配置参数
| 配置参数 | 类型 | 默认值 | 说明 |
|---|---|---|---|
max_requests_per_connection |
整数 | 无限制 (0) | 一个连接最多能处理的请求数。达到后连接会被关闭并重建。常用于防止 HTTP/1.1 连接泄漏。 |
max_connections |
整数 | 1024 | 连接池中允许的最大连接数。超过此数后，新请求将进入等待队列。 |
max_pending_requests |
整数 | 1024 | 等待队列的最大长度。超过此数后，新请求将被直接拒绝（503）。 |
idle_timeout |
Duration | 1小时 | 连接空闲多久后会被关闭。 |
max_connection_lifetime |
Duration | 无限制 (0) | 连接的最大存活时间，无论是否空闲。 |
升级故障高发点： 在 Service Mesh 升级过程中，如果上游服务协议从 HTTP/1.1 切换为 HTTP/2，而连接池配置未同步更新，极易出现以下问题：
- 连接数不足： HTTP/2 场景下，
max_connections配置过大（如 100）通常不是问题，但配置过小（如 1）且未配置足够的并发流数，可能导致请求排队。 - 等待队列溢出： 如果
max_pending_requests设置过小，突发的流量尖峰可能导致大量请求被直接拒绝（503）。 - 连接过早关闭：
max_requests_per_connection在 HTTP/2 下应谨慎使用，因为一个连接承载大量请求是常态，设置过小会导致频繁重建连接，增加开销。
下图展示了连接池中一个典型连接的生命周期状态机：