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

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

HTTP/2:

多路复用

单TCP连接

二进制而不是文本

报头压缩

服务器推送

我知道以上所有优点问题1:如果我使用HTTP/2的REST，我确信，与HTTP/1.1的REST相比，我会获得显著的性能改进，但这与gRPC（HTTP/2）相比如何

我还知道gRPC使用proto buffer，这是在线路上传输结构化数据的最佳二进制序列化技术。Proto-buffer还有助于开发语言不可知的方法。我同意这一点，并且可以使用graphQL在REST中实现相同的功能。但我担心的是序列化：问题2:当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）的区别和好处。

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

您所说的“二进制特性”是HTTP/2帧的二进制表示。内容本身（JSON负载）仍然是UTF-8。您可以压缩JSON并设置

内容编码：gzip

，就像HTTP/1一样

但是gRPC也做gzip压缩。实际上，我们讨论的是gzip压缩的JSON和gzip压缩的protobufs之间的区别

正如您可以想象的那样，压缩的protobufs应该在各个方面都优于压缩的JSON，否则protobufs的目标就失败了

---

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

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

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

---

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

感谢@nfirvine对这个问题的意见。序列化功能有点道理。您可以添加一些关于REST和gRPC中如何进行序列化的详细信息/解释吗。如果你能在同一个网站上分享一些链接，那就太好了。谢谢你@Carl的回答。你能给我们分享一些解释以上所有事情的链接/文档，以及基准测试的链接吗？我更新了对仪表板链接的回复。我没有直接解释这些的文档，但我是核心贡献者。请提供负载平衡

库
链接你最终使用了什么？HTTP2+REST有框架吗？@knocte我最终使用了gPRC。它很好地减少了延迟。关于HTTP/2+REST，没有特定的框架，您需要在使用的服务器中更改设置。比如说，您正在使用nginx，查看文档以了解设置HTTP/2.0的步骤，并且您必须确保HTTP/1.1重用连接。否则，搜索“tcp冷启动”。默认情况下，gRPC重用连接。