RPC与HTTP的关系

首选理清楚关系

RPC与HTTP是两个不同维度的东西

HTTP 协议(Hyper Text Transfer Protocol),又叫做超文本传输协议,是一种传输协议,平时通过浏览器浏览网页网页,用到的就是 HTTP 协议。

RPCRemote Procedure Call),又叫做远程过程调用。它本身并不是一个具体的协议,而是一种调用方式

RPC这种调用方式,主要有两部分组成

  1. 传输协议
  2. 序列化方式

传输协议有多种,比如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的关系_第1张图片
RPC与HTTP的关系_第2张图片
RPC与HTTP的关系_第3张图片

内部系统

但是对于大型企业来说,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;

其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。

RPC额外优势

一般RPC框架,不仅仅有传输功能,还添加了很多其他功能,比如服务发现、负载均衡、链路追踪、限流降级等等。比如这里的Dubbo

RPC与HTTP的关系_第4张图片

为什么不直接使用TCP协议?

这里就不赘述,简单说TCP协议有自身的问题,比如粘包问题等,直接使用会有问题,所以都是基于TCP的自研协议。

RPC 协议 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/protocol/

HTTP协议为什么效率低?

一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成,下图给出了请求报文的一般格式。

RPC与HTTP的关系_第5张图片

HTTP请求报文

RPC与HTTP的关系_第6张图片

这里可以看出,HTTP协议为了传输内容,前后增加了很多“冗余”的字段,当然这里的“冗余”是为了通用性与兼容性,毕竟HTTP协议要兼容大多数不同的浏览器与不同的设备。

但是如果不需要考虑兼容性,只针对具体的设备,那就是真冗余了

为什么现在用了HTTP协议?

现在很多是直接使用HTTP协议,并且现在很多RPC框架也是使用的HTTP协议,原因如下

  • 因为HTTP也一直在升级,也优化了性能
  • 网友的带宽也在提升,对性能要求没这么高了
  • 兼容性,之前接口仅需支持单个设备,现在需要支持多设备了,而HTTP的兼容性是最好的,几乎所有设备都会支持
  • 成本问题:自研也需要开发成本,还要考虑兼容性。

基于以上原因,如果对性能没有极致要求,没必要自研协议,直接使用HTTP协议

总结

RPCRemote Procedure Call),又叫做远程过程调用。它本身并不是一个具体的协议,而是一种调用方式,只要能够实现这种调用方式都可以称为RPC

实现RPC有两个核心点,传输协议序列化方式,而HTTP只是传输协议中的一种。

参考

RPC 协议 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/protocol/

既然有 HTTP 协议,为什么还要有 RPC?

你可能感兴趣的:(rpc,http,网络协议)