网络编程——RPC与HTTP基本介绍、历史追溯、主流应用场景、对比分析、为什么还需要使用RPC

一、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 指的是两种常见的软件架构模型:

因此由上可知，在刚开始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确实存在差异。

• 通信方式：RPC 是长链接，不必每次通信都要像 HTTP 一样去进行 3 次握手，减少了网络开销。
• 传输协议差异：HTTP 1.1使用文本协议，传输时必须包括报文头部与报文体，报文头部包含大量元数据，这使得每次通信的开销较高。相比之下，RPC可以使用自定义的传输协议，报文头部较小，不需要像HTTP那样考虑各种浏览器行为，如302重定向跳转，只含有必要的元数据，在远程调用时减少了通信的开销。
• 序列化差异：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进行远程调用呢？
首先是历史原因，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库通常提供了更多面向服务的高级特性，如服务发现、负载均衡和熔断降级等。

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

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