远程通信协议：RPCvsHTTP
RPC与HTTP：理解远程通信的核心概念
什么是RPC？
RPC（Remote Procedure Call，远程过程调用）是一种计算机通信协议，它允许一个程序（客户端）像调用本地方法一样调用另一个地址空间（通常是远程服务器）上的程序或服务，而不需要显式处理网络通信的细节。
RPC的核心思想是透明性——开发者可以像调用本地函数一样调用远程函数，底层通信细节被隐藏起来。RPC框架通常包括：
• 客户端存根（stub）：负责将调用信息序列化并发送到网络
• 服务器端骨架（skeleton）：负责接收请求并调用实际的方法
• 通信协议：定义数据传输格式和规则
• 序列化机制：将数据结构或对象转换为可传输的格式
常见的RPC框架包括gRPC、Thrift、Dubbo等。
什么是HTTP？
HTTP（Hypertext Transfer Protocol，超文本传输协议）是应用层协议，用于分布式、协作式的超媒体信息系统。它是万维网（WWW）数据通信的基础。
HTTP基于请求-响应模型工作：
- 客户端（通常是浏览器）向服务器发送HTTP请求
- 服务器处理请求并返回HTTP响应
- 连接通常会在响应后关闭（除非使用持久连接）
HTTP是无状态协议，每个请求都是独立的，服务器不会保留之前请求的信息。现代HTTP/1.1和HTTP/2支持持久连接、管道化和头部压缩等特性。
RPC与HTTP的区别
| 特性 | RPC | HTTP |
|---|---|---|
| 设计目的 | 远程方法调用，强调透明性 | 超文本传输，强调资源交换 |
| 通信模型 | 通常面向过程/方法调用 | 面向资源（RESTful）或动作（SOAP） |
| 协议层 | 可以在传输层之上直接构建 | 应用层协议，通常基于TCP |
| 性能 | 通常更高（二进制协议，更少的开销） | 相对较低（文本协议，更多元数据） |
| 序列化 | 使用高效的二进制格式（如Protocol Buffers） | 通常使用文本格式（JSON/XML） |
| 服务发现 | 内置服务发现机制 | 需要额外组件（如API网关） |
| 适用场景 | 内部服务间通信，高性能需求 | 公开API，浏览器-服务器交互 |
| 跨语言支持 | 需要特定客户端实现 | 通用性强，几乎所有语言都支持 |
如何选择？
选择RPC还是HTTP取决于具体场景：
使用RPC当：
• 需要高性能的内部服务通信
• 服务间调用频繁且延迟敏感
• 需要强类型接口和编译时检查
• 系统由同一团队维护，可以统一技术栈
使用HTTP当：
• 需要公开API供第三方使用
• 需要与浏览器直接交互
• 系统组件由不同团队维护，需要松耦合
• 需要利用现有的HTTP基础设施（缓存、负载均衡等）
现代趋势：融合与演进
值得注意的是，现代技术趋势正在模糊RPC和HTTP的界限：
• gRPC基于HTTP/2，结合了RPC的高效和HTTP的通用性
• RESTful API设计借鉴了RPC的一些思想
• GraphQL提供了类似RPC的精确查询能力，同时运行在HTTP上
结论
RPC和HTTP都是实现远程通信的重要技术，各有优势和适用场景。理解它们的核心差异有助于我们在系统设计中做出合理的选择。随着技术的发展，两者也在相互借鉴和融合，开发者可以根据具体需求选择最适合的方案，甚至组合使用它们。