有了 HTTP，为什么还要 RPC？聊聊这两个东西到底差在哪

一个很自然的疑问

学网络编程的时候，大部分人都是先接触 HTTP。浏览器敲个地址，发个请求，拿个响应，这套东西太熟悉了。

然后突然有一天，面试官问你：“你们微服务之间用什么通信？”

你说 HTTP。

他接着问：“那为什么不用 RPC？HTTP 和 RPC 有什么区别？”

你愣住了。

这个问题其实很多工作两三年的程序员都说不清楚。不是他们菜，而是 HTTP 太常用了，日常开发里很少有机会去想"除了 HTTP 还能用什么"。

今天把这俩的关系掰扯清楚。

---

先别对立起来，它俩不是一个层面的东西

很多人一上来就把 HTTP 和 RPC 当对手，好像用了这个就不能用那个。这种理解从一开始就偏了。

HTTP 是应用层协议。 它的核心工作是定义数据怎么打包、怎么传输、怎么解析。请求行、状态码、Header、Body，一套固定的格式，浏览器认识，服务器也认识。

RPC 是一种思想，或者说设计理念。 它的目标是让你调用远程服务的时候，感觉就像在调本地方法一样。你只关心入参和返回值，网络通信的细节全部被屏蔽掉。

打个比方：

• HTTP 像是快递公司的标准化包装规范——箱子尺寸、面单格式、签收流程，全给你定死了。
• RPC 像是**"让对方帮你办一件事"这种协作方式**——你不在乎他是坐地铁来的还是打车来的，你只在乎他把事办成没有。

所以严格来说，HTTP 和 RPC 不是二选一的关系。RPC 是一种"调用思想"，HTTP 是一种"传输手段"。很多 RPC 框架底层就是用 HTTP 传输的，比如 gRPC 跑在 HTTP/2 上，Spring Cloud 的 OpenFeign 也是基于 HTTP。

那问题来了：既然底层都可以是 HTTP，为什么不直接手写 HTTP 调用，还要套一层 RPC 框架？

---

核心区别：你到底想要什么能力

1. 设计定位不同

HTTP 设计之初是为了浏览器和服务器之间的文档传输。它天然是面向"资源"的，URL 定位资源，GET/POST/PUT/DELETE 操作资源——这就是 RESTful 那套思想。

RPC 设计之初是为了程序与程序之间的方法调用。它天然是面向"动作"的，getUserById(123)、createOrder(orderInfo)，跟你在本地写代码的思路一模一样。

HTTP：“我要获取用户资源” → GET /users/123

RPC：“帮我查一下 ID 为 123 的用户” → userService.getUserById(123)

看出区别了吗？RPC 的思维方式更贴近业务代码的编写习惯。

2. 性能差距是真实存在的

先说结论：RPC 通常比 HTTP/1.1 快。

为什么？

第一，序列化方式不同。HTTP/1.1 传 JSON 是常态，文本格式，可读性好但体积大、解析慢。RPC 一般用 Protobuf、Thrift 这类二进制序列化协议，数据体积小，解析速度飞快。

第二，HTTP/1.1 有个著名的"队头阻塞"问题——同一个连接上，上一个请求没处理完，下一个就得等着。虽然浏览器用多连接缓解了这个问题，但在微服务高并发场景下，这就是实实在在的性能损耗。

RPC 框架通常会基于 HTTP/2.0 做多路复用，一个连接上可以同时跑多个请求，彻底解决了队头阻塞。

当然，你可能会说：“那 HTTP/2.0 也有多路复用啊，直接用 HTTP/2.0 不就行了？”

理论上可以。但 HTTP/2.0 出现得晚了（2015 年才正式发布），而 RPC 生态（Dubbo 2011 年就开源了，gRPC 2016 年）在它之前就已经在企业内部大规模使用了。历史惯性和生态成熟度摆在那里，不是说换就换的。

3. 传输层灵活度不一样

HTTP/1.1 和 HTTP/2.0 底层只能跑在 TCP 上，没得选。

RPC 框架就灵活多了。gRPC 基于 HTTP/2.0，Dubbo 默认走 TCP 但可以切 HTTP，Thrift 支持 TCP/HTTP/甚至自定义协议。

这意味着 RPC 框架可以根据场景选择最优的传输方式——内网环境追求极致性能就走 TCP 二进制协议，需要跨语言跨网络就走 HTTP/2.0。

---

历史分工：B/S vs C/S

这是个有意思的历史视角。

以前大家习惯这么划分：

• HTTP → B/S 架构（Browser/Server），浏览器访问网页，天然就是 HTTP。
• RPC → C/S 架构（Client/Server），APP 客户端跟后端服务通信，自己定协议，RPC 更灵活。

现在这个边界已经模糊了。浏览器也能通过 gRPC-Web 调 RPC，后端 Go 服务也能暴露 HTTP 接口。但在微服务内部通信这个场景下，RPC 依然是绝对主流。

---

现在的实际玩法：对外 HTTP，对内 RPC

这才是重点。现代大型系统的架构基本长这样：

浏览器 / APP
    │
    ▼
┌──────────────┐
│  API 网关     │  ← 对外暴露 HTTP/REST
└──────┬───────┘
       │
  ┌────┴────┐
  ▼         ▼
┌─────┐  ┌─────┐
│用户  │  │订单  │  ← 微服务之间用 RPC 通信
│服务  │◄─┤服务  │     (gRPC / Dubbo / OpenFeign)
└─────┘  └─────┘

对外用 HTTP：浏览器只认这个，而且 RESTful 接口对前端友好，文档好写，调试方便。

对内用 RPC：性能高、调用方便、服务治理能力强（负载均衡、熔断、限流，Dubbo 这些东西都是标配）。

---

一张表总结

	HTTP	RPC
本质	应用层传输协议	远程调用思想/框架
面向	资源（RESTful）	动作（方法调用）
数据格式	通常是 JSON/XML（文本）	通常是 Protobuf/Thrift（二进制）
性能	HTTP/1.1 有队头阻塞	更高效，多路复用
底层传输	仅 TCP	TCP / UDP / HTTP / 自定义
代表实现	—	gRPC、Dubbo、Thrift、OpenFeign
典型场景	浏览器-服务器、对外 API	微服务内部通信

---

最后

HTTP 和 RPC 不是对立的，甚至不应该拿来比较，但是面试官就是会问这个问题。

HTTP 负责搞定外部世界——浏览器、第三方、开放 API，它是互联网的通用语言。

RPC 负责搞定内部世界——微服务之间高性能、低心智负担地互相调用，它是分布式系统的神经系统。

理解了这层关系，以后面试再被问到这个问题，你心里就有底了。

---

我是小饼干，专注写点我们都看得懂的技术内容。觉得有用的话，点个赞再走。