GRPC连接机制---长连接分析 - FutureAI-Zeng

gRPC 建立连接后是长连接。 底层基于 HTTP/2，而 HTTP/2 本身就是多路复用的长连接协议。连接一旦建立，默认会一直保持，直到某一方主动关闭或网络中断。

核心机制

1. 连接建立过程

gRPC 客户端启动时，会通过 ClientConn 与目标服务端建立 TCP 连接。如果是 TLS，还要完成 TLS 握手。之后在这个 TCP 连接之上跑 HTTP/2，握手完成后连接就进入就绪状态。

2. 多路复用（关键）

HTTP/2 允许在同一条 TCP 连接上同时跑多个 RPC 调用。每个调用是一个独立的 Stream，有自己的 Stream ID。这意味着：

• 100 个并发 RPC 请求，可能共用 1 条 TCP 连接
• 不需要为每个请求单独建连接、关连接
• 头部压缩（HPACK）让重复的 metadata 传输开销很小

这是 gRPC 和传统“短连接 RPC”最大的区别。传统方式每个请求建一次连接，开销大；gRPC 一次建连，反复复用。

3. 连接保持

gRPC 默认启用了 HTTP/2 Keepalive。客户端会定期发送 PING 帧，确认连接还活着。如果服务端没响应，客户端会认为连接失效并尝试重连。

Go 的 gRPC 里，keepalive 参数长这样：

grpc.WithKeepaliveParams(keepalive.ClientParameters{
    Time:                10 * time.Second, // 多久发一次 PING
    Timeout:             3 * time.Second,  // PING 等多久算超时
    PermitWithoutStream: true,             // 没有活跃流时也发 PING
})

服务端也有对应的 keepalive 策略，可以设置 MaxConnectionIdle、MaxConnectionAge 等强制回收连接。

什么时候连接会断

虽然是长连接，但以下几种情况会触发断开或重建：

一个常见的误解

有人以为“gRPC 是长连接，所以不用管连接管理”。实际上：

连接是长连接，但 RPC 调用不是。 每次 RPC 调用仍然是一个独立的请求-响应周期，有自己的 deadline、metadata、状态码。连接复用只是省掉了 TCP/TLS 握手开销，不代表调用之间共享状态。

负载均衡需要额外配置。 如果服务端是多实例，一条长连接只会打到其中一个实例。要真正做负载均衡，通常需要配合服务发现 + round_robin 等 LB 策略，让客户端维护到多个后端的连接池。

连接数不是越多越好。 有些场景下，成千上万的客户端各自维持一条长连接，服务端 fd 和内存压力会很大。这时候服务端会用 MaxConnectionAge 强制连接定期重建，配合负载均衡把流量打散。

总结

gRPC 连接是长连接 + 多路复用：建连一次，多个 RPC 并发复用同一条 TCP 连接，靠 HTTP/2 的 Stream 机制隔离。连接默认保持，靠 keepalive 探活，靠服务端的 idle/age 策略回收。你不需要为每个请求手动建连关连，但需要理解连接生命周期，才能正确处理重连、负载均衡和资源回收。