gRPC消息大小限制需客户端和服务端双向显式配置，因默认4MB接收上限（4194304字节）会触发ResourceExhausted错误；仅调高单边或依赖内网带宽无效，必须两端同步设置MaxRecvMsgSize和MaxSendMsgSize且单位严格为字节。
为什么 grpc.MaxRecvMsgSize 和 grpc.MaxSendMsgSize 不能只看文档默认值
内网带宽高不等于 gRPC 能自动吞下大消息——默认的 4MB 接收上限会直接让大 payload 请求失败，错误是 rpc error: code = ResourceExhausted desc = grpc: received message larger than max (X vs. 4194304)。这不是网络问题，是客户端/服务端两边都得显式放宽限制，且必须对齐。
实操建议：
- 两端（client 和 server）都要设置，缺一不可；只改一边无效
- 数值单位是字节，别写成
10MB或10 * 1024 * 1024这种易错表达，直接写10485760或用常量如10 - 如果用的是 Go 的
grpc.Dial，需在grpc.WithDefaultCallOptions里传入；服务端则在grpc.Server初始化时通过grpc.MaxRecvMsgSize等选项配置 - 注意：
MaxRecvMsgSize影响内存分配策略，设得过大但实际消息小，会浪费预分配缓冲区；设得太小则频繁 realloc，反而拖慢吞吐
内网高吞吐下 grpc.WriteBufferSize 和 grpc.ReadBufferSize 怎么设才不浪费也不卡顿
这两个参数控制底层 TCP 连接的读写缓冲区大小，默认是 32KB。在千兆/万兆内网中，小缓冲区会导致频繁系统调用、数据分片增多，实测吞吐可能压不到带宽的 60%。
实操建议：
- 先确认真实单连接平均消息大小和频率；若多为
1–2MB批处理，可将WriteBufferSize提到1024 * 1024（1MB） -
ReadBufferSize建议 ≥WriteBufferSize，否则接收端来不及消费，发送端会因流控阻塞 - 不要盲目设到
16MB：Go runtime 的net.Conn在大 buffer 下可能触发更激进的 GC 扫描，反而增加延迟毛刺 - 验证方式：用
ss -i观察连接的rcv_space/snd_space是否稳定接近你设的值，而不是长期远低于它
启用 grpc.WithTransportCredentials(insecure.NewCredentials()) 后，缓冲行为有啥隐性变化
用明文传输（即禁用 TLS）时，gRPC 底层不再走 http2.Transport 的加密帧封装路径，而是直连 net.Conn。这会让缓冲区更“透明”，但也意味着你失去 TLS 层自带的流量整形和部分流控保护。
实操建议：
- 关闭 TLS 后，
MaxRecvMsgSize的校验仍生效，但ReadBufferSize对实际吞吐影响更直接——建议比 TLS 场景再提高 20%～30% - 务必关掉
grpc.WithKeepaliveParams中的Time和Timeout，否则明文连接在长连接空闲时更容易被中间设备（如某些 ToR 交换机）静默断连 - 若服务部署在容器中，检查宿主机
/proc/sys/net/core/rmem_max和wmem_max，确保它们 ≥ 你设的Read/WriteBufferSize，否则内核会默默截断
为什么 grpc.UseCompressor 在内网不一定加速，还可能变慢
压缩看似能减小传输量，但在高带宽低延迟内网中，CPU 压缩/解压开销常超过节省的网络时间。尤其当消息本身已含 JPEG、Protobuf 序列化后二进制密度高时，gzip 几乎压不出多少体积。
实操建议：
- 先用
protoc-gen-go生成的XXX.Size()方法估算原始消息大小；若Size() < 100KB，基本不用压缩 - 开启压缩后，对比
grpc_ctxtags+ Prometheus 的grpc_server_handled_latency_ms分位数，重点看 p99 是否上升 - 若必须压缩，优先选
snappy（Go 生态支持好、无依赖、压缩比适中），避免zstd（需 CGO，容器环境易出兼容问题） - 注意：压缩只作用于 message body，header 不压缩；所以大量 metadata 无法靠这个优化
缓冲区调优不是填几个数字就完事——每个参数背后都绑着内存分配、系统调用、内核 socket 缓冲、甚至 CPU 缓存行对齐行为。最容易被忽略的是：client 和 server 的缓冲配置必须成对验证，不能只测单边。
