在分布式系统的世界里，RPC（远程过程调用）和HTTP（超文本传输协议）是两种最常见的通信方式。它们看似不同，但本质上都是基于底层的TCP/IP协议发展而来。本文将从网络通信的底层逻辑出发，梳理两者的演进历程、核心区别以及适用场景。
什么是RPC
RPC，全程Remote Procedure Calls远程程序调用，是一种方法，并不是和http一样的协议
首先看时间关系
gantt
dateFormat YYYY
title TCP协议、RPC、HTTP1.0和2.0诞生时间轴
section 协议诞生
TCP协议诞生 :1974, 1y
RPC（ONC RPC定义为标准）:1988, 1y
HTTP/1.0发布 :1996, 1y
HTTP/2.0发布 :2015, 1y
一、TCP：一切通信的基石
TCP（传输控制协议）是互联网的“基础设施”，负责在不可靠的网络环境中提供可靠的数据传输。它的核心特性包括：
- 面向连接：通过三次握手建立连接，确保通信双方就绪。
- 可靠传输：通过确认机制、重传和流量控制保证数据不丢失、不重复。
- 有序性：数据包按顺序到达，避免乱序问题。
为什么需要上层协议？
TCP虽然可靠，但它只负责传输“原始字节流”，无法直接表达复杂的业务逻辑（比如“调用一个远程函数”或“获取一个网页”）。因此，开发者需要在其上构建应用层协议，定义数据格式和交互规则，这就是HTTP和RPC诞生的背景。
sequenceDiagram
participant Client
participant Server
Client->>Server: 发送 SYN（同步位），初始序号 seq=x
Server->>Client: 发送 SYN+ACK（同步位和确认位），确认序号 ack=x+1，初始序号 seq=y
Client->>Server: 发送 ACK（确认位），确认序号 ack=y+1
二、HTTP的演进：从简单文本到高效协议
HTTP最初是为Web设计的“请求-响应”协议，随着互联网的发展不断优化：
- HTTP/0.9与HTTP/1.0
- 简单文本协议，每次请求需新建TCP连接，效率低下。
- 典型场景：获取静态HTML页面。
- HTTP/1.1（1997）
- 引入持久连接（Keep-Alive）和管道化（Pipelining），复用TCP连接。
- 新增缓存控制、分块传输等特性。
- 痛点：队头阻塞（Head-of-Line Blocking），顺序请求导致效率受限。
- HTTP/2（2015）
- 二进制分帧层：将请求/响应拆分为帧，支持多路复用（Multiplexing），彻底解决队头阻塞。
- 头部压缩（HPACK）、服务端推送（Server Push）等优化。
- 核心思想：在保持HTTP语义的同时，提升传输效率。
- HTTP/3（2022）
- 基于UDP的QUIC协议，解决TCP的队头阻塞和握手延迟。
- 连接迁移（切换网络不断连）、0-RTT快速握手。
HTTP的核心定位：
- 通用性强：无状态、基于URI的资源操作（GET/POST/PUT/DELETE）。
- 跨平台：浏览器、移动端、API网关均可使用。
- 语义明确：设计目标是传输超文本（如HTML），但逐渐成为RESTful API的事实标准。
三、RPC的诞生：让远程调用像本地调用一样简单
RPC的目标是隐藏网络细节，让开发者像调用本地函数一样调用远程服务。其核心设计包括：
- 核心组件
- 序列化：将对象转换为二进制（如Protobuf、JSON、Thrift）。
- 传输协议：基于TCP或HTTP/2等协议传输数据。
- 服务发现：自动定位服务节点（如Consul、Zookeeper）。
- 负载均衡与容错：失败重试、熔断机制等。
- RPC协议的发展
- 早期RPC：如Sun RPC（1980s），基于TCP/UDP，但耦合度高。
- 现代RPC框架：如gRPC（基于HTTP/2）、Dubbo（自定义协议）、Thrift（多协议支持）。
- 趋势：拥抱标准协议（如HTTP/2），同时提供更高效的序列化（如Protobuf）。
- 与HTTP的关键区别
- 性能：RPC通常使用二进制序列化（如Protobuf），比HTTP+JSON更高效。
- 灵活性：RPC协议可定制（如连接池、压缩算法），而HTTP是通用协议。
- 服务治理：RPC框架内置服务发现、监控等能力，HTTP需依赖外部组件（如API网关）。
四、RPC与HTTP的融合：界限逐渐模糊
随着HTTP/2的普及，RPC与HTTP的界限不再绝对：
- gRPC：基于HTTP/2和Protobuf，兼具RPC的高效和HTTP的通用性。
- RESTful API：可通过OpenAPI规范实现类似RPC的强类型接口（如GraphQL）。
- HTTP/3：QUIC协议可能成为未来RPC的底层传输选项。
五、如何选择RPC与HTTP？
- 选择RPC的场景：
- 微服务内部通信，追求高性能、低延迟。
- 需要服务治理（如熔断、链路追踪）。
- 强类型接口，跨语言支持（如gRPC）。
- 选择HTTP的场景：
- 对外公开API，需跨平台兼容（浏览器、移动端）。
- 遵循RESTful风格，资源化操作（如CRUD）。
- 快速迭代，无需复杂服务治理。
六、总结
- TCP是通信的基石，解决了可靠传输问题。
- HTTP是通用应用层协议，从简单文本发展到高效二进制协议。
- RPC是面向服务调用的设计模式，追求性能和开发体验。
- 未来趋势：协议分层逐渐淡化，底层追求效率（QUIC），上层追求易用性（gRPC）。
无论是RPC还是HTTP，本质上都是为了解决同一个问题：如何在网络上高效、可靠地交换数据。理解它们的底层逻辑，才能在实际场景中做出合理的技术选型。