本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
有不少程序员都说 http 比 rpc 慢，但是 Spring Cloud 还是有不少选择 http 的。这看起来好像是不合常理，但实际上 http 并不是完全没有优势的。
http 虽然“慢”，尤其是感官上会觉得比 rpc 慢很多倍，但微服务里 http 用的还是最多的。
今天群里还有人再讨论，我发现在微服务架构里，服务间通信用 HTTP 还是 RPC？应该是一个经久不衰的争论话题。有人说 HTTP 简单通用，有人说 RPC 性能碾压。
我两边都不占，不谈立场，今天就摆数据，给大家看看一些公开压测结果，包括 gRPC vs REST、Dubbo 官方 Benchmark、HTTP/1.1 vs HTTP/2 等，彻底搞懂HTTP 到底比 RPC 慢多少？慢在哪？以及你的业务真的需要纠结这个吗？
我们到底在比什么？
讨论之前，先对齐口径，否则就是鸡同鸭讲。
日常口语中的 HTTP 和 RPC，实际指代的是两套具体的技术组合。
- HTTP 阵营：HTTP 协议 + JSON 序列化（典型代表有 Spring Cloud OpenFeign / RestTemplate 等）
- RPC 阵营：TCP 私有协议或 HTTP/2 + 二进制序列化（典型代表有 Dubbo、gRPC 等）
所以 HTTP 比 RPC 慢这句话，准确的说法应该是 HTTP/1.1 + JSON 这套组合，比二进制协议 + Protobuf 慢多少。记住这个口径，我们后面所有的数据都建立在这个基础上。
数据说话
下面我们通过网上公开的 6 组压测结果进行横向对比。
gRPC vs REST
先说结论，gRPC vs REST 吞吐量差一倍，延迟差一半。
第一组数据来自 markaicode.com 2025 年的基准测试（gRPC + Protobuf vs REST + JSON）。
吞吐量对比如下所示。
| 场景 | gRPC + Protobuf | REST + JSON | gRPC 领先幅度 |
|---|---|---|---|
| 小消息体 | 25,800 req/s | 12,450 req/s | 107% |
| 1MB 大消息体 | 2,350 req/s | 1,250 req/s | 88% |
延迟对比如下所示。
| 指标 | gRPC | REST | REST 多出来的延迟 |
|---|---|---|---|
| 平均延迟（小消息） | 12.8ms | 24.5ms | +11.7ms |
| P99 延迟（小消息） | 29ms | 56ms | +27ms |
| 平均延迟（1MB） | 98ms | 175ms | +77ms |
| P99 延迟（1MB） | 185ms | 325ms | +140ms |
资源消耗对比如下所示。
| 指标 | gRPC | REST | 差距 |
|---|---|---|---|
| CPU 占用 | 58% | 72% | REST 高 19% |
| 内存占用 | 2.5GB | 3.8GB | REST 高 34% |
| 网络带宽 | 0.86 Gbps | 1.45 Gbps | REST 高 41% |
看完这组数据，结论应该很容易得出了，gRPC 在吞吐量上大约是 REST 的 2 倍，延迟低接近一半，资源消耗全面占优。Protobuf 序列化后的消息体积比 JSON 小 60%-80%，这个差距在大消息场景下会被进一步放大。
100 并发下 RPS 提升 140%
另一个实测数据来自于 CSDN 博主 2025 年 10 月在 Python 环境下用 wrk 做的实测（Flask REST vs gRPC），结果显示 gRPC 平均延迟 19.5ms、RPS 5,120，REST 平均延迟 48.2ms、RPS 2076。gRPC 的 RPS 提升超过 140%，CPU 反而更低（54% vs 67%）。这与第一组数据相互印证。
Dubbo 官方 Benchmark
国内 Java 圈绕不开 Dubbo。Dubbo 官方文档中有一组非常有代表性的 RPC 协议基准测试（Dubbo 3.0，POJO 返回值场景）。Dubbo + Hessian2 达到 12,279 ops/s（P99 5.7ms），而同样基于 Protobuf 的 Triple（HTTP/2）为 6255 ops/s（P99 8.9ms）。
文章配图参见我的公众号文章：https://mp.weixin.qq.com/s/OPD5jtkLjcHZejWGECAIkA。
可以说是 TCP 私有协议依然很能打，这其中也有两个有意思的发现。
- Dubbo 私有 TCP 协议的性能依然是最强的。固定头的二进制协议，在纯 Java 点对点调用场景下优势巨大。
- 同样是 HTTP/2 + Protobuf，Triple 点对点调用反而明显慢于 Dubbo 私有协议。Dubbo 官方自己也承认，单纯看点对点调用，基于 HTTP/2 的协议对比基于 TCP 的协议处于劣势，Triple 的优势在于网关穿透性、通用性和 Stream 流式通信。
说白了，上了 RPC 框架不等于性能就一定好，协议实现细节同样关键。
HTTP/1.1 vs HTTP/2
协议版本不同，竟然能带来 45% 吞吐提升。
慢的部分到底有多少是 HTTP/1.1 的锅？一组实测数据显示，HTTP/2 的吞吐量比 HTTP/1.1 高约 45%，延迟低约 31%（HTTP/1.1 约 55,760 req/s、3.59ms，HTTP/2 约 81,153 req/s、2.46ms）。有开发者模拟 50ms 网络延迟做过对比，HTTP/1.1 加载耗时 3.53s，HTTP/2 只要 1.73s，差距接近一倍。
HTTP/2 解决了 HTTP/1.1 的三大痛点。二进制分帧取代文本头、多路复用解决队头阻塞、HPACK 头部压缩（头部体积可减少 50%-90%）。
序列化的单独对比
很多人把性能差的锅甩给 HTTP 协议本身，其实大头是 JSON 序列化。
同一个数据结构，JSON 序列化后约 1000 字节，Protobuf 序列化后约 200-400 字节，体积差 2-5 倍；序列化速度根据数据结构不同，Protobuf 通常比 JSON 快 2-10 倍不等。
Dubbo 生态的序列化对比数据（复杂嵌套对象）也很能说明问题，Kryo 响应仅 90 字节、TPS 8444；而 Dubbo 默认的 Hessian2 响应 329 字节、TPS 6701。同样是二进制协议，换个序列化实现，TPS 就能差出 20% 以上。性能优化是连环扣，不是单选题。
一个反直觉的数据
也不是所有数据都一边倒。有 .NET 生态的测试显示，当接口返回的数据量比较小时，REST 的性能甚至可能比 gRPC 略好；数据量变大之后，gRPC 的优势才明显起来。
这提醒我们，压测数据高度依赖场景，消息体小的时候，REST 未必输。脱离消息大小、并发度、链路长度谈优劣，都是耍流氓。
你的业务感知得到这 15% 吗？
上面列的这些数据都是极端压测场景下的结果。现在请回到你的实际业务算一笔账。
一个普通的接口请求，数据库查询花了 30ms，业务逻辑处理花了 20ms，HTTP 通信本身耗时约 24ms，总耗时约 74ms。如果换成 gRPC，通信耗时降到约 13ms，总耗时变成 63ms，省下来的 11ms，占总耗时约 15%。
这 15% 的差距，用户能感知到吗？很大概率感知不到吧。
这就是为什么很多用 OpenFeign 的团队，线上跑得好好的，没觉得有什么性能问题。因为通信协议从来就不是他们的瓶颈，有团队实测过，以 HTTP 做远程调用，5000 QPS 的压测目标可以顺利达成，瓶颈自然下沉到数据库查询，而不是协议本身。
但如果你的场景是下面这几种，通信协议的差距就会被放大，这时候确实该认真考虑二进制协议。
- 调用链很长。一个请求串 7、8 个服务，每次省 10ms，全链路就是百毫秒级
- 调用频率极高。QPS 几万起步，吞吐量和 CPU/内存成本的差距会线性放大
- 消息体很大。大对象传输，JSON 的体积膨胀和序列化开销急剧上升
- 网络环境差。移动端、IoT、跨机房调用，带宽受限时小体积报文是硬优势
所以，具体选谁，还要结合着看业务场景。
HTTP 到底慢在哪？
笼统地说 HTTP 慢确实不准确。慢的不是 HTTP 这四个字母，而是 HTTP/1.1 + JSON 组合在三个具体环节上的开销。
文本协议头 vs 二进制协议头
HTTP/1.1 的请求头是纯文本的，如下所示。
GET /api/user/123 HTTP/1.1
Host: user-service
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...每一次请求都要带上这堆文本头，服务端还要逐字符解析。一个典型的 HTTP 请求头大约 300-800 字节。而 Dubbo 协议的请求头是固定 16 字节的二进制格式，解析快、体积小。gRPC 基于 HTTP/2，用二进制帧 + HPACK 压缩，这块开销也小得多。单次差距不大，高并发下会积累。
JSON 序列化
序列化才是真正的性能大头。
前面的数据已经说明问题了。JSON 是文本格式，序列化和反序列化都要做字符串解析和内存分配。Hessian2 是不错的折中方案：二进制格式、不需要 IDL 定义、Java 生态开箱即用，性能介于 JSON 和 Protobuf 之间，这也是 Dubbo 把它作为默认序列化的原因。
连接管理
HTTP/1.1 的队头阻塞是硬伤。
HTTP/1.1 虽然支持 Keep-Alive，但一个连接同一时间只能处理一个请求（队头阻塞）。想并发发 10 个请求，就得建 10 个连接。而 Dubbo 的 TCP 协议一个连接上可以同时跑多个请求，通过 requestId 匹配请求和响应；gRPC 基于 HTTP/2 也支持多路复用，一个连接并行处理多个流，连接利用率高得多。
gRPC 用的也是 HTTP
很多人讨论 HTTP 慢还是 RPC 快 时，把 HTTP 和 RPC 当成两个对立的东西。
但你仔细想想，再想想，仔细品品。
- gRPC 用的传输协议是什么？HTTP/2。
- gRPC 做的核心优化是什么？Protobuf 序列化 + 多路复用。
所以 gRPC 本质上就是帮你选好了一套 HTTP/2 + Protobuf + 多路复用的最佳实践组合。它并没有绕开 HTTP，它只是用了更好版本的 HTTP，配了更高效的序列化方式。
换句话说，如果你在 Spring Cloud 里也切到 HTTP/2（比如 WebFlux + Netty），再把 JSON 换成 Protobuf，性能跟 gRPC 已经差不了多少了。这个问题真正的答案不是 HTTP 慢，而是 HTTP/1.1 + JSON 这个特定组合慢。
协议版本和序列化方式才是决定性能的关键变量，不是 HTTP 这四个字母。
搞清楚了这一层，你在做技术选型的时候就不会被 HTTP 慢这个简单结论误导了。
结语
所以，HTTP 到底比 RPC 慢多少？
哎，数据层面的答案是，吞吐量差 1-2 倍，延迟差 30%-50%，在压测场景下资源消耗差 20%-40%。
工程层面的答案是，慢的是 HTTP/1.1 + JSON，不是 HTTP；而且这个差距在大多数业务里被数据库和业务逻辑的开销淹没了，根本感知不到。真正值得做的，是先用监控找到真实瓶颈，再决定要不要为协议升级买单。
技术选型没有银弹，只有场景。千万别让二选一的思维，限制了你的架构！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » HTTP 到底比 RPC 慢？慢多少？