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

Question

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

复用

单 TCP 连接

1. 二进制而不是文本
2. 标头压缩
3. 服务器推送
我了解以上所有优点。
5. 问题1：
如果我使用

REST with HTTP/2

，我确信，与REST with 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）的差异和好处。

默认情况下，gRPC 并不比 HTTP/2 上的 REST 快，但它为您提供了加快速度的工具。 有些事情使用 REST 很难或不可能完成。 选择性消息压缩。 在 gRPC 中，流式 RPC 可以决定压缩或不压缩消息。 例如，如果您通过单个流传输混合文本和图像（或任何混合的可压缩内容），则可以关闭图像压缩。 这可以让您免于压缩已经压缩的数据，这些数据不会变得更小，但会消耗您的 CPU。

Answer 1

深度优化。 gRPC（库）处于“连续基准”之下，以确保不存在速度回归。 这些基准正在不断提高。 再说一遍，这与 gRPC 协议没有任何关系，但使用 gRPC 后你的程序会更快。

• 正如 nfirvine 所说，您将通过使用 Protobuf 看到大部分性能提升。 虽然您
可以
• 将 proto 与 REST 结合使用，但它与 gRPC 集成得非常好。 从技术上讲，您可以将 JSON 与 gRPC 结合使用，但大多数人在习惯了 protos 后并不想付出性能成本。
• 无论如何，我都不是这方面的专家，而且我没有数据支持这一点。

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

Content-Encoding: gzip，就像 HTTP/1 一样。

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

Answer 2

正如你可以想象的，压缩的 protobufs 应该在各个方面击败压缩的 JSON，否则 protobufs 就无法实现他们的目标。

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

我发现， 如果您想发送 txt、img 或视频文件等文件，那么 REST/HTTP 比 gRPC 快得多。 如果您想通过网络发送对象，那么 gRPC 是有效的。

来源：

用于发送文件

,,

发送大文件

,,

Answer 3

基于 HTTP/2 的 gRPC 通常比基于 HTTP/2 的 REST 更快，其原因取决于两者的设计方式。 gRPC 使用协议缓冲区 (protobuf)，这是一种紧凑且高效的二进制格式，与 REST 不同，REST 通常依赖于 JSON（一种基于文本的格式，处理速度较慢且占用更多空间）。 gRPC 的另一个优势是其内置的双向流支持，允许客户端和服务器实时来回发送数据。另一方面，REST 坚持传统的请求-响应模型，这对于流式处理来说效率不高。虽然 gRPC 和 REST 都受益于复用和标头压缩等 HTTP/2 功能，但 gRPC 旨在充分利用这些功能，从而实现更低的延迟和更好的性能，尤其是在高吞吐量场景中。