gRPC(HTTP/2) 是否比使用 HTTP/2 的 REST 更快？

Question

目标是引入一种在延迟和网络吞吐量方面更好的传输和应用层协议。目前，该应用程序使用 REST 和 HTTP/1.1，我们会遇到高延迟。我需要解决这个延迟问题，我愿意使用 gRPC(HTTP/2) 或 REST/HTTP2。

HTTP/2：

1. 多路复用
2. 单 TCP 连接
3. 二进制而不是文本
4. 标题压缩
5. 服务器推送

我了解上述所有优势。 问题 1：如果我使用 REST 和 HTTP/2，我相信与 REST 和 HTTP/1.1 相比，我将获得显着的性能提升，但这与 gRPC(HTTP/2) 相比如何？

我还知道 gRPC 使用 proto 缓冲区，这是用于在线传输结构化数据的最佳 二进制序列化 技术。 Proto 缓冲区还有助于开发一种与语言无关的方法。我同意这一点，我可以使用 graphQL 在 REST 中实现相同的功能。但我担心的是序列化：问题 2： 当 HTTP/2 实现此 二进制功能 时，使用 proto 缓冲区是否会带来额外的优势在 HTTP/2 之上？

问题 3：就流式传输、双向用例而言，gRPC(HTTP/2) 与（REST 和 HTTP/2）相比如何)?

互联网上有很多博客/视频将 gRPC(HTTP/2) 与（REST 和 HTTP/1.1）进行比较，例如 this。如前所述，我想知道比较 GRPC(HTTP/2) 和（REST 与 HTTP/2）的区别和好处。

Answer 1

默认情况下，gRPC 并不比 REST over HTTP/2 快，但它为您提供了使其更快的工具。有些事情用 REST 很难或不可能做到。

• 选择性消息压缩。在 gRPC 中，流式 RPC 可以决定压缩或不压缩消息。例如，如果您在单个流上传输混合的文本和图像（或实际上是任何混合的可压缩内容），您可以关闭图像的压缩。这样可以避免压缩已经压缩的数据，这些数据不会变得更小，但会烧毁 CPU。
• 一流的负载平衡。虽然在点对点连接方面没有改进，但 gRPC 可以智能地选择将流量发送到哪个后端。 （这是一个库功能，而不是有线协议功能）。这意味着您可以将请求发送到负载最少的后端服务器，而无需使用代理。这是延迟方面的胜利。
• 高度优化。 gRPC（库）位于continuous benchmarks 下，以确保没有速度回归。这些基准正在不断改进。同样，这与 gRPC 协议没有任何关系，但使用 gRPC 后您的程序会更快。

正如 nfirvine 所说，您将看到大部分性能提升仅来自使用 Protobuf。虽然您可以将 proto 与 REST 结合使用，但它与 gRPC 的集成非常好。从技术上讲，您可以将 JSON 与 gRPC 一起使用，但大多数人在习惯 protos 后不想支付性能成本。

Answer 2

无论如何，我都不是这方面的专家，也没有任何数据可以支持。

您所说的“二进制特性”是 HTTP/2 帧的二进制表示。内容本身（JSON 有效负载）仍将是 UTF-8。您可以压缩该 JSON 并设置 Content-Encoding: gzip，就像 HTTP/1 一样。

但是 gRPC 也可以进行 gzip 压缩。所以说真的，我们正在讨论 gzip 压缩的 JSON 与 gzip 压缩的 protobuf 之间的区别。

您可以想象，压缩的 protobuf 应该在各个方面都优于压缩的 JSON，否则 protobuf 将无法实现其目标。

除了 JSON 与 protobufs 的普遍性之外，我认为使用 protobufs 的唯一缺点是您需要 .proto 来解码它们，比如在 tcpdump 情况下。