gRPC 和 HTTP/2 是现代高性能服务通信的事实标准，其性能源于对网络底层的精准建模；关键调优包括通道复用、多连接突破流限制、窗口调优及 HPACK 动态表扩容。
gRPC 和 HTTP/2 不是“高级协议”的可选项，而是现代高性能服务通信的事实标准。它们的性能优势不来自功能堆砌，而来自对网络底层行为的精准建模与控制。调优的关键不是堆参数，而是理解连接、流、帧三者之间的约束关系。
重用 gRPC 通道是性能底线
每次新建 GrpcChannel 都会触发完整 TCP+TLS+HTTP/2 握手，耗时通常在 50–200ms。生产环境必须全局单例或通过依赖注入容器管理通道生命周期。
- 一个通道可安全并发发起数百个调用，多路复用在单个 HTTP/2 连接上完成
- .NET 中推荐使用
GrpcClientFactory，它自动复用通道并支持配置重试、超时、认证等策略 - Python 客户端应复用
grpc.insecure_channel()或grpc.secure_channel()实例，避免在循环或高频方法中重复创建
突破并发流限制：多连接不是妥协而是设计
HTTP/2 默认单连接最多 100 个并发流（SETTINGS_MAX_CONCURRENT_STREAMS）。当业务存在长周期流式响应（如日志订阅、实时指标推送）或突发高并发请求时，排队会导致尾部延迟激增。
- .NET 客户端启用
SocketsHttpHandler.EnableMultipleHttp2Connections = true，通道会在流满时自动新建连接 - Go 客户端可通过
grpc.WithTransportCredentials配合自定义http2.Transport设置MaxConcurrentStreams - 务必配合连接池健康检查——空闲连接需设
keepalive_time=45s，避免被中间设备（如Nginx、ELB）静默断连
窗口调优直击传输效率瓶颈
HTTP/2 的流量控制靠接收方通告窗口（WINDOW_UPDATE），默认初始连接窗口和流窗口均为 64KB。在千兆内网或低延迟专线中，这会造成大量等待帧，吞吐受限。
- 将
InitialWindowSize提升至 1MB～4MB（需客户端和服务端同步调整） - 根据带宽延迟积（BDP）动态计算：若 RTT=5ms、带宽=1Gbps，则 BDP ≈ 625KB，窗口至少设为 1MB 才能填满管道
- 禁用自动窗口调整（
AutoWindowUpdate=false）后，由应用层按需发送WINDOW_UPDATE，适合可控数据流场景
头部压缩与连接复用深度协同
HPACK 压缩效果高度依赖动态表命中率。gRPC 请求头虽短，但 grpc-encoding、grpc-timeout、authorization 等字段高频重复，动态表大小不足会导致频繁重建索引、CPU 升高。
- 将 HPACK 动态表大小从默认 4KB 提升至 16KB（需两端支持 HTTP/2 SETTINGS）
- 预加载常用 header 键值对进静态表（如 Envoy 可通过
http2_protocol_options配置） - 监控
hpack.dynamic_table_size和hpack.indexed_header_count指标，命中率低于 70% 就需扩容
