gRPC(HTTP / 2)比使用HTTP / 2的REST更快吗? [英] Is gRPC(HTTP/2) faster than REST with HTTP/2?

查看:3700
本文介绍了gRPC(HTTP / 2)比使用HTTP / 2的REST更快吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的目标是引入传输层和应用层协议,它的延迟网络吞吐量更好。目前,该应用程序对 HTTP / 1.1 使用 REST ,并且我们遇到了高延迟。我需要解决这个延迟问题,我打算使用 gRPC(HTTP / 2) REST / HTTP2

HTTP / 2:


  1. 多路复用

  2. TCP连接

  3. 二进制代替文本

  4. 标题压缩

  5. 服务器推送

我知道所有上述优点。 问题1:如果我使用 REST与HTTP / 2 ,我相信,与使用HTTP / 1.1的 REST相比,我将获得显着的性能提升,但它与 gRPC(HTTP / 2)相比如何?

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



问题3:流媒体,双向使用案例,gRPC HTTP / 2)与(REST和HTTP / 2)进行比较?



互联网上有很多博客/视频 (HTTP / 2)与(REST和HTTP / 1.1),如这个。如前所述,我想知道在比较GRPC(HTTP / 2)和(REST与HTTP / 2)方面的差异和好处。

解决方案 div>

默认情况下,gRPC不比HTTP / REST更快,但它为您提供了更快的工具。有些事情对于REST来说很难或不可能做到。


  • 有选择的消息压缩。在gRPC中,流RPC可以决定压缩或不压缩消息。例如,如果您要通过单个流(或者真的是任何混合的可压缩内容)流式传输混合文本和图像,则可以关闭图像的压缩。这样可以避免压缩已压缩的数据,这些数据不会变小,但会烧毁CPU。

  • 一流的负载平衡。虽然点对点连接并未得到改进,但gRPC可以智能地选择将后端发送到哪个后端。 (这是一个库功能,而不是有线协议功能)。这意味着您可以将您的请求发送到最少加载的后端服务器,而无需使用代理。这是延迟获胜。

  • 重度优化。 gRPC(图书馆)在持续基准之下,以确保那里没有速度回归。这些基准正在不断改进。再次,这与gRPC协议没有任何关系,但是使用gRPC的程序会更快。



nfirvine说,使用Protobuf你会看到你的大部分性能改进。虽然您可以使用REST使用proto,但它与gRPC很好地结合在一起。从技术上讲,你可以在gRPC上使用JSON,但大多数人不希望在习惯protos后支付性能成本。


The goal is to introduce a transport and application layer protocol that is better in its latency and network throughput. Currently, the application uses REST with HTTP/1.1 and we experience a high latency. I need to resolve this latency problem and I am open to use either gRPC(HTTP/2) or REST/HTTP2.

HTTP/2:

  1. Multiplexed
  2. Single TCP Connection
  3. Binary instead of textual
  4. Header compression
  5. Server Push

I am aware of all the above advantages. Question No. 1: If I use REST with HTTP/2, I am sure, I will get a significant performance improvement when compared to REST with HTTP/1.1, but how does this compare with gRPC(HTTP/2)?

I am also aware that gRPC uses proto buffer, which is the best binary serialization technique for transmission of structured data on the wire. Proto buffer also helps in developing an language agnostic approach. I agree with that and I can implement the same feature in REST using graphQL. But my concern is over serialization: Question No. 2: When HTTP/2 implements this binary feature, does using proto buffer give an added advantage on top of HTTP/2?

Question No. 3: In terms of streaming, bi-directional use-cases, how does gRPC(HTTP/2) compare with (REST and HTTP/2)?

There are so many blogs/videos out in the internet that compares gRPC(HTTP/2) with (REST and HTTP/1.1) like this. As stated earlier, I would like to know the differences, benefits on comparing GRPC(HTTP/2) and (REST with HTTP/2).

解决方案

gRPC is not faster than REST over HTTP/2 by default, but it gives you the tools to make it faster. There are some things that would be difficult or impossible to do with REST.

  • Selective message compression. In gRPC a streaming RPC can decide to compress or not compress messages. For example, if you are streaming mixed text and images over a single stream (or really any mixed compressible content), you can turn off compression for the images. This saves you from compressing already compressed data which won't get any smaller, but will burn up your CPU.
  • First class load balancing. While not an improvement in point to point connections, gRPC can intelligently pick which backend to send traffic to. (this is a library feature, not a wire protocol feature). This means you can send your requests to the least loaded backend server without resorting to using a proxy. This is a latency win.
  • Heavily optimized. gRPC (the library) is under continuous benchmarks to ensure that there are no speed regressions. Those benchmarks are improving constantly. Again, this doesn't have anything to do with gRPC the protocol, but your program will be faster for having used gRPC.

As nfirvine said, you will see most of your performance improvement just from using Protobuf. While you could use proto with REST, it is very nicely integrated with gRPC. Technically, you could use JSON with gRPC, but most people don't want to pay the performance cost after getting used to protos.

这篇关于gRPC(HTTP / 2)比使用HTTP / 2的REST更快吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆