3. HTTP/1.1 连接池参数详解：max_requests_per_connection、max_connections、connect_timeout

在 Service Mesh 升级过程中，Envoy 的 HTTP/1.1 连接池是影响服务间延迟与吞吐量的核心组件。与 HTTP/2 的多路复用不同，HTTP/1.1 采用“请求-响应”串行模型，每个连接同一时刻只能处理一个请求。因此，连接池参数直接决定了上游集群的连接复用效率、资源消耗以及故障恢复速度。

本章聚焦三个最关键的连接池参数：max_requests_per_connection、max_connections 和 connect_timeout。理解它们的协同机制，是调优 Envoy 连接池的必修课。

3.1 参数全景与作用域

Envoy 的 HTTP/1.1 连接池参数定义在 envoy.config.cluster.v3.Cluster 的 circuit_breakers 和 upstream_connection_pool 配置中。下表列出了三个参数的核心属性：

3.2 max_requests_per_connection：连接寿命控制

该参数定义了单个 HTTP/1.1 连接在关闭前最多可以处理多少个请求。Envoy 在连接上每完成一个请求-响应周期，内部计数器递增；当计数达到设定值时，连接会在当前请求处理完毕后进入“排空”状态，不再接受新请求，待所有流式响应结束后关闭。

3.2.1 典型场景与配置

• 负载均衡场景： 设置较小的值（如 100~500）可以强制 Envoy 定期断开并重建连接，使流量更均匀地分布到后端 Pod，避免“热连接”现象。
• 长连接保活场景： 设置较大的值（如 1000+）或保持默认无限制，可以减少连接重建开销，适合后端连接建立成本高的场景（如 TLS 握手、数据库连接池）。
• 灰度发布与版本升级： 在 Istio 中，配合 drain 策略，设置 max_requests_per_connection 可以加速旧版本 Pod 的连接排空，缩短升级窗口。

# Envoy 配置示例：限制每个连接最多处理 500 个请求
clusters:
- name: "service_backend"
  connect_timeout: 3s
  max_requests_per_connection: 500
  circuit_breakers:
    thresholds:
    - priority: DEFAULT
      max_connections: 200

3.3 max_connections：并发连接上限

该参数是断路器（Circuit Breaker）的一部分，控制 Envoy 到某个上游集群的最大并发连接数。当活跃连接数达到此阈值时，Envoy 会立即返回 503 或进入 pending 队列（取决于 max_pending_requests 配置），防止上游被突发流量压垮。

3.3.1 与 HTTP/1.1 串行模型的耦合

由于 HTTP/1.1 每个连接只能串行处理请求，max_connections 直接决定了该集群的最大并发请求数。例如，设置 max_connections: 100，则最多同时有 100 个请求在传输中，其余请求必须排队等待空闲连接。

3.4 connect_timeout：连接建立的生命线

该参数定义了 Envoy 等待 TCP 连接建立完成的最长时间。超时后，Envoy 会认为该连接失败，并尝试下一个可用端点（如果配置了重试）。

3.4.1 超时对连接池的影响

• 过短的 connect_timeout（< 1s）： 在网络抖动或后端负载高时，容易导致大量连接建立失败，触发断路器快速熔断，造成服务雪崩。
• 过长的 connect_timeout（> 10s）： 当后端实例宕机时，请求会长时间阻塞在连接建立阶段，耗尽连接池中的 pending 队列，导致后续请求被拒绝。
• 与重试的交互： 如果配置了重试，每次重试都会重新发起连接建立，connect_timeout 会累加。例如重试 3 次、超时 5s，最坏情况下请求等待 15s 才返回失败。

# 推荐配置：结合网络延迟和 SLO 设置
connect_timeout: 3s   # 内网服务推荐 1~3s，跨可用区可放宽到 5s

3.5 参数协同与调优流程

下图展示了三个参数在连接生命周期中的协同关系：

3.6 调优实战建议

1. Step 1：测量基线 — 使用 Envoy 的 /stats 端点观察 upstream_cx_total、upstream_cx_active、upstream_rq_total 等指标，了解当前连接池使用情况。
2. Step 2：设置 connect_timeout — 内网服务建议 2~3s，跨可用区或公网服务建议 5~8s。避免小于 1s 导致误熔断。
3. Step 3：调整 max_connections — 根据后端 Pod 数量 × 每个 Pod 的并发处理能力（通常 50~200）计算初始值，压测后逐步调整。
4. Step 4：配置 max_requests_per_connection — 如果后端使用长连接且负载均衡器依赖连接数分布，设置 200~500；如果后端连接建立成本低，可以保持默认无限制。

# 生产环境推荐初始配置（以 Istio DestinationRule 为例）
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend-dr
spec:
  host: backend-svc
  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 3s
      http:
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
        maxRequestsPerConnection: 500
    circuitBreaker:
      simpleCb:
        maxConnections: 200
        maxPendingRequests: 100
        maxRequests: 500
        maxRetries: 3