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

使用纯裸 TCP 会有什么问题

八股文常背，TCP 是有三个特点，面向连接、可靠、基于字节流。

字节流简单来说就是一大堆 01 串。纯裸 TCP 收发的这些 01 串之间是没有任何边界的，你根本不知道到哪个地方才算一条完整消息。

这就容易出现粘包问题，无法区分出不同的消息。

HTTP 和 RPC

TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。

HTTP 协议（Hyper Text Transfer Protocol），又叫做超文本传输协议。我们用的比较多，平时上网在浏览器上敲个网址就能访问网页，这里用到的就是 HTTP 协议。

而 RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。

可以通过这种方式调用远端服务器暴露出来的一个方法。

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

TCP 是70 年代出来的协议，80 年代出来的 RPC， HTTP 是 90 年代才开始流行的，两者为了解决TCP的粘包问题。

现在电脑上装的各种联网软件，比如 xx 管家，xx 卫士，它们都作为客户端（Client）需要跟服务端（Server）建立连接收发消息，此时都会用到应用层协议，在这种 Client/Server (C/S) 架构下，它们可以使用自家造的 RPC 协议，因为它只管连自己公司的服务器就 ok 了。

但有个软件不同，浏览器（Browser），不管是 Chrome 还是 IE，它们不仅要能访问自家公司的服务器（Server），还需要访问其他公司的网站服务器，因此它们需要有个统一的标准，不然大家没法交流。于是，HTTP 就是那个时代用于统一 Browser/Server (B/S) 的协议。

目前 RPC 就开始退居幕后，一般用于公司内部集群里，各个微服务之间的通讯。

那这么说的话，都用 HTTP 得了，还用什么 RPC？

• RPC：

  • 是一种远程过程调用协议，它允许一个程序调用另一个地址空间（通常是在另一台计算机上）的过程或方法，就像调用本地函数一样。RPC封装了远程调用的细节，提供了透明化的远程通信方式。
  • 通常使用二进制格式传输数据，如Protocol Buffers（简称Protobuf），这种格式具有更高的传输效率和更低的冗余。RPC可以基于TCP协议或HTTP/2协议，支持多路复用、头部压缩等特性，进一步降低延迟和提高性能。
  • 它特别适用于对性能要求较高的场景，如微服务架构中的服务调用。
  • RPC 就是对请求过程的封装，使用不一样的传输协议和序列化协议。 那么就要求客户端跟服务端使用相同的传输协议和序列化协议。

• HTTP：

  • 主要使用文本格式（如JSON、XML）传输数据，这在某些情况下可能导致数据冗余和传输效率较低。不过，随着HTTP/2的普及，HTTP协议在性能上也有所提升，支持头部压缩、服务器推送等功能。
    • 在发送端，JSON数据首先被编码为二进制数据（例如，通过Base64编码等方式），然后在网络上传输。在接收端，接收到的二进制数据被解码回原始的JSON字符串，然后再进行解析和处理。
  • 虽然HTTP在性能和效率上可能略逊于RPC，但它具有简单、易用的特点，并且广泛应用于各种Web应用中。需要考虑各种浏览器行为。
  • HTTP协议简单、安全、可靠，能够满足众多应用程序的数据传输需求。特别是在浏览器环境中，HTTP是唯一的通信协议。

• 因为只有在内部服务间调用才能定制化协议，所以内部服务间才能使用 RPC 调用，调外部的第三方服务只能用 HTTP 协议。

---