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

目标是引入更好的延迟和网络吞吐量的传输和应用层协议.目前,该应用程序使用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 buffer,这是用于在线路上传输结构化数据的最佳二进制序列化技术.Proto缓冲区还有助于开发一种与语言无关的方法.我同意这一点,我可以使用graphQL在REST中实现相同的功能.但我关注的是序列化问题:问题2:当HTTP/2实现这个二进制特性时,使用proto缓冲区是否在HTTP/2之上提供了额外的优势？

问题3:在流媒体,双向用例方面,gRPC(HTTP/2)如何与(REST和HTTP/2)进行比较？

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

默认情况下,gRPC并不比REST over HTTP/2更快,但它为您提供了使其更快的工具.使用REST有些事情很难或不可能.

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

一流的负载均衡.虽然点对点连接没有改进,但gRPC可以智能地选择要向其发送流量的后端.(这是库功能,而不是有线协议功能).这意味着您可以将请求发送到负载最少的后端服务器,而无需使用代理.这是一个延迟胜利.

重新优化.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压缩的protobufs之间的区别.

可以想象,压缩的protobufs应该以各种方式击败压缩的JSON,否则protobufs就会失败.

除了无处不在的JSON与protobufs之外,我可以看到使用protobufs的唯一缺点是你需要.proto来解码它们,比如在tcpdump情况下.