一、HTTP与RPC基本介绍

• HTTP协议（Hyper Text Transfer Protocol）超文本传输协议：
  • 一个用于在网络上交换信息的标准协议，它定义了客户端(例如浏览器)和服务器之间的通信方式。如平时上网在浏览器上敲个网址url就能访问网页，这里用到的就是HTTP协议。
  • 明确 HTTP 是一个协议，是一个超文本传输协议，不是运输通道。它基于 TCP/IP 来传输文本、图片、视频、音频等。HTTP 不提供数据包的传输功能，也就是数据包从浏览器到服务端再来回的传输和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 指的是两种常见的软件架构模型:

1. C/S:Client/Server,即客户端/服务器架构。
   • 这种架构中,客户端和服务器是独立的两个程序,通过某种网络协议进行通信。
   • 客户端需要安装专用的软件来访问服务器提供的服务。服务器提供各种功能给客户端调用。典型的 C/S 架构应用如QQ、迅雷、游戏客户端等各种需要安装对应软件的服务
   • C/S架构的概念可以追溯到20世纪60年代随着分布式计算的兴起开始出现，但真正流行开来是80年代中后期。
2. 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确实存在差异。

• 通信方式：RPC 是长链接，不必每次通信都要像 HTTP 一样去进行 3 次握手，减少了网络开销。
• 传输协议差异：HTTP 1.1使用文本协议，传输时必须包括报文头部与报文体，报文头部包含大量元数据，这使得每次通信的开销较高。相比之下，RPC可以使用自定义的传输协议，报文头部较小，不需要像HTTP那样考虑各种浏览器行为，如302重定向跳转，只含有必要的元数据，在远程调用时减少了通信的开销。
• 序列化差异：HTTP 1.1常用的序列化格式是文本格式，如JSON、XML等。尽管可以使用二进制编码协议如Protobuf对内容进行编码，但由于二进制编码的可读性较差，使用较少，且在打开网页时进行序列化json等文本格式的时间也可忽略不计，故通常在HTTP应用中，文本格式更为普遍。而在RPC中，由于通常用于服务间通信如游戏服务器，性能和效率更为重要，因此更常使用二进制编码协议。

3.2 HTTP 2.0

随着HTTP的发展，出现了HTTP 2.0和HTTP 3.0。 HTTP/2和HTTP/3在传输协议和性能方面都对HTTP/1.1进行了重要改进。它们都采用了二进制协议格式，可以更高效地传输数据。同时，它们都支持多路复用，可以同时在一个连接上发送多个请求和响应，减少了网络延迟和资源浪费。HTTP/2还引入了头部压缩技术，可以减小报文头的大小，提高传输效率。而HTTP/3则采用了QUIC协议和UDP传输，可以更快地建立连接并传输数据，提高了实时性和可靠性。

1. 回顾 Http1.x协议 
   Http1.0协议  请求响应的模式 短连接协议（无状态协议）  传输数据文本结构     单工 无法实现服务端推送 变相实现推动（客户端轮训的方式） 
   Http1.1协议  请求响应的模式 有限的长连接（可升级为WebSocket）  传输数据文本结构  双工 实现服务器向客户端推送。
   总结Http1.x协议 共性
     1. 传输数据文本格式 可读性好的但是效率差。
     2. 本质上Http1.x协议无法实现双工通信。
     3. 资源的请求。需要发送多次请求，建立多个连接才可以完成，如请求页面需要html，js，css，则需要建立3次连接。 
2. HTTP2.0协议 
     1. Http2.0协议是一个二进制协议，效率高于Http1.x协议，可读性差。
     2. 可以实现双工通信。
     3. 一个请求 一个连接 可以请求多个数据。【多路复用】
3. Http2.0协议的三个概念
     1. 数据流 stream
     2. 消息   message
     3. 帧    frame    参看图
4. 其他的相关概念
     1. 数据流的优先级，可以通过为不同的stream设置权重，来限制不同流的传输顺序。
     2. 流控 client发送的数据太快了，server处理不过来，通知client暂停数据的发送。

总结来说，HTTP/1.1相对于RPC在传输协议和性能方面有一些不足，但是随着HTTP/2和HTTP/3的出现，HTTP协议在这些方面得到了很大的改进，使得它在某些场景下可以替代RPC来进行高效的数据传输。如当前流行的gRPC框架底层就使用HTTP2.0 协议进行通信。

当然2015年才出现HTTP 2.0，因此在2015年之前使用RPC可以从效率方面进行考虑，但如今已经出现了效率一样的HTTP2.0，为什么还需要继续使用RPC呢？

3.3 为什么还需要使用RPC

根据上述对比分析，可以发现HTTP2.0协议已经优化编码效率问题，像 grpc 这种 rpc 库使用的就是 http2.0协议，那么为什么还需要使用RPC进行远程调用呢？
首先是历史原因，HTTP2.0在2015年才出现，因此许多公司内部已经使用了很久的PPC，更换需要很大的成本。

而之前说过，RPC并不是一个具体的协议，只是一种协议的规范，明确的说是概念、机制或者思想，它并没有具体实现，只有按照RPC通信协议规范实现的通信框架，也就是RPC框架，才是协议的具体实现，它包括了：接口规范+序列化反序列化规范+通信协议等。现在狭义的RPC一般指一些用IDL(Inteface Description Language)描述接口， 然后生成stub的框架, 比如grpc,thrift,dubbo等，其中grpc,dubbo3.0的传输用的都是HTTP2.0，也已经属于RPC和HTTP的融合体了，这种融合体的设计使得开发人员可以享受到HTTP的广泛支持，同时获得更好的性能和功能。

当我们使用比较成熟的RPC库时，RPC库通常提供了更多面向服务的高级特性，如服务发现、负载均衡和熔断降级等。

1. 服务发现：RPC库可以提供服务注册和发现的机制，使得服务之间的通信更加灵活和可靠。通过服务发现，服务可以自动注册自己的地址和状态，并且客户端可以动态地发现可用的服务实例。这样，当服务实例发生变化时，客户端可以自动适应并调用可用的服务。

建立连接的前提是，你得知道IP地址和端口。这个找到服务对应的IP端口的过程，其实就是服务发现。在HTTP中，你知道服务的域名，就可以通过DNS服务去解析得到它背后的IP地址，默认80端口。而RPC的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息，比如consul或者etcd，甚至是redis。想要访问某个服务，就去这些中间服务去获得IP和端口信息。由于dns也是服务发现的一种，所以也有基于dns去做服务发现的组件，比如CoreDNS。

2. 负载均衡：RPC库可以支持负载均衡算法，用于将请求动态地分配到不同的服务实例上。负载均衡可以根据实际情况，如服务实例的负载情况、网络延迟等，来决定将请求发送到哪个服务实例上，以实现请求的均衡分配和提高系统的性能和可伸缩性。
3. 熔断降级：RPC库可以实现熔断降级机制，用于处理服务不可用或响应时间过长的情况。当某个服务出现故障或性能下降时，熔断降级可以自动切换到备用服务或返回默认值，以保证系统的稳定性和可用性。熔断降级还可以防止故障的扩散，避免整个系统崩溃。

总的来说，RPC框架对比HTTP协议多了更高级的封装，它提供了服务发现、负载均衡和熔断降级等面向服务的高级特性。这些特性使得RPC框架在构建分布式微服务系统时更加方便和可靠，能够提供更好的性能、可伸缩性和容错能力。