RPC 是什么？HTTP 是什么？

作为一个程序员，假设我们需要从A电脑的进程发送一段数据到B电脑的进程，我们一般会在代码中使用 Socket 进行编程。

此时，可选性一般就是 TCP 和 UDP 二选一，由于 TCP 可靠、UDP 不可靠，只要对可靠性有要求，一般就选 TCP 了。

Socket 本质是个代码库，我们需要先创建类似于：

其中 SOCK_STREAM是指使用字节流传输数据。说白了就是 TCP 协议。

在定义了 socket 之后，我们就可以对这个 socket 进行操作。比如使用 bind() 方法绑定 IP 端口；用 connect() 方法发起建联，里面就包含了常见的 TCP 三次握手流程；在建立连接之后就可以使用 send() 方法发送数据；receive() 方法接收数据。

光这个“纯裸”的 TCP 连接就可以收发数据了，那是不是就够了？
不行。
八股文常背 TCP 有三个特点：面向连接、可靠、基于字节流。

这里关注“基于字节流”，字节流可以理解为双向通道里流淌的二进制数据，就是一堆“01”串。“纯裸”的 TCP 连接收发的这些“01”串是没有任何边界的，你无法知道一条完整消息的起始位置。

由于无边界，所以当选择使用 TCP 发送“夏洛特烦恼”时，接收端无法区分你想表达的是“夏洛” 和“特烦恼”还是“夏洛特”和“烦恼”。这也就是所谓的“粘包”问题。

既然“纯裸” TCP 是不能直接拿来用的，那就需要在这个基础上加入一些自定义规则，来区分 消息边界。
于是，我们会把每条要发送的消息都包装一下。比如加入消息头，消息头中写清楚一个完整的包长度是多少，根据这个长度可以继续接收数据，截取出来后，就是我们真正想传输的消息体。
这里的消息头中还可以放各种规则，比如消息体是否压缩、消息体格式之类的。只要上下游都约定好，互相能够解析，这就是所谓的协议了。

每个使用 TCP 的项目，都可能会定义一套类似于这样的协议解析标准，它们可能有区别，但原理都类似。
于是基于 TCP 就衍生出非常多的协议，如 HTTP 和 RPC 。

TCP 是传输层的协议，而基于 TCP 造出来的各类协议，都是定义了不同规则的应用层协议。

HTTP 协议又叫做“超文本传输协议”，我们平时上网在浏览器中敲个网址就能访问网页，用到的就是 HTTP 协议。

RPC(Remote Procedure Call)又叫做“远程过程调用”，它本身不是一种具体的协议，而是一种调用方式。
RPC 让我们可以像调用本地方法一样，调用远端服务器的方法（remoteFunc），屏蔽掉一些网络细节。

基于这个思路，大佬们造成了非常多款式的 RPC 协议，如 gRPC、tRPC 等。

虽然大部分 RPC 协议底层使用的是 TCP 协议，但也可以改用 UPD 或者 HTTP。

为什么有 HTTP 还要有 RPC?

其实，TCP 是 70年代的产物，HTTP 是 90年代的产物，由于直接使用 TCP 会出现粘包问题，所以可想而知，70~90年代之间会有很多协议产生，其中包含 80年代产出的 RPC 协议

因此我们该问的不是“为什么有 HTTP 还要有 RPC？”，而是“为什么有 RPC 还要有 HTTP？”。

为什么有 RPC 还要有 HTTP 协议？
现在电脑上安装的各种软件，如xx管家、xx视频，它们作为客户端，需要与服务端建立连接收发消息，都会用到应用层协议，在这种C/S（client server）架构下，他们就能使用自家造的RPC协议，因为只需要连接自己公司的服务器。

但是xx浏览器却不同，不管是 Chrome 还是 IE，它们不仅需要连接自家服务器，还需要访问其他公司的网站服务器，因此需要一个统一的标准。于是 HTTP 就是当时用于统一 browser server 的协议。

当时 HTTP 主要用于 B/S 架构，而 RPC 主要用于 C/S 架构，但是现在没有分那么清楚了，B/S 和 C/S 在慢慢融合。
很多软件需要支持多端，如网页端、PC端、移动端，如果通信协议都用 HTTP，那么服务器只用一套就够了，而 RPC 开始退居幕后，一般用于公司内部集群里各个微服务之间的通讯。
那么，既然有了 HTTP，为啥还要使用 RPC 呢？

为什么有 HTTP 还要有 RPC？
这个问题需要从二者的区别说起：
首先是服务发现。
服务建立连接的前提是需要知道对方的IP地址和端口号，寻找对方IP端口的过程叫做服务发现。
在 HTTP 中，知道服务的域名，就可以通过 DNS 服务器解析 IP 地址，端口默认是 80 。
而 RPC 需要专门的中间服务来保存服务名的IP信息，比如 etcd （甚至是 Redis）。
可以看出服务发现方面，二者虽有区别，但不分高低。

其次是底层连接形式。
以主流的 HTTP1.1 协议为例，默认在建立底层 TCP 连接之后会一直保持这个连接，Keep alive，之后的请求都会复用这条连接。

而 RPC 协议也和 HTTP 协议类似，也是通过建立 TCP 长连接进行数据交互，但不同的地方在于，RPC 一般还会再建立一个连接池，在请求量大的时候，建立多条连接放在连接池中，需要发数据的时候就从池中取出一条连接，用完载放回去。

由于连接池有利于提升网络性能，所以有些编程语言的网络库中也会给 HTTP 加个连接池，比如 Go。
可以看出这块二者也没有太大区别。

最后是传输的内容

传输内容是基于 TCP 传输的消息，包含消息头header 和 消息体body，header 适合标记一些特殊信息，其中最重要的信息就是消息体的长度；body则是放真正需要传输的内容，而这些内容只能是二进制数据。

所以 TCP 传输字符串和数字的问题不大，因为字符串可以编码，再变成二进制，而数字本身可以直接转为二进制。
但是结构体呢？
需要想办法转为二进制，现在的方案主要有 json、protoBuf 。将这个结构体转为二进制的过程叫做序列化。

对于主流的 HTTP1.1，虽然现在叫做超文本协议，支持音频视频，但是在设计之初是用于做网络文本展示的，所以传输内容主要以字符转为主，header和body都是如此，在 body 这块使用 json 来序列化结构体。
而 RPC 因为定制化程度更高，可以采用体积更小的 protobuf 文件或其他序列化协议，来保存结构体，同时不需要像 HTTP 那样考虑各种浏览器行为，如 302 定向跳转，因此性能会更好。这也是公司内部抛弃 HTTP 而选项 RPC 的主要原因。

当然，上面说的 HTTP 其实特指主流的 HTTP1.1, HTTP2 在前者的基础上做了很多改进，性能可能比 RPC 还好，甚至连 gRPC 底层都是用的 HTTP2，那么问题又来了，“为什么既然有了 HTTP2，还要使用 RPC?”,因为 HTTP2 是 2015 年才出来的，那时候很多公司内部的 RPC 服务都运行很多年了，基于历史原因，也就没必要换了。

参考：
RPC是什么？HTTP是什么？RPC和HTTP有什么区别？