gRPC 性能：keepalive、连接复用与多路复用

更新时间：2026-09-18。gRPC 性能的几条主线都建立在 HTTP/2 之上：一条 TCP 连接承载大量并发 stream、连接要长生命周期复用、用 keepalive 防止被中间设备静默掐断。配错 keepalive 会被服务端判为「ping 太频繁」直接 GOAWAY，不复用 Channel 则白白付出建连与 TLS 握手成本。本文把连接模型、参数和坑讲清。流语义见四种流模式。

本文要回答的问题

HTTP/2 多路复用具体怎么省掉连接？多个 RPC 怎么共享一条 TCP？
为什么 gRPC Channel/Stub 必须单例复用，而不是每次调用 new 一个？
keepalive 三个参数（time/timeout/permitWithoutCalls）怎么配，为什么会被 GOAWAY？
MaxConcurrentStreams、flow control、流复用过多会有什么副作用（队头阻塞）？
gRPC 怎么做负载均衡？为什么是客户端侧/代理侧 LB，不能简单用四层轮询？

一、连接模型：一条 TCP，多条 stream

HTTP/1.1 在一条连接上同一时刻基本只能处理一个请求（即使 keep-alive 也是串行），所以客户端要开多条 TCP 并发。HTTP/2 在一条 TCP 连接上分出多条互不阻塞的 stream，每个 gRPC 调用（含每个流式调用）是一条 stream，帧带 stream id 交错传输：

带来的收益：省去反复 TCP 三次握手与 TLS 握手（HTTP/2 通常基于 TLS）、连接数大减、服务端线程/内存压力小。注意 stream id 单双号区分客户端/服务端发起，且一条连接上 stream id 用得非常多也无压力。

二、Channel 复用：最重要的一条实践

java

// ✅ 整个应用共享一个 ManagedChannel（内部维护连接与多条 stream）
ManagedChannel ch = ManagedChannelBuilder.forTarget("dns:///svc:8080")
        .useTransportSecurity().build();
DemoStub stub = DemoGrpc.newStub(ch);   // stub 轻量，可随用随建

// ❌ 每次调用都 newChannel()：每次建连+握手，吞吐崩塌、TIME_WAIT 堆积

gRPC 的 Channel 是「逻辑通道」，内部管理物理连接、重连、负载均衡、HTTP/2 设置；BlockingStub/Stub 只是绑定调用选项的轻量包装，可以反复创建，Channel 必须单例/长生命周期，应用关闭时再 shutdown。这与数据库 HikariCP 连接池「复用昂贵连接」的思想一致。

三、keepalive：保活但别激怒服务端

NAT、L4 负载均衡、防火墙会静默回收一段时间没流量的连接；等客户端下次发请求时才发现连接已死，首笔调用报错。keepalive 周期性发 HTTP/2 PING 探测并保持连接「活跃」：

bash

客户端常用：
  keepAliveTime: 60s          空闲多久后开始发 PING
  keepAliveTimeout: 20s       PING 等 ACK 多久超时则判定断连并重连
  keepAliveWithoutCalls(false) 没有在途调用时是否也 ping
服务端：
  permitKeepAliveTime: 30s    允许的最小 ping 间隔
  permitKeepAliveWithoutCalls: true/false
  maxConnectionIdle/age ...

关键坑：若客户端在没有在途调用时频繁 ping，或 ping 间隔小于服务端 permitKeepAliveTime（常见阈值 5 分钟），服务端会回 GOAWAY，错误码 ENHANCE_YOUR_CALM 并附带 "too_many_pings"，直接关连接。正确姿势：客户端 keepAliveTime 不小于服务端允许值（如 60s 且与服务端协商一致），permitWithoutCalls/keepAliveWithoutCalls 只在确需维持空闲连接时开，且与服务端策略对齐。

四、并发上限、flow control 与队头阻塞

MaxConcurrentStreams（服务端 SETTINGS 帧下发）限制单条连接上的并发 stream 数，默认可能 100。超过的调用排队或触发新建连接——这是高并发下吞吐上不去的隐蔽点，要结合连接数一起调。
HTTP/2 flow control 是逐跳的接收窗口，慢消费者会反压发送方；流式大消息若不及时读取，窗口耗尽会卡住其他 stream 的数据帧。
TCP 层队头阻塞仍在：HTTP/2 解决了 HTTP 层队头阻塞，但所有 stream 共用一条 TCP，一旦发生丢包，TCP 重传会阻塞该连接上所有 stream（HTTP/3/QUIC 才在传输层解决）。因此跨地域、高丢包链路要评估多连接/QUIC。
消息大小：默认 gRPC 对单条消息有 4MB 左右上限，超大消息要调 maxInboundMessageSize，但更推荐拆成流式而非无限调大。

五、负载均衡与连接池

普通 L4 轮询对长连接几乎失效：gRPC 一条连接复用承载海量调用，连接一旦建立就固定到某个后端实例，流量无法再分摊。两种主流方案：

bash

1) 客户端侧 LB（gRPC 原生）
   客户端通过 name resolver（dns/k8s/xds）拿到一组 IP，
   在多条到不同实例的子连接(subchannel)上按 round_robin/ pick_first 分发
2) 代理侧 LB
   用 Envoy/L7 网关按 stream/请求分发（HTTP/2 感知），客户端只连代理

客户端侧 LB 省一跳、感知实例权重；Service Mesh / xDS 适合大规模统一治理。pick_first 是默认（只连一个），要 round_robin 需显式配置负载均衡策略。

六、坑与对照

每次调用新建 Channel。 建连/TLS 成本主导，性能崩；Channel 单例化。
ping 太勤被 ENHANCE_YOUR_CALM。 与服务端 permitKeepAliveTime 对齐，别在空闲时乱 ping。
单连接并发受 MaxConcurrentStreams 卡住。 高并发要多 subchannel，注意 round_robin 配置。
慢消费者拖垮整条连接。 流式及时 Recv、关注 flow control 窗口。
用四层 LB 期待轮询。 长连接下要靠客户端侧或 L7 负载均衡。
无限调大消息上限。 优先流式分片，并评估序列化/内存。

调用语义与背压见 gRPC 四种流模式；鉴权埋点见 gRPC 拦截器；和 REST 的取舍见 gRPC 与 Protobuf。

总结

gRPC 性能：靠 HTTP/2 在一条 TCP 连接上多路复用大量 stream，省建连与 TLS 握手，因此 ManagedChannel 必须单例复用、stub 可随建；用 keepalive（keepAliveTime/Timeout/WithoutCalls）周期发 PING 防 NAT 静默断连，但 ping 间隔要 ≥ 服务端 permitKeepAliveTime、别在空闲乱 ping，否则收到 GOAWAY ENHANCE_YOUR_CALM/too_many_pings；高并发受单连接 MaxConcurrentStreams 与 HTTP/2 flow control 限制、且共享 TCP 仍有丢包队头阻塞；长连接让 L4 轮询失效，要用客户端侧 round_robin（多 subchannel）或 Envoy/L7 代理负载均衡，超大消息优先流式而非调大上限。

gRPC 性能：keepalive、连接复用与多路复用 ​

本文要回答的问题 ​

一、连接模型：一条 TCP，多条 stream ​

二、Channel 复用：最重要的一条实践 ​

三、keepalive：保活但别激怒服务端 ​

四、并发上限、flow control 与队头阻塞 ​

五、负载均衡与连接池 ​

六、坑与对照 ​

总结 ​