RPC 和 http 相比优势在哪里?

[chaleaochexist]

其实我的实际问题是:

http 比 RPC 开发更快速高效简单

为什么服务和服务内部的通信不能使用 http 而要用GRPC?

是因为高效? 高效在哪里? GRPC 是基于 HTTP2 的.

因为 SDK? 为什么一定要开发一套 SDK? 用通用的 http 库不行吗?

HTTP 难道不是跨语言的吗?

站内搜索遇到过类似的问题

https://www.v2ex.com/t/709864

https://v2ex.com/t/656766

还是理解不了.

1. RPC 出现比 http 早
2. RPC 和 http 不是同一概念无法比较 这两类观点楼主已经了解. 感谢.

[thinkershare]

HTTP 比 RPC(这里特指 GRPC) 开发更快速高效简单? 这个观念不知道你怎么有的，HTTP 现在一点也不简单。
HTTP 创建之初就是为纯文本通讯而设计的,它天然的通讯协议开销是无法通过技术手段消除的，HTTP2/HTTP3 都无法解决这个问题，虽然它们做了很多优化和压缩。
gRPC 这个设计最初就是为服务之间的相互通讯设计的，它一开始就采用了和语言无关的二进制通讯模式，这使得它天然更加适合服务通讯，HTTP 协议提供的很多功能在服务相互调用时根本不需要。

[chaleaochexist]

@thinkershare 总结一句话就是 GRPC 更高效
但问题是 GRPC 高效在哪里 除了 protobuf vs json?
我的理解 GRPC 本身是基于 http2 的那么无法规避 http2 的任何低效问题.

我可以这么理解吗?

[buaacss]

开发过一个分布式任务调度系统，我的理解是

1 、grpc 上带有 context ，可以双向超时+取消，只要长链接中断就可以各自执行中断处理。
2 、grpc 支持双向 stream ，这对于一些要求获取远程调用实时输出的程序很友好。
3 、对于一般业务来说和 http 相比没有优势

[chaleaochexist]

@thinkershare 我说的开发更快速高效简单是指开发效率而不是运行效率.

[chaleaochexist]

@buaacss 感谢.

[chaleaochexist]

@buaacss 不过
1. 双向超时和取消 http 也有办法做到啊. timeout 参数, 取消的话我不是很了解 GRPC 是如何实现的, 等我天亮了去学习一下.
2. 双向 stream 是不是 websocket 也可以实现.
3. 我认同 哈哈....

[wangnimabenma]

没在生产环境用过，但是我的理解是

[chaleaochexist]

@wangnimabenma 是啥?

[wangnimabenma]

没在生产环境用过，但是我的理解是
1. 基于 http2.0 比 1.1 传输高效（多路复用什么的）
2. Keepalive 机制
3. *.proto 的文件定义比看文档方便
4. 协议帧的二进制通讯，提高了 API 被爬的门槛

[thinkershare]

@chaleaochexist
1：protocol buffers 和任何基于文本的序列化性能差异是很大的，它是一个规范，只要最终大家都支持，那它就会成为 HTTP 那样的共识协议，这个共识在二进制序列化上要达成只要 google 这种全球化的公司才有可能完成。
2：HTTP 2 通过新的链接复用，在传输上已经解决了低效问题，然后就是对基于文本头的魔值定义再次压缩的通讯的协议头大小，基本上在传输上效率大大提高了，但它的核心问题还是 body 部分需要一个统一的二进制规范。
3. 最核心的是 HTTP 协议有很多功能是为服务器-浏览器模式定制的，这些功能在服务器-服务器的时候没啥作用，这部分功能在 gRPC 通讯层可以和直接屏蔽掉，不对最终消费 gRPC 的用户开放。

[wangnimabenma]

还有强类型定义说漏了

[haozibi]

个人理解

RPC ，client 像调用本地函数一样调用接口，语义更加明确，更加规范，无需关心连接、序列化等细节，这些都由 RPC 框架帮你做了

「通用的 HTTP 库」，如果这个库把连接池、编码等等功能都实现了，调用方每个接口的调用无须做重复性劳动，那么这个「通用的 HTTP 库」何尝不是一个 RPC

[leonshaw]

> 2. RPC 和 http 不是同一概念无法比较

既然你已经了解，为啥还会提出这个问题？你所说的 http 是特指 HTTP 1.x 还是包括 HTTP2 ？如果是前者，就 gRPC 而言，先了解一下 HTTP2 比 HTTP 1.1 的优势。如果是后者，就好像在问 HTTP 和 TCP 相比优势在哪里。

[Chingim]

@leonshaw 不懂就问，rpc 是不是基于 tcp 的上层封装？
如果是，那应当能跟 http 比较一番才对

[b1ghawk]

@Chingim rpc 在其协议内容里，直接支持"RPC"概念集里的各类元素，例如：过程、过程参数、参数类型、参数长度、返回类型等等...
而 http 的协议内容里并没有上述概念(面向资源)，需要在 http 协议之上，继续进行一些有关于 RPC 的封装，或者将 http 协议当中既有的某些元素映射成 rpc 里的某些元素。

其实用 ftp 当作 rpc 来用也可以吧……只是程序员面向的概念集不一样，ftp 里是 上传，下载，路径，要做一些额外的工作才可以当作 rpc 来用，但与 http 类似，均比原生 rpc 协议更加低效。

这种场景下，有什么理由不直接使用 rpc 的原生协议呢？合适的场景选择合适的工具，砍树用美工刀，切菜用老虎钳，拍蒜泥用枕头。能用，但不适合...

[leonshaw]

@Chingim 不是，RPC 可以基于任何通信方式（例如 UDP 、IP 甚至串口通信协议），基于 HTTP2 的 gRPC 显然和 HTTP 不在同一层。即使都是基于 TCP ，也未必有比较的意义，例如 HTTP 和 SSH 有啥好比较的呢？

[cassyfar]

我觉得 rpc 99% 的优势就是高效，其他都是添头。百万级 qps 以下服务用哪个都无所谓。

[yueji]

grpc 不能 cdn...

[chendy]

比较不了
RPC 是远程服务调用，强调可以像调用本地方法一样调用远程方法，具体是怎么调用的不管
HTTP 是一应用层协议
部分 RPC 的底层是 HTTP

http 手撸需要处理各种细节，rpc 通常就是写好 idl 生成代码，再把服务端逻辑写好就能用了

[buaacss]

楼上有补充强类型的，我也再来贡献各 case 。文本协议比特位翻转导致数据库更新了全表。

update xxx set a=1,b=2,c=3 where id=xxx;

被宇宙射线击中后，3 变成了#，导致后面的文本直接变成了注释

3 的二进制是 00110011
#的二进制是 00100011

第一次看到我都吓傻了