为什么有了HTTP协议还需要RPC协议？

为什么有了HTTP协议还需要RPC协议？

我们在客户端和服务端之间传输数据的时候，一般为会选择TCP或则UDP协议
，
我们假定使用TCP作为传输层协议
TCP三大特点：1、面向连接 2、可靠 3、基于字节流
其中特性3，说明TCP传输的数据是二进制数据，简单说就是01串，我们无法知道如何解析这些发送的01数据。比如发送 “我是王子林老师” 我们无法知道应该把这句话解析为“我是传艺王子 林老师” 还是解析为 “我是传艺 王子林 老师”。这样你到底应该喊他王老师还是林老师呢？中文短句都有如此问题，01串更无法被计算机所解析，这个就是所谓的TCP粘包。

由于以上特点，我们无法把TCP数据直接用于数据传输。应该加上一定的“断句”来区分这些数据。我们常见的HTTP协议，就是在TCP数据流加入消息头，来进行标识，比如定义数据包的长度，消息体类型等。只要客户端和服务端之间约定相同的协议进行数据解析即可。（不用关心是HTTP还是RPC）
回到问题，为什么有了HTTP协议还需要RPC协议？
首先TCP协议在1970年被发明出来，HTTP1.1协议在1990年被发明出来，RPC协议在1980年被发明出来。所以问题应该是，为什么有了RPC协议还需要HTTP协议？

首先RPC协议本身最初发明是为了处理传统 C/S架构，即客户端/服务端，主要用于多个进程之间通信（跨进程函数调用）。而HTTP协议本身主要用于 B/S架构，即浏览器/服务端。而RPC协议本身只是一直传输数据的“断句”标准，各大厂商提供了不同的实现，比如著名的grpc。
传输层协议也不局限为TCP，也可以使用HTTP，UDP等。

现在大部分软件支持多端，即C/S，B/S融合，如果通信协议都用HTTP的话，那服务器只需要同一套就可以了。RPC协议这时候就开始退居幕后，一般用于公司内部进程调用，微服务等。

这时候就有一个问题，既然HTTP1.1 协议可以做到RPC协议的所有工作，为什么还要RPC协议呢？
主要原因是HTTP1.1协议本身传输数据使用json/text等文本传输，而RPC协议可以使用二进制数据流进行传输如grpc使用Protobuf, restrpc使用msgpack进行传输，本身也无需处理向HTTP302跳转这样的请求，所以本身效率高于HTTP1.1。还有一点区别是RPC协议一般使用一个长连接池，针对每次使用，只要从池中取出连接，能够更好的复用连接。（HTTP1.1后续也支持）

如今HTTP2.0在HTTP1.1协议上了做了很多优化，在效率上也能够超过大部分RPC协议，只是由于其2015年才问世，之前的旧产品，没有必要向HTTP2.0进行迁移。才导致RPC协议依旧存在。