首选理清楚关系
RPC与HTTP是两个不同维度的东西
HTTP 协议（Hyper Text Transfer Protocol），又叫做超文本传输协议，是一种传输协议，平时通过浏览器浏览网页网页，用到的就是 HTTP 协议。
而 RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。
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（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式，只要能够实现这种调用方式都可以称为RPC
实现RPC有两个核心点，传输协议与序列化方式，而HTTP只是传输协议中的一种。
参考
RPC 协议 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/protocol/
既然有 HTTP 协议，为什么还要有 RPC？
