从 TCP 到 RPC：彻底搞懂「HTTP 与 RPC用法区别」
刚入行时，我曾一度困惑：HTTP 用得好好的，为啥微服务之间偏要选 RPC？直到顺着网络协议的演进脉络梳理下来，才发现这不是「替代关系」，而是「场景适配」的选择。今天就把这些知识点整合起来，用松散的节奏带你吃透 HTTP 与 RPC 的核心逻辑。
一、先搞懂底层：TCP 的特性与痛点
要理解 HTTP 和 RPC，得先从它们的「地基」—— TCP 说起。
TCP 是 70 年代就诞生的传输层协议，核心特性很明确：
面向连接：通信前必须建立三次握手
可靠传输：丢包会重传，保证数据完整
基于字节流：数据像水流一样连续传输，没有天然边界
但「字节流无边界」恰恰是个大问题 —— 这就是 粘包 / 拆包 痛点。
举个生动的例子：
客户端发送了两句话：「夏洛特」和「特烦恼」，但 TCP 传输时可能会把它们拼成「夏洛特特烦恼」一起发，也可能拆成「夏洛」「特特烦恼」分开发。接收端根本不知道哪里是一句话的结束，哪里是另一句话的开始。
怎么解决？
答案是「自定义协议封装」：在 TCP 字节流之上，加上「消息头 + 消息体」的结构。比如用消息头里的「长度字段」告诉接收端：接下来多少字节是一个完整的消息。这也是 HTTP 和 RPC 协议的底层核心逻辑。
二、HTTP 与 RPC 的起源：谁先谁后？
很多人误以为 RPC 是「后起之秀」，其实恰恰相反：
70 年代：TCP 诞生，提供底层传输能力
80 年代：RPC 出现，解决「裸 TCP」的开发痛点（序列化、粘包、连接管理）
90 年代：HTTP 流行，专为浏览器与 Web 服务器通信设计
所以问题本质不是「有了 HTTP 为什么要 RPC」，而是「有了 RPC 为什么要 HTTP」—— 因为 HTTP 更通用、更开放，适合跨平台、跨设备的公开通信。
它们的本质都是「基于 TCP 的应用层协议」，只是设计目标不同：
HTTP：面向「浏览器 + 公开服务」，追求通用、兼容、易理解
RPC：面向「内部服务 + 远程调用」，追求高效、性能、简洁
三、HTTP 与 RPC 的核心区别：一张表看明白
对比维度
HTTP
RPC
服务发现
依赖 DNS 解析域名，默认 80/443 端口
依赖服务注册中心（Consul/Etcd/Nacos）或 CoreDNS
连接管理
HTTP/1.1 用 Keep-Alive 复用连接，高并发下有瓶颈
维护连接池，请求时取连接、用完放回，高效应对高并发
传输格式
文本格式（JSON/XML），Header 冗余多（User-Agent、Content-Type 等）
二进制格式（Protobuf/Thrift），Header 精简，无冗余
设计目标
兼容浏览器，需处理跨域、Cookie、302 跳转等场景
专注内部服务调用，无需兼容浏览器，只追求性能
开发成本
低，无需客户端 SDK，直接用 Postman 调试
中，需引入框架 SDK，生成客户端代码，但调用像本地方法
四、适用场景：没有好坏，只有适合
技术选型的核心是「匹配场景」，两者的分工很明确：
✅ 选 HTTP 的场景
对外提供服务：比如前后端交互、给第三方开放 API
需求简单，无需追求极致性能：比如管理后台的接口调用
跨平台、跨设备通信：比如手机 App、小程序、网页都要调用的服务
✅ 选 RPC 的场景
内部微服务通信：比如电商系统的「订单服务」调用「库存服务」
高并发、低延迟需求：比如秒杀场景，需要快速响应
多语言混合开发：比如 Java 服务调用 Go 服务，RPC 跨语言能力更强
五、补充知识点：让理解更完整
上面是核心逻辑，下面这些补充内容能帮你应对实际开发中的问题：
1. 常见的 RPC 实现框架（落地必备）
RPC 是一种「思想」，实际开发需要用具体框架：
Dubbo：阿里开源，Java 技术栈首选，支持多协议、多注册中心，生态成熟
gRPC：Google 开源，基于 HTTP/2 + Protobuf，跨语言能力极强（支持 Java/Go/Python 等 10+ 语言）
Thrift：Facebook 开源，支持多种序列化协议和传输方式，灵活度高
Spring Cloud OpenFeign：基于 HTTP 的 RPC 风格框架，兼顾开发效率和性能，适合 Spring 技术栈
2. HTTP 协议演进：正在缩小与 RPC 的性能差距
之前说 HTTP 性能不如 RPC，主要针对 HTTP/1.1。但 HTTP 也在进化：
HTTP/2：支持多路复用（一个连接并发处理多个请求）、头部压缩、二进制帧，性能提升 30%~50%，甚至成为 gRPC 的底层传输协议
HTTP/3：基于 QUIC（UDP + TLS），解决了 TCP 队头阻塞问题，性能更优，未来可能让 HTTP 和 RPC 的边界更模糊
3. RPC 的核心组件与完整调用流程
RPC 框架之所以好用，是因为封装了复杂的底层逻辑，核心组件包括：
服务注册与发现：服务启动时注册地址，调用时查询地址
序列化 / 反序列化：把对象转二进制（如 Protobuf），或反之
网络传输：基于 TCP/HTTP/2 传输数据
负载均衡：把请求分发到不同服务实例（轮询、加权轮询等）
容错机制：超时重试、熔断、降级（避免服务雪崩）
完整调用流程（像调用本地方法一样简单）：
客户端调用本地代理（Stub），比如 orderService.reduceStock()
Stub 把参数序列化，通过网络发送给服务端
服务端代理（Skeleton）接收请求，反序列化参数，调用实际的 reduceStock() 方法
服务端把返回结果序列化，发送给客户端
客户端 Stub 反序列化结果，返回给调用者
4. 粘包 / 拆包的 3 种具体解决方法
之前提到「消息头 + 消息体」，这里补充常见方案：
固定长度法：每个消息长度固定，不足的补空格（简单但浪费空间）
分隔符法：用特殊字符（如换行符）分隔消息（需处理消息中包含分隔符的情况）
消息头 + 消息体法：消息头包含消息长度（如 4 字节表示长度），这是 RPC 最常用的方式（如 Dubbo 协议）
5. 技术选型的具体决策依据
除了场景，还可以参考这几点：
团队技术栈：Java 团队选 Dubbo，多语言团队选 gRPC
性能要求：QPS 百万级选 RPC，十万级以下选 HTTP 足够
开发效率：追求快速上线选 OpenFeign/HTTP，追求长期性能选 Dubbo/gRPC
维护成本：HTTP 无需额外依赖，RPC 需维护注册中心、SDK 版本
总结：不用纠结，按场景选就对了
HTTP 和 RPC 不是「竞争对手」，而是「互补搭档」：
对外通信、简单场景：用 HTTP，通用、省心
内部微服务、高并发场景：用 RPC，高效、强大
搞懂它们的底层逻辑和场景差异，下次技术选型时就不会迷茫啦～