目标是引入一个在 latency 和 network throughput 中更好的传输和应用层协议 . 目前，该应用程序使用 REST 和 HTTP/1.1 ，我们遇到高延迟 . 我需要解决这个延迟问题，我可以使用 gRPC(HTTP/2) 或 REST/HTTP2 .
HTTP/2:
-
多路复用
-
单TCP连接
-
二进制而不是文本
-
标头压缩
-
服务器推送
我知道上述所有优点 . Question No. 1: 如果我使用 REST with HTTP/2 ，我相信，与 REST with HTTP/1.1 相比，我将获得显着的性能提升，但这与 gRPC(HTTP/2) 相比如何？
我也知道gRPC使用proto缓冲区，这是用于在线路上传输结构化数据的最好的 binary serialization 技术 . Proto缓冲区还有助于开发一种与语言无关的方法 . 我同意这一点，我可以使用graphQL在REST中实现相同的功能 . 但我担心的是序列化： Question No. 2: 当 HTTP/2 实现了这个 binary feature 时，使用proto buffer是否会在HTTP / 2之上提供额外的优势？
Question No. 3: 就 streaming, bi-directional use-cases 而言，gRPC（HTTP / 2）如何与（REST和HTTP / 2）进行比较？
互联网上有很多 blogs/videos 用于比较gRPC（HTTP / 2）和（REST和HTTP / 1.1），如this . 如前所述，我想知道比较GRPC（HTTP / 2）和（REST与HTTP / 2）的差异和好处 .
2 回答
我无论如何都不是这方面的专家，我没有数据可以支持这一点 .
您正在谈论的"binary feature"是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情况下 .
默认情况下，gRPC并不比REST over HTTP / 2快，但它为您提供了使其更快的工具 . 使用REST有些事情很难或不可能 .
选择性消息压缩 . 在gRPC中，流式RPC可以决定压缩或不压缩消息 . 例如，如果您通过单个流（或实际上任何混合的可压缩内容）传输混合文本和图像，则可以关闭图像的压缩 . 这样可以避免压缩已压缩的数据，这些数据不会变小，但会烧毁CPU .
一流的负载均衡 . 虽然点对点连接没有改进，但gRPC可以智能地选择要向其发送流量的后端 . （这是库功能，而不是有线协议功能） . 这意味着您可以将请求发送到负载最少的后端服务器，而无需使用代理 . 这是一个延迟胜利 .
严重优化 . gRPC（库）在continuous benchmarks下，以确保没有速度回归 . 这些基准正在不断改进 . 同样，这与gRPC协议没有任何关系，但是你的程序使用gRPC会更快 .
正如nfirvine所说，您将通过使用Protobuf看到您的大部分性能提升 . 虽然你可以使用带有REST的proto，但它与gRPC非常完美地集成在一起 . 从技术上讲，您可以将JSON与gRPC一起使用，但大多数人不习惯在习惯protos后支付性能成本 .