为何gRPC吞吐量是HTTP/2+Protobuf的两倍？Java Spring Boot测试分析

我在Java+Spring Boot环境下开展不同传输协议的基准测试，发现gRPC的吞吐量远高于基于Protobuf的HTTP/2，且并发调用时两者差距进一步扩大。

JMH测试结果 #

protobufHttp2  thrpt   25  2196,489 ±  47,739  ops/s
grpc           thrpt   25  4650,875 ±  51,356  ops/s

HTTP/2客户端配置 #

HttpAsyncClients.customHttp2()
                .setDefaultConnectionConfig(ConnectionConfig.custom()
                        .setTimeToLive(TimeValue.ofMinutes(10))
                        .build())
                .setTlsStrategy(ClientTlsStrategyBuilder.create()
                        .setSslContext(selfSignSSLContext)
                        .build())

                .build();

核心性能优势机制 #

• 连接与流的精细化管理：gRPC基于HTTP/2但做了深度定制，默认保持长连接，单个连接上可高效多路复用数百个并发流。相比你使用的HttpAsyncClient，gRPC的流调度逻辑更贴合RPC场景，在流的创建、复用、销毁上的开销更低，高并发下能更充分利用连接资源。
• Protobuf与传输层的深度绑定：两者虽都用Protobuf，但gRPC的序列化/反序列化直接和传输逻辑整合，发送时无需额外HTTP报文头封装——gRPC仅用极简的HTTP/2头帧传递RPC元数据，而普通HTTP/2客户端会携带更多冗余头信息。此外，gRPC原生支持Protobuf消息的分帧传输，大消息自动拆分发送，避免单次传输阻塞，这部分逻辑普通HTTP/2客户端需自行实现，额外增加开销。
• 原生流量控制与背压：gRPC内置基于HTTP/2的流量控制和背压机制，能根据两端处理能力动态调整数据发送速率，避免缓冲区溢出和资源浪费。你的HttpAsyncClient配置未显式开启精细化流量控制，高并发下易出现拥塞，拖慢吞吐量。
• 内存与零拷贝优化：Java版gRPC大量使用直接ByteBuffer实现零拷贝，减少用户态与内核态的数据拷贝次数；同时自带内存池，复用序列化缓冲区，避免频繁内存分配回收带来的GC压力。普通HTTP/2客户端依赖JVM默认内存管理，高并发下GC开销更大，影响性能稳定性。
• RPC语义的原生支持：gRPC专为RPC场景设计，自带请求/响应、流式调用等语义，RPC元数据（如请求ID、错误码）通过HTTP/2头帧高效传输，无需像普通HTTP/2那样手动封装解析这些逻辑，减少了额外的序列化和处理开销。

内容的提问来源于stack exchange，提问作者Runekn