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

HTTP 和 RPC

HTTP 和 RPC 都基于 TCP 协议，都是为了解决 TCP 粘包问题。

• HTTP（Hyper Text Transfer Protocol，超文本传输协议）：
  • 浏览器这种不只需要访问自家服务器，还要访问其他家的服务器，需要使用统一标准，这种Browser/Server (B/S) 架构，一般使用 HTTP 协议。
  • 主要使用文本格式（如 JSON、XML）传输数据，数据会有冗余，效率较低。发送时这些数据也会编码成二进制
    • 为什么 HTTP 不能二进制传输呢？
  • 相对简单，通用，HTTP 目前是浏览器的唯一通信协议
• RPC（Remote Procedure Call，远程过程调用）：本身不是一个具体协议，是一种调用方式，调用远程服务器暴露的方法。像 gRPC 和 Thrift 这样才是协议。
  • 封装了调用细节，一般使用二进制格式传输数据，如Protocol Buffers（简称Protobuf），有更高的传输效率、更低的冗余。定制化程度高
  • 大部分底层使用 TCP，但是也可以使用 UDP 或者 HTTP。
  • 各种联网软件，是作为自家产品客户端，一般只要和自家服务端请求即可，这种 Client/Server (C/S) 架构 一般使用自家造的 RPC 协议，减少了 HTTP 的一些冗余兼容（需要适配浏览器。
  • 需要客户端跟服务端使用相同的传输协议和序列化协议
  • 其实比 HTTP 出现还早
  • 可能不如 HTTP2 性能好，所以很多基于 HTTP2实现，或者 HTTP3。
    • 只是因为出现的早，所以没有换成 HTTP2 或者 3

传输的内容

• 两者主要的区别：

  • 对于数字11来进行编码的区分

  • 二进制编码：11直接转化为二进制就是 1011 -> (2^3 +2^1+ 2^0)

  • 文本编码：11 需要拆分成两个 1 ，每个单独编码，即 0000 0001 0000 0001

  • 主流的 HTTP1.1 的header头部内容过于冗余，且在Body部分使用的是 JSON 进行序列化，且协议升级这种情况需要考虑用户浏览器的版本等问题，不能随意升级。

    • 当然现在的 HTTP2 在 HTTP1.1 的基础上改进很多，所以 性能可能比很多 RPC 协议还要好，甚至连gRPC底层都直接用的HTTP2。

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

而 RPC 的话，就有些区别，一般会有专门的中间服务去保存服务名和 IP 信息，比如 Consul、Etcd、Nacos、ZooKeeper，甚至是 Redis。想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如 CoreDNS。

---