GRPC (HTTP/2)比使用 HTTP/2的 REST 快吗？

目标是引入一个在 潜伏期和 网络吞吐量网络吞吐量中表现更好的传输和应用层协议。目前，应用程序使用 休息和 HTTP/1.1，我们经历了一个高延迟。我需要解决这个延迟问题，我开放使用 GRPC (HTTP/2)或 REST/HTTP2。

HTTP/2:

  1. 多路复用
  2. 单一 TCP 连接
  3. 二进制代替文本
  4. 头部压缩
  5. 服务器推送

我知道以上所有的好处。如果我使用 带 HTTP/2的 REST，我确信，与 带 HTTP/1.1的 REST相比，我将获得显著的性能提高，但这与 GRPC (HTTP/2)相比如何？

我还知道 gRPC 使用 proto buffer，这是在线上传输结构化数据的最佳 二进制序列化技术。原型缓冲区还有助于开发一种语言无关的方法。我同意这一点，并且我可以使用 GraphQL 在 REST 中实现相同的特性。但是我关心的是序列化: 问题二:当 HTTP/2实现这个 二进制特征时，使用 proto buffer 是否在 HTTP/2之上提供了额外的优势？

问题3: 就 流，双向用例而言，gRPC (HTTP/2)与(REST 和 HTTP/2)相比如何？

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

42872 次浏览
小开

无论如何，我都不是这方面的专家，而且我也没有任何数据来支持这一切。

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

但是 gRPC 也可以进行 gzip 压缩，所以实际上，我们讨论的是 gzip 压缩的 JSON 和 gzip 压缩的原型 bufs 之间的区别。

正如您可以想象的那样，压缩的原型程序应该在各个方面击败压缩的 JSON，否则原型程序就达不到它们的目标。

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

小开
最佳答案

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

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

正如 nfirvine 所说，只要使用 Protobuf，您就可以看到大部分的性能改进。虽然 可以在 REST 中使用 proto，但是它与 gRPC 集成得非常好。从技术上讲，您可以将 JSON 与 gRPC 一起使用，但是大多数人在习惯了原型之后并不想为此付出性能代价。


提交答案