首选理清楚关系
RPC与HTTP是两个不同维度的东西
HTTP 协议(H yper T ext T ransfer P rotocol),又叫做超文本传输协议,是一种传输协议,平时通过浏览器浏览网页网页,用到的就是 HTTP 协议。
而 RPC (R emote P rocedure C all),又叫做远程过程调用 。它本身并不是一个具体的协议,而是一种调用方式。
RPC这种调用方式,主要有两部分组成
- 传输协议
- 序列化方式
传输协议有多种,比如HTTP协议、自研协议等。
序列化方式有很多种,比如二进制流,JSON,XML等
所以HTTP协议只是RPC中传输协议
中的一种
如果传输协议与序列化方式选择HTTP与JSON,只要封装的好,也能实现这个远程调用,也能称之为RPC。
只不过早期的RPC因为传输效率的原因,大多没有选择HTTP与JSON,而是自研协议与二进制传输。
网上区分RPC与HTTP的文章太多了,我也没必要重复,所以我提供一种新的角度,就是根据历史的发展进行解释。
历史发展
早期互联网,大多是C/S架构,并且不需要对外开发API,仅自己内部调用(中国互联网对外开放事件:3Q大战),并且大家的带宽还很低,此时的HTTP协议还是1.0(1.0传输效率低,具体为什么,后面会讲)。
基于以上背景,当时需要一种高效率的传输方式,并且不需要考虑兼容性。
所以在传输协议的选择上,基于TCP的自研协议的RPC就应运而生了。
也是因为上述相同的历史背景,所以当时传输信息的序列化方式不是现在流行的JSON或者XML,而是二进制流,因为体积更小,传输效率更高。
内部系统
但是对于大型企业来说,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;
其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。
RPC额外优势
一般RPC框架,不仅仅有传输功能,还添加了很多其他功能,比如服务发现、负载均衡、链路追踪、限流降级等等。比如这里的Dubbo
为什么不直接使用TCP协议?
这里就不赘述,简单说TCP协议有自身的问题,比如粘包问题等,直接使用会有问题,所以都是基于TCP的自研协议。
RPC 协议 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/protocol/
HTTP协议为什么效率低?
一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成,下图给出了请求报文的一般格式。
HTTP请求报文
这里可以看出,HTTP协议为了传输内容,前后增加了很多"冗余"的字段,当然这里的"冗余"是为了通用性与兼容性,毕竟HTTP协议要兼容大多数不同的浏览器与不同的设备。
但是如果不需要考虑兼容性,只针对具体的设备,那就是真冗余了
为什么现在用了HTTP协议?
现在很多是直接使用HTTP协议,并且现在很多RPC框架也是使用的HTTP协议,原因如下
- 因为HTTP也一直在升级,也优化了性能
- 网友的带宽也在提升,对性能要求没这么高了
- 兼容性,之前接口仅需支持单个设备,现在需要支持多设备了,而HTTP的兼容性是最好的,几乎所有设备都会支持
- 成本问题:自研也需要开发成本,还要考虑兼容性。
基于以上原因,如果对性能没有极致要求,没必要自研协议,直接使用HTTP协议
总结
而 RPC (R emote P rocedure C all),又叫做远程过程调用 。它本身并不是一个具体的协议,而是一种调用方式,只要能够实现这种调用方式都可以称为RPC
实现RPC有两个核心点,传输协议
与序列化方式
,而HTTP
只是传输协议
中的一种。
参考
RPC 协议 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/protocol/