HTTP协议和RPC协议的区别

HTTP协议就是我们平常使用最多的协议，RPC协议又叫做远程调用协议，严格来说本身并不是一个协议而是一种调用方式。

大部分的RPC协议底层都使用的TCP，但实际上并不是必须使用TCP，使用UDP或者是HTTP也是可以的。

70年代提出了TCP协议，80年代提出了RPC协议，90年代提出了HTTP协议。

首先说一下TCP协议

TCP协议是一个使用字节流、面向连接的实现可靠传输的通信协议。其中字节流就是我们常说的01字符串组成的二进制数据，同时这些二进制的01字符串是没有任何边界的，所以你不知道那个地方切割才能算作是一条完整的消息。这也就是所谓的粘包问题。所以就需要增加一些自定义的规则来区分消息之间额消息边界。（就比如：HTTP请求的请求头当中会明确的指出一个完整的报的长度，从而明确消息之间的界限划分）。TCP和HTTP都是通过标准来解析实现上面的切分过程的。

 

区别1.服务发现

HTTP通过DNS解析域名来发现背后的IP地址和端口号实现远程通信。

RPC一般会用专门的服务中间件（ETCD、Consul甚至Redis）来记录对应的IP地址和端口号信息实现服务发，找对应的端口号等信息。

区别2.底层连接形式

HTTP1.1协议会建立长连接，也就是实现TCP连接的复用，从而不需要每次发送请求都需要重新建立连接。

RPC框架也会建立长连接进行数据交互，同时还会创建一个连接池，在请求量大的时候，多个连接放在连接池当中，发送数据的时候就取出一条连接出来，用完再放回去重复利用。进一步减少连接的时间。

连接池有利于提升网络性能，所以不少的编程语言的网络库中都会给HTTP加一个连接池（go）。

区别3.传输的内容

基于TCP传输的消息其实就是传输消息头header和消息体body。

Header里面记录了一些特殊信息，比如消息体长度。

Body里面记录的内容才是我们真正要去传输的数据，这些内容只能是二进制的01串。而将对应的结构体（对象）转换成对应的01串进行传递的这个过程就叫做序列化，因为我们不能直接传输json字符串，所以必须要将对应的字符串序列化成01串的字节流之后才能进行消息的传输。

我们能够看到这里面的内容十分冗余，比如Header当中的信息，如果我们提前约定好了第几位对应的什么数据，那么就不需要每次都将左边“Content-type”这个字段全部都传递过来，只需要传递具体的数据值即可。

RPC因为定制化程度较高，可以采用体积更小的Protobuf或者其他序列化协议去保存结构体，也不需要向http协议那样考虑各种浏览器的行为。所以性能会更好一点。因为传递的消息体积越小涮传递量越少那么多赢的传递的性能也一定更高，所以在公司内部微服务中只要提前约定好远程传输的请求内容，就可以提高性能，所以会更多地使用公司自己研发的RPC框架来实现远程调用。

上面说的HTTP协议更多的指的是现在主流使用的HTTP1.1，但是HTTP2在前者的基础上进行了许多的改进所以性能可能比很多PRC协议还好，甚至gRPC底层都可以直接使用HTTP2。但是因为HTTP是2015年新提出来的协议，这个时候许多公司已经有了自己成熟的RPC协议，并且跑了很多年了，所以基于历史原因也就没必要去更换成HTTP2了。