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

HTTP和RPC

HTTP 协议（H yper T ext T ransfer P rotocol），又叫做超文本传输协议。平时上网在浏览器上敲个网址就能访问网页，这里用到的就是HTTP协议。

RPC （R emote P rocedure C all），又叫做远程过程调用 。它并不是一个具体的协议，而是一种调用方式。

像之前的单体时代，我们的 service 调用就是自己实现的方法，是本地进程内的调用。

public User getUserById(Long id) {
	return userDao.getUserById(id); // 这叫本地调用
}

现在都是微服务了，根据业务模块做了不同的拆分，像用户的服务不用我这个小组负责，我这小组只要写订单服务就行了。

但是我们服务需要用到用户的信息，于是我们需要调用用户小组的服务，于是代码变成了以下这种

public User getUserById(Long id) {
    return userConsumer.getUserById(id); // 远程调用
}

我们像调用本地方法那样去调用它，屏蔽掉一些网络细节，这样用起来岂不是很方便。

值得注意的是，虽然大部分RPC协议底层使用TCP，但实际上它们不一定非得使用TCP，改用UDP或者HTTP，其实也可以做到类似的功能。

RPC 调用使用的场景更多的公司内部的多个服务之间的通信。

服务的拆分独立部署，那服务间的调用就必然需要网络通信，用 Http的方式调用当然可行，但是比较麻烦。

想要服务被拆分了但是使用起来还是和之前本地调用一样方便，所以就出现了 RPC 框架，来屏蔽这些底层调用细节，使得我们编码上还是和之前本地调用相差不多。

HTTP 协议比较的冗余，RPC 都是内部调用所以不需要太考虑通用性，只要公司内部保持格式统一即可。

我们来看看RPC和HTTP区别比较明显的几个点。

首先要向某个服务器发起请求，你得先建立连接，而建立连接的前提是，你得知道IP地址和端口 。这个找到服务对应的IP端口的过程，其实就是服务发现。

在HTTP 中，你知道服务的域名，就可以通过DNS服务去解析得到它背后的IP地址。

而RPC 的话，就有些区别，一般会有专门的中间服务 去保存服务名和IP信息，比如**consul。**想要访问某个服务，就去这些中间服务去获得IP和端口信息。

以主流的HTTP1.1 协议为例，其默认在建立底层TCP连接之后会一直保持这个连接（keep alive），之后的请求和响应都会复用这条连接。

RPC ，也跟HTTP类似，也是通过建立TCP长链接进行数据交互，但不同的地方在于，RPC协议一般还会再建个连接池 ，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。

由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给HTTP加个连接池 ，比如go就是这么干的。这一块两者也没太大区别。

基于TCP传输的消息：header 是用于标记一些特殊信息、body则是放我们真正需要传输的内容。

可以看到像header里的很多信息，其实如果我们约定好之后，就不用每次都传输了，比如"content-type"这个字段。

RPC，因为它定制化程度更高，可以采用体积更小的protobuf或其他序列化协议去保存结构体数据，同时也不需要像HTTP那样考虑各种浏览器行为，比如302重定向跳转什么的。因此性能也会更好一些。

HTTP原理

RPC原理

HTTP2.0在HTTP1.1的基础上做了优化，性能可能比很多RPC协议都要好。