为什么 RPC 要比 HTTP 更快？我：之前项目只用过 HTTP...

面试考察点协议理解深度面试官不仅仅是想知道 RPC 比 HTTP 快更是想知道你是否理解 HTTP/1.1 的协议开销Header 冗余、文本格式编码以及 RPC 框架在协议层做了哪些精简。序列化机制认知考察你是否清楚 JSON/XML 这类文本序列化方式与 Protobuf、Hessian 等二进制序列化的性能差距以及背后的原因。连接管理意识看你是否了解长连接复用、连接池管理对性能的影响以及 HTTP 短连接模型的固有开销。工程辨析能力一个加分项——能否客观地说出 RPC 不一定总是比 HTTP 快比如 HTTP/2 和 gRPC 的出现已经大幅缩小了这个差距。核心答案先说结论RPC 之所以比传统 HTTP特指 HTTP/1.1 JSON更快核心原因有4 个。维度HTTP/1.1 JSONRPCDubbo/gRPC 等性能差距协议格式文本协议Header 臃肿自定义二进制协议精简高效报文体积差距 3~10 倍序列化方式JSON文本Protobuf/Hessian二进制序列化速度差距 5~20 倍连接模型短连接为主 / Keep-Alive 有限复用长连接 连接池减少 TCP 握手开销网络模型BIO/NIO 混用NIO/Epoll 优化的 Netty高并发吞吐量差距明显下面一个个拆开讲。深度解析一、协议格式报文 臃肿 vs 精瘦HTTP/1.1 的报文头是纯文本的每次请求都要携带一大堆 Header 信息。来看个直观的例子img上图展示了 HTTP 和 RPC 在报文结构上的核心差异。关键点HTTP/1.1 的 Header 是文本格式每次请求都要带上Content-Type、User-Agent、Accept等一堆跟业务无关的信息。这些 Header 在内部服务调用中完全多余但协议规定必须解析。Dubbo 的协议头只有固定的 16 字节Magic Number Flag Status Request ID Data Length极其精简。没有废话全是干货。实际场景中一个简单的 HTTP 接口调用Header 可能就占了 300~800 字节而 RPC 协议头只有 16 字节。在高频调用下这个差距会被无限放大。二、序列化文本 vs 二进制这是性能差距最大的一块。HTTP 最常用的序列化格式是 JSON而 RPC 框架通常使用二进制序列化Protobuf、Hessian、Kryo 等。两者差距在哪img上图直观展示了 JSON 和 Protobuf 在序列化后的数据差异。核心原因有三点字段名冗余JSON 每次都要把字段名id、name完整地传一遍而 Protobuf 用字段编号1、2代替接收端通过.proto文件反序列化时再映射回字段名。数据量直接砍半。类型编码低效JSON 中数字12345按 ASCII 字符存储占 5 字节。Protobuf 用 Varint变长整数编码只占 3 字节。整数越大差距越明显。格式符号冗余JSON 的{}、、:、,这些格式符号在二进制协议中全部可以省略用 Tag-Length-ValueTLV结构替代。实际压测数据参考序列化方式序列化耗时反序列化耗时数据大小JSONJackson~5ms~8ms100%Hessian2~3ms~4ms~60%Protobuf~1ms~1.5ms~30%Kryo~0.8ms~1ms~35%“以上数据为同一条复杂对象 10 万次序列化的参考值实际数值取决于数据结构和运行环境。三、连接模型短连接开销 vs 长连接复用HTTP/1.1 默认虽然支持Keep-Alive但在实际使用中很多客户端尤其浏览器连接复用效率并不高。而 RPC 框架天生就是基于长连接设计的。img上图对比了三种连接模型。重点说说 RPC 的优势TCP 连接建立开销一次 TCP 三次握手需要 1.5 个 RTTRound-Trip Time如果走 TLS 还要额外 2 个 RTT。在同机房 RTT 约 0.5ms跨机房可能 5~30ms。高频短连接场景下这个开销非常可观。RPC 框架直接基于 Netty 做 NIO 多路复用一个 TCP 连接上可以同时跑多个请求通过 Request ID 做关联互不阻塞。Dubbo 还支持连接池和多连接可以根据并发量动态调整。默认情况下消费者与每个提供者建立单个长连接对于高并发场景可以配置多个连接。四、网络模型BIO vs NIO这个维度很多人会忽略。传统的 HTTP 服务比如早期的 Servlet 容器多采用 一请求一线程 的 BIO 模型并发量大的时候线程数暴涨上下文切换开销巨大。而主流 RPC 框架Dubbo、gRPC底层都是基于Netty的 NIO 模型少量线程通常等于 CPU 核心数即可处理大量并发连接基于 Linuxepoll的 IO 多路复用单线程可以同时监听数千个连接避免了线程上下文切换和锁竞争的开销说白了网络模型决定了 天花板 有多高。协议再精简如果每个请求都占用一个线程并发一上去照样扛不住。五、一个容易被忽略的点——RPC 框架的 额外优化除了上面 4 个核心差异成熟的 RPC 框架还做了一些 HTTP 原生不提供的优化服务发现RPC 框架内置注册中心Nacos、ZooKeeper自动感知服务上下线HTTP 需要额外引入负载均衡组件智能路由基于权重、一致性哈希、同机房优先等策略的流量调度熔断降级集成 Sentinel、Hystrix 等组件快速失败泛化调用不需要客户端 SDK直接传参调接口这些不算 速度 上的优势但它们让 RPC 在微服务架构中的整体效率远高于裸 HTTP 调用。常见误区误区HTTP 一定比 RPC 慢。这个说法已经过时了。HTTP/2 引入了二进制分帧、多路复用、Header 压缩HPACK性能大幅提升。gRPC 更是直接基于 HTTP/2 Protobuf性能已经非常接近传统 RPC 框架。所以更准确的说法是RPC自定义协议比 HTTP/1.1 JSON 快但 HTTP/2 Protobuf 的性能已经和传统 RPC 不相上下了。面试高频追问追问一既然 RPC 这么好为什么还要用 HTTPHTTP 的优势在于通用性和生态。浏览器原生支持 HTTPAPI 网关、CDN、防火墙都围绕 HTTP 协议工作。对外暴露的 APIOpenAPI、移动端接口几乎都用 HTTP对内微服务间调用才用 RPC。这也是为什么很多公司采用 外 HTTP 内 RPC 的架构。追问二gRPC 算 RPC 还是 HTTPgRPC 是基于 HTTP/2 的 RPC 框架。它用 HTTP/2 做传输层用 Protobuf 做序列化兼具了 HTTP 的通用性和 RPC 的高性能。所以说HTTP 和 RPC 并不是对立的gRPC 就是两者结合的产物。追问三Dubbo 和 Spring CloudOpenFeign的性能差距大吗Dubbo 使用自定义 TCP 协议 Hessian2/Protobuf 序列化OpenFeign 本质是 HTTP JSON。在同样的硬件条件下Dubbo 的吞吐量通常是 OpenFeign 的 2~5 倍延迟也低 30%~50%。不过 Spring Cloud 6 已经开始支持 gRPC差距在缩小。常见面试变体变体一HTTP 和 RPC 的本质区别是什么变体二为什么微服务内部调用推荐用 RPC 而不是 HTTP变体三gRPC 和 Dubbo 性能上有什么差异变体四什么场景只能用 HTTP不能用 RPC记忆口诀RPC 快的四个字精、二、长、N精协议精简16 字节头部 vs 几百字节 HTTP Header二二进制序列化体积小、速度快长长连接复用省去 TCP 握手开销NNIO 网络模型少量线程扛高并发总结一句话RPC 比传统 HTTP/1.1 快核心在于协议更精简、序列化更高效、连接复用更好、网络模型更优秀。但别忘了HTTP/2 gRPC 已经在缩小这个差距面试时千万别说 HTTP 就是比 RPC 慢要说清是 HTTP/1.1 JSON vs 自定义协议 二进制序列化 的差异这才是面试官想听的。