HTTP 与 RPC 之间的区别？

HTTP 与 RPC 的区别

【核心定义】

HTTP 是一种通用的应用层网络协议，主要用于 Web 通信；而 RPC（远程过程调用）是一种通信范式或架构模式，旨在让调用远程服务像调用本地方法一样简单，其底层传输协议可以是 HTTP，也可以是 TCP 等自定义协议。

【关键要点】

1. 定位与设计目标不同

   • HTTP：设计目标是通用、无状态、可缓存的 Web 资源传输协议，核心是“请求-响应”模型，面向资源（RESTful）。
   • RPC：设计目标是透明化远程调用，隐藏网络通信细节，让开发者专注于业务逻辑，面向方法/服务。

2. 协议与性能差异

   • HTTP/1.1：文本协议，头部冗余大，每次请求需建立连接（Keep-Alive 可复用），但仍有队头阻塞问题。
   • HTTP/2：二进制分帧，多路复用，头部压缩，性能大幅提升，常被现代 RPC 框架用作传输层（如 gRPC）。
   • 自定义 RPC 协议（如 Dubbo 的 dubbo 协议、Thrift）：二进制编码，报文更紧凑，序列化效率高，专为高性能服务间通信优化。

3. 序列化方式

   • HTTP + JSON/XML：文本序列化，可读性好，但体积大，解析慢。
   • RPC：通常采用高性能二进制序列化（如 Protobuf、Thrift、Hessian），编码紧凑，编解码快，节省带宽和 CPU。

4. 服务治理能力

   • HTTP：原生缺乏服务发现、负载均衡、熔断降级等能力，需依赖外部组件（如 API 网关、服务网格）。
   • RPC 框架：内置完整的服务治理体系，包括服务注册与发现、负载均衡、容错、链路追踪、监控等，开箱即用。

5. 适用场景

   • HTTP：适合跨平台、跨语言、对通用性要求高的场景，如浏览器与服务器交互、开放 API。
   • RPC：适合企业内部高性能、低延迟的服务间通信，如微服务架构中的服务调用。

【深度推导/细节】

性能差异的本质原因

• 协议开销：HTTP/1.1 的文本头部（如 Cookie、User-Agent）在服务间通信中大部分是冗余信息，而自定义 RPC 协议只传递必要元数据。
• 连接模型：HTTP/1.1 默认短连接（或 Keep-Alive 有限复用），而 RPC 框架通常维护长连接池，减少 TCP 握手和慢启动开销。
• 序列化效率：JSON 解析需字符串解析和反射，而 Protobuf 等通过预编译生成编解码代码，直接操作二进制流，效率差一个数量级。

设计哲学对比

• HTTP 是“协议约束”：遵循 REST 风格时，强调资源定位（URI）、统一接口（GET/POST/PUT/DELETE）、无状态，适合松耦合系统。
• RPC 是“接口约束”：强调方法签名（接口契约）、参数传递，耦合更紧但开发体验更自然，适合统一技术栈的微服务集群。

【关联/对比】

HTTP 与 RPC 的关系

• 不是对立关系，而是不同层次的概念：RPC 是一种架构模式，HTTP 是一种可能的传输协议。现代 RPC 框架（如 gRPC）直接基于 HTTP/2 构建，兼具 RPC 的易用性和 HTTP/2 的高性能。
• 代表性框架对比：

  特性	HTTP + REST（Spring Cloud OpenFeign）	RPC（Apache Dubbo）	gRPC
  协议	HTTP/1.1 或 HTTP/2	自定义 dubbo 协议（默认）	HTTP/2
  序列化	JSON（Jackson）	Hessian2、JSON 等	Protobuf
  服务治理	依赖 Spring Cloud 生态（Eureka、Ribbon）	内置（ZooKeeper/Nacos + 负载均衡）	依赖周边生态
  性能	中等	高	高
  跨语言	好（文本协议）	主要 Java	优秀（多语言支持）

与 TCP 自定义协议的对比

• 一些传统 RPC 框架（如早期 Dubbo）直接基于 TCP 自定义二进制协议，比 HTTP 更高效，但牺牲了通用性和可调试性（需要专用工具抓包解析）。

『面试官追问』

1. 为什么 gRPC 选择 HTTP/2 而不是自定义协议？

   • 答：HTTP/2 提供了多路复用、头部压缩、流控制等现代化特性，性能已接近自定义协议，同时保留了 HTTP 的通用性和穿透性（可穿越大多数防火墙、代理），且天然支持多语言（有标准实现）。

2. 什么情况下应该用 HTTP，什么情况下用 RPC？

   • 答：
     • 用 HTTP：需要对外提供 API（如开放平台、移动端接口）；团队技术栈异构（多种语言）；通信频率低、性能非关键。
     • 用 RPC：内部微服务调用，追求高性能、低延迟；技术栈统一（如全 Java）；需要完善的服务治理能力。

3. RESTful 和 RPC 风格在 API 设计上有什么区别？

   • 答：
     • RESTful：资源为中心，URI 表示资源（如 /users/123），HTTP 方法表示操作（GET 获取、POST 创建）。
     • RPC：动作为中心，URI 表示方法（如 /getUser 或直接方法名），参数通过请求体传递。

4. HTTP/2 能否完全取代自定义 RPC 协议？

   • 答：在大多数场景下可以，但极端性能敏感场景（如金融交易系统、游戏实时通信）可能仍需要极简的二进制自定义协议，以消除所有协议层开销，实现微秒级延迟。

5. Dubbo 为什么既支持 dubbo 协议又支持 HTTP 协议？

   • 答：灵活性适配不同场景。dubbo 协议用于内部高性能调用；HTTP 协议用于跨语言调用或穿透网关。这种多协议支持体现了 RPC 框架的演进趋势——兼顾性能和通用性。

【总结】

• 本质区别：HTTP 是协议，RPC 是模式。二者不在同一维度比较，但常以“HTTP API” vs “RPC 框架”的形式被对比。
• 选型关键：性能要求、技术栈统一性、服务治理需求、跨语言需求是核心决策因素。
• 发展趋势：随着 HTTP/2 的普及和云原生的发展，基于 HTTP/2 的 RPC（如 gRPC） 正在成为内部服务通信的主流选择，平衡了性能、通用性和可观测性。