一、HTTP与RPC基本介绍
- HTTP协议（Hyper Text Transfer Protocol）超文本传输协议：
- 一个用于在网络上交换信息的标准协议，它定义了客户端(例如浏览器)和服务器之间的通信方式。如平时上网在浏览器上敲个网址url就能访问网页，这里用到的就是HTTP协议。
- HTTP最早版本在1989年提出,经过多年发展,到1996年发布的HTTP/1.1版本一直沿用至今，而在2015年也出现了HTTP/2.0。
- RPC（Remote Procedure Call）远程过程调用：
- 能够调用位于另一个地址空间(通常是网络上的另一台计算机)中的函数,而对程序员来说是透明的。仅仅是远程调用，还不算是RPC，因为RPC强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装。
- 它本身并不是一个具体的协议，只是一种协议的规范，明确的说是概念、机制或者思想，它并没有具体实现，只有按照RPC通信协议规范实现的通信框架，也就是RPC框架，才是协议的具体实现，比如Dubbo、gRPC等。它包括了：接口规范+序列化反序列化规范+通信协议等
- RPC的概念可以追溯到1970年代,但真正流行起来是1980年代中后期,随着分布式计算的兴起。1984年发布的ONC RPC和1986年的DCE RPC是最早的RPC实现。
在面试题中可能会看到为什么有了HTTP，还需要RPC，但由上述介绍可知，RPC的提出及使用时间均比HTTP要早，故首先需要思考第一个问题——为什么有RPC还要有HTTP协议？
二、为什么有了RPC，还需要HTTP
2.1 历史追溯——B/S与C/S架构
首先，我们需要先了解 B/S 和 C/S 指的是两种常见的软件架构模型:
- C/S:Client/Server,即客户端/服务器架构。
- 这种架构中,客户端和服务器是独立的两个程序,通过某种网络协议进行通信。
- 客户端需要安装专用的软件来访问服务器提供的服务。服务器提供各种功能给客户端调用。典型的 C/S 架构应用如QQ、迅雷、游戏客户端等各种需要安装对应软件的服务
- C/S架构的概念可以追溯到20世纪60年代随着分布式计算的兴起开始出现，但真正流行开来是80年代中后期。
- B/S:Browser/Server,即浏览器/服务器架构。
- 这种架构中,客户端只需要使用 web 浏览器来访问 web 服务器提供的服务。web 服务器提供 HTML、JavaScript、CSS 等页面,浏览器负责展现。
- 典型的 B/S 架构应用就是 web 应用。用户只需要一个浏览器就可以访问服务，而不需要安装任何客户端软件。
- B/S架构是与万维网、HTTP协议同时出现的，大约出现于1989年。
因此由上可知，在刚开始C/S架构流行时，对于C/S架构下的软件,如聊天软件、办公软件等，它们只需要与自己公司的服务器通信,所以可以使用自家定制的RPC协议进行远程调用即可。但随着万维网与B/S架构的出现，浏览器产生了，而浏览器需要访问来自不同公司的很多网站，这不能通过RPC进行访问，所以需要一个统一的标准来与这些网站服务器通信。这就是HTTP协议发挥作用的地方。HTTP为B/S架构(浏览器/服务器架构)提供了一个统一的标准,让不同网站的服务器能够与浏览器交互。
2.2 RPC与HTTP主流应用场景
由以上分析可知，在多年前，RPC与HTTP有对应的主流应用场景
- RPC 更多用于 C/S 架构,即客户端(Client)和服务器(Server)之间的通信。因为 C/S 架构通常是 within an organization(一个组织内部),所以可以使用自家定制的 RPC 协议来实现客户端和服务器之间的通信。
- HTTP 主要用于 B/S 架构,即浏览器(Browser)和服务器(Server)之间的通信。因为浏览器需要一个统一的标准来访问不同网站的服务器,所以 HTTP 成为了 B/S 架构的标准协议。而HTTP发明的场景是用于web架构，而不是分布式系统间通信，这导致了在很长一段时间内，HTTP是浏览器程序和后端web系统通信用的东西，传输的文档格式是繁琐的HTML格式，因此没有人把HTTP作为分布式系统通信的协议。
但是随着用户需要，许多软件同时支持多端，现在情况已经变化，B/S 架构和 C/S 架构在慢慢融合。越来越多的应用同时支持 Web 端、手机端和 PC 端。
- 随着前端技术的发展，AJAX技术和JSON文档在前端界逐渐成为主流，HTTP调用摆脱HTML，开始使用JSON这一相对简洁的文档格式。之后随着RESTFUL思潮的兴起，越来越多系统用HTTP来提供服务。因此为了简化架构，现在很多应用选择使用 HTTP 作为统一的通信协议，来支持多端通信。这使服务器端只需要实现一次 HTTP 接口，就可以支持所有客户端。
- 而 RPC 协议则主要用于 within an organization(一个组织内部),比如公司内部的微服务(Microservices)之间的通信。
- 所以总的趋势是:HTTP 作为公用的标准协议不断普及，而自家定制的 RPC 协议则主要用于内部集群(Cluster)。
而由上介绍，我们可以知道HTTP既可以用于B/S端，也可以用于C/S端，那这样为什么不全部使用HTTP协议呢，即引出了接下来的经典面试问题——为什么有了HTTP，还需要RPC
3. 为什么有了HTTP，还需要RPC
3.1 HTTP与RPC对比分析
HTTP通常指的是HTTP1.1版本，在对HTTP1.1与RPC进行分析时，一般会从以下方面进行分析：
| 特点 | HTTP 1.1 | RPC |
|---|---|---|
| 协议用途 | 对外的异构环境，浏览器接⼝调⽤，APP接⼝调⽤，第三⽅接⼝调⽤等 | 公司内部的服务调⽤，性能消耗低，传输效率⾼，服务治理 |
| 通信方式 | 请求-响应模型，独立连接 | 调用-返回模型，长连接 |
| 传输协议 | 通过HTTP1.1传输，报文体积大 | 自定义TCP协议传输，也可以基于HTTP协议 |
| 序列化 | 文本或二进制 ，大多使用json ，也可以使用 protobuf 二进制编码 | 文本或二进制 |
| 通信效率 | 可支持连接池复用 | 多次调用在同一连接中，通信效率较高 |
| 数据格式 | 使用通用的数据格式，如JSON、XML等 | 可以使用自定义的IDL来定义接口 |
| 接口定义和调用 | 使用URL标识资源和进行请求与响应 | 使用接口描述语言定义接口和方法 |
| 安全性和认证 | 可使用TLS/SSL | 身份验证、加密和授权 |
如上所示， HTTP 1.1和RPC在传输协议和序列化方面确实存在差异。以下是对HTTP 1.1和RPC在这两个方面的差距的理解：
- 传输协议差异：HTTP 1.1使用文本协议，其报文头部包含大量元数据，这使得每次通信的开销较高。相比之下，RPC可以使用自定义的传输协议，报文头部较小，只含有必要的元数据，从而减少了通信的开销。
- 序列化差异：HTTP 1.1常用的序列化格式是文本格式，如JSON、XML等。尽管可以使用二进制编码协议如Protobuf对内容进行编码，但由于二进制编码的可读性较差，使用较少，且在打开网页时进行序列化json等文本格式的时间也可忽略不计，故通常在HTTP应用中，文本格式更为普遍。而在RPC中，由于通常用于服务间通信如游戏服务器，性能和效率更为重要，因此更常使用二进制编码协议。
另外，需要指出的是，随着HTTP的发展，出现了HTTP 2.0和HTTP 3.0。 HTTP/2和HTTP/3在传输协议和性能方面都对HTTP/1.1进行了重要改进。它们都采用了二进制协议格式，可以更高效地传输数据。同时，它们都支持多路复用，可以同时在一个连接上发送多个请求和响应，减少了网络延迟和资源浪费。HTTP/2还引入了头部压缩技术，可以减小报文头的大小，提高传输效率。而HTTP/3则采用了QUIC协议和UDP传输，可以更快地建立连接并传输数据，提高了实时性和可靠性。
总结来说，HTTP/1.1相对于RPC在传输协议和性能方面有一些不足，但是随着HTTP/2和HTTP/3的出现，HTTP协议在这些方面得到了很大的改进，使得它在某些场景下可以替代RPC来进行高效的数据传输。如当前流行的gRPC框架底层就使用HTTP2.0 协议进行通信。
当然2015年才出现HTTP 2.0，因此在2015年之前使用RPC可以从效率方面进行考虑，但如今已经出现了效率一样的HTTP2.0，为什么还需要继续使用RPC呢？
3.2 为什么还需要使用RPC
根据上述对比分析，可以发现HTTP2.0协议已经优化编码效率问题，像 grpc 这种 rpc 库使用的就是 http2.0协议，那么为什么还需要使用RPC进行远程调用呢？
之前说过，RPC并不是一个具体的协议，只是一种协议的规范，明确的说是概念、机制或者思想，它并没有具体实现，只有按照RPC通信协议规范实现的通信框架，也就是RPC框架，才是协议的具体实现，它包括了：接口规范+序列化反序列化规范+通信协议等。现在狭义的RPC一般指一些用IDL(Inteface Description Language)描述接口， 然后生成stub的框架, 比如grpc,thrift,dubbo等，其中grpc,dubbo3.0的传输用的都是HTTP2.0，也已经属于RPC和HTTP的融合体了，这种融合体的设计使得开发人员可以享受到HTTP的广泛支持，同时获得更好的性能和功能。
当我们使用比较成熟的RPC库时，RPC库通常提供了更多面向服务的高级特性，如服务发现、负载均衡和熔断降级等。
- 服务发现：RPC库可以提供服务注册和发现的机制，使得服务之间的通信更加灵活和可靠。通过服务发现，服务可以自动注册自己的地址和状态，并且客户端可以动态地发现可用的服务实例。这样，当服务实例发生变化时，客户端可以自动适应并调用可用的服务。
- 负载均衡：RPC库可以支持负载均衡算法，用于将请求动态地分配到不同的服务实例上。负载均衡可以根据实际情况，如服务实例的负载情况、网络延迟等，来决定将请求发送到哪个服务实例上，以实现请求的均衡分配和提高系统的性能和可伸缩性。
- 熔断降级：RPC库可以实现熔断降级机制，用于处理服务不可用或响应时间过长的情况。当某个服务出现故障或性能下降时，熔断降级可以自动切换到备用服务或返回默认值，以保证系统的稳定性和可用性。熔断降级还可以防止故障的扩散，避免整个系统崩溃。
总的来说，RPC框架是对HTTP协议的更高级封装，它提供了服务发现、负载均衡和熔断降级等面向服务的高级特性。这些特性使得RPC框架在构建分布式微服务系统时更加方便和可靠，能够提供更好的性能、可伸缩性和容错能力。