gRPC（HTTP / 2）是否比使用HTTP / 2的REST更快？

Question 1

目标是引入一种传输和应用程序层协议，该协议的延迟和网络吞吐量都更好。当前，该应用程序将REST与HTTP / 1.1结合使用，并且我们遇到了高延迟。我需要解决此延迟问题，并且愿意使用gRPC（HTTP / 2）或REST / HTTP2。

HTTP / 2：

多路复用
单TCP连接
二进制而不是文本
标头压缩
服务器推送

我知道上述所有优点。问题1：我可以肯定，如果我将REST与HTTP / 2一起使用，与使用HTTP / 1.1的REST相比，我将获得显着的性能提升，但是与gRPC（HTTP / 2）相比又如何呢？

我也知道gRPC使用原始缓冲区，这是在网络上传输结构化数据的最佳二进制序列化技术。Proto缓冲区还有助于开发不可知的语言方法。我同意这一点，并且可以使用graphQL在REST中实现相同的功能。但是我担心的是序列化：问题2：当HTTP / 2实现此二进制功能时，使用原型缓冲区是否能在HTTP / 2之上带来更多优势？

问题3：在双向流传输用例方面，gRPC（HTTP / 2）与（REST和HTTP / 2）相比如何？

有这么多的博客/视频出像比较GRPC（HTTP / 2）（REST和HTTP / 1.1）互联网这个。如前所述，我想知道在比较GRPC（HTTP / 2）和（REST与HTTP / 2）方面的区别和好处。

Question 2

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

选择性消息压缩。在gRPC中，流式RPC可以决定压缩还是不压缩消息。例如，如果要通过单个流（或实际上任何混合的可压缩内容）流式混合文本和图像，则可以关闭图像的压缩。这样可以避免压缩已经压缩的数据，这些数据不会变得更小，但是会消耗您的CPU。
一流的负载平衡。尽管点对点连接没有改进，但gRPC可以智能地选择向哪个后端发送流量。（这是库功能，而不是有线协议功能）。这意味着您可以将请求发送到负载最少的后端服务器，而无需使用代理。这是等待时间的胜利。
大量优化。gRPC（库）处于连续基准测试之下，以确保不存在速度下降。这些基准不断提高。同样，这与gRPC协议没有任何关系，但是您的程序使用gRPC会更快。

正如nfirvine所说，您将仅通过使用Protobuf就能看到大部分性能改进。虽然您可以将REST与REST一起使用，但它已与gRPC很好地集成在一起。从技术上讲，您可以将JSON与gRPC一起使用，但是大多数人在习惯了原型后并不想支付性能成本。

Question 3

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

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

但是gRPC也会进行gzip压缩。所以说真的，我们是在谈论gzip压缩的JSON与gzip压缩的protobufs之间的区别。

可以想象，压缩的protobuf应该在所有方面击败压缩的JSON，否则protobuf的目标就失败了。

除了JSON和protobufs的普遍存在之外，我看到使用protobufs的唯一缺点是，您需要使用.proto对其进行解码，例如在tcpdump情况下。