RPC和HTTP的区别

RPC（Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议）是两种极为重要的通信方式。它们在诸多方面存在差异，理解这些不同点，对我们在实际开发中做出正确选择至关重要。下面就来深入分析一下RPC和HTTP的区别。

一、设计目标与核心思想

（一）RPC：让远程调用像本地调用一样简单

RPC的主要目的是让开发者在调用远程服务时，感觉就像在调用本地方法一样方便。它把网络通信中的序列化、传输、路由等复杂细节都隐藏起来了，重点关注的是提升效率，降低延迟。所以，RPC非常适合用在一个系统内部各个服务之间的通信场景中。

（二）HTTP：标准化资源交互的通用协议

HTTP作为通用的应用层协议，它的设计目标是规范客户端和服务器之间的资源交互过程。不管是获取Web页面，还是调用API，HTTP都能派上用场。它基于请求 – 响应模型工作，特别强调可扩展性、兼容性和可读性，这使得它在对外暴露服务方面表现出色。

二、协议特性差异

（一）协议格式：二进制与文本的较量

RPC通常会采用二进制协议，像Protobuf、Thrift就是典型代表。这种二进制格式的数据非常紧凑，解析起来效率很高。有些框架，比如gRPC，虽然是基于HTTP/2的，但数据依旧是二进制格式的。

HTTP在早期的时候，采用的是文本格式，就像HTTP/1.1版本，它的明文头以及常用的JSON/XML数据格式，虽然可读性很好，但是在效率方面就比较低。到了HTTP/2版本，引入了二进制分帧技术，性能有了很大提升，不过它的语义还是围绕着资源操作展开的，比如URL、请求方法、状态码这些。

（二）传输协议：不同的选择路径

RPC在传输协议的选择上比较灵活，既可以直接基于TCP/UDP，像Dubbo就是这样；也能结合HTTP/2，gRPC就是很好的例子。

HTTP则默认基于TCP协议，并且严格遵循应用层协议规范来进行通信。

三、性能表现

（一）序列化效率：RPC更胜一筹

在序列化效率方面，RPC使用的二进制协议优势明显。以Protobuf为例，它序列化速度快，生成的数据体积小。相比之下，HTTP常用的JSON/XML格式，数据体积比较大，解析时需要花费更多的开销。

（二）网络开销：HTTP/2缩小差距

RPC通过长连接和连接池技术，能够有效减少握手带来的开销。HTTP/1.1使用的是短连接，这就导致它的延迟比较高。不过，HTTP/2引入的多路复用技术，在很大程度上缩小了与RPC在网络开销方面的差距。

（三）典型场景：各司其职

RPC适合在微服务之间高频次调用的场景中使用，比如在电商系统里，订单服务频繁调用库存服务的时候，RPC就能发挥它的优势。

HTTP则更适合跨系统之间，以及浏览器和移动端的API交互场景。

四、功能与生态

（一）服务治理：RPC内置，HTTP依赖外部

RPC自身就集成了服务发现、负载均衡、熔断降级等服务治理功能。像Dubbo的注册中心，以及gRPC的健康检查，都是很好的体现。

HTTP想要实现这些服务治理功能，通常需要依赖网关，比如Nginx、Kong，或者借助服务网格，比如Istio来完成。

（二）跨语言支持：HTTP天然，RPC需借助IDL

HTTP在跨语言支持方面具有天然的优势，任何编程语言都能够处理HTTP请求。

RPC想要实现跨语言支持，一般需要通过IDL（接口定义语言）来生成多语言客户端。例如，使用Protobuf定义接口，然后根据这个接口生成不同语言的客户端代码。

五、开发体验

（一）调用方式：面向方法与面向资源

RPC采用的是面向方法的调用方式，就像调用本地对象的方法一样，比如userService.getUser(id)，开发者不用关心底层的网络细节。

HTTP则是面向资源操作的，像GET /users/{id}这种，开发者需要自己处理状态码、Header等信息。

（二）接口定义：强规范与灵活性

RPC对接口规范的依赖程度很高，一般需要通过像Protobuf文件这样的方式来定义接口，并且要预先生成代码。

HTTP通常是通过文档，比如OpenAPI来约定接口，这种方式灵活性比较高，但也容易出现接口不一致的问题。

六、适用场景

在不同的应用场景下，RPC和HTTP有着不同的适用性，具体如下：

场景	RPC	HTTP
内部服务通信	高频调用且对低延迟有要求时适用	性能开销相对较高，不太适合
对外暴露API	需要额外的网关进行适配，不太方便	对浏览器和移动端友好，非常适用
跨语言交互	需要生成多语言代码，相对麻烦	天然支持多语言，优势明显
实时流传输	支持双向流，如gRPC流式调用，表现出色	HTTP/2对实时流传输的支持有限