RPC与HTTP的关系

首选理清楚关系

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框架，不仅仅有传输功能，还添加了很多其他功能，比如服务发现、负载均衡、链路追踪、限流降级等等。比如这里的Dubbo

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

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

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

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

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

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

而 RPC （R emote P rocedure C all），又叫做远程过程调用 。它本身并不是一个具体的协议，而是一种调用方式，只要能够实现这种调用方式都可以称为RPC

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