为何gRPC选择基于HTTP2而非直接基于TCP构建？

你提到的“TCP直接构建RPC更高效”在理论上成立，但gRPC选择HTTP2是权衡效率、开发成本、生态兼容性后的务实选择，核心原因如下：

• 避免重复造轮子，复用成熟特性
  HTTP2已经内置了大量RPC场景需要的关键能力：

  • 多路复用：单个TCP连接上同时处理多个请求/响应，避免TCP握手开销和连接数限制；
  • 流控：基于流的流量控制，防止发送端过载；
  • 头部压缩（HPACK）：大幅减少请求响应头部的传输体积；
  • 流优先级：允许高优先级请求优先处理，适合RPC中的关键调用场景。
    如果直接基于TCP自定义RPC协议，gRPC团队需要从零实现这些特性，不仅开发周期长，还容易引入稳定性问题。

• 兼容现有网络基础设施
  绝大多数现代网络设备（反向代理、负载均衡器、防火墙）都原生支持HTTP2，gRPC基于HTTP2可以直接接入这些现有系统，无需额外配置或改造。而自定义TCP协议可能被防火墙拦截，或者需要专门适配负载均衡策略，落地成本极高。

• 标准化带来的互操作性
  HTTP2是IETF标准化的协议，不同语言、平台都有成熟的HTTP2实现。gRPC基于HTTP2可以轻松实现跨语言、跨平台的服务调用，客户端和服务端的开发只需要遵循gRPC和HTTP2的标准即可，无需各自维护一套自定义协议的解析逻辑。

• HTTP2的额外开销可忽略
  虽然HTTP2比纯自定义TCP协议多了一层封装，但实际开销非常有限：HPACK头部压缩把元数据开销降到了极低，Protobuf序列化的高效性也抵消了HTTP2的微小额外消耗。在实际生产场景中，gRPC的性能和基于TCP的自定义RPC差距极小，但却获得了远高于后者的生态兼容性和开发效率。

• 原生支持安全特性
  HTTP2天然支持TLS加密，gRPC可以直接复用这一能力实现传输层安全，无需自己开发加密、身份验证逻辑。自定义TCP协议则需要额外集成TLS或实现自定义安全机制，增加了复杂度。

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