Published on

有了TCP为什么还需要HTTP？再用RPC？这次彻底讲明白了

Authors
  • avatar
    Name
    Terry
    Twitter

从网络基础说起：TCP的能力与局限

刚开始接触网络编程时，我觉得TCP已经足够完美——它能够建立稳定的连接、保证数据可靠传输、处理网络拥塞，这似乎就是网络通信的全部需求。

但在实际开发中，我遇到了一个基础却关键的问题：

// 发送方连续发送两条独立消息
socket.write('Hello')
socket.write('World')

// 接收方可能一次收到："HelloWorld"
// 完全无法区分原始的消息边界

这就是TCP粘包问题的典型体现。TCP基于字节流的特性意味着它只负责可靠地传输字节序列，却不关心这些字节应该如何被组织成有意义的业务消息。

TCP的三个核心特性：

  1. 面向连接：通信前需要通过三次握手建立连接
  2. 可靠传输：通过确认、重传、排序等机制保证数据可靠送达
  3. 基于字节流：数据没有自然边界，只是连续的字节序列（二进制）

个人理解： TCP就像是一个可靠的物流系统，保证把所有的货物都送达，但把所有包裹混在一起投递——货物确实都到了，但接收方需要自己重新分类整理。

HTTP协议的出现：为数据赋予意义

面对TCP的局限性，应用层协议应运而生。HTTP协议通过在TCP之上定义明确的报文格式，解决了消息边界和语义表达的问题。

HTTP通过标准的报文结构定义消息边界：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 48

{"name": "Alice", "email": "alice@example.com"}

关键就在于Content-Length: 48这个头部——它明确告诉接收方消息体的确切长度，从而解决了TCP的粘包问题。

HTTP协议的主要价值：

  1. 定义消息边界：通过Content-Length或chunked编码标识消息范围
  2. 标准化通信语义：GET、POST、PUT、DELETE等标准方法
  3. 丰富的能力扩展：缓存控制、内容协商、状态管理
  4. 通用兼容性：被所有主流平台和语言支持

结论： TCP解决了"可靠传输"的问题，而HTTP等应用层协议解决了"传输什么"和"如何解析"的问题。

新的困惑：为什么要在HTTP之上再引入RPC？

随着分布式系统的发展，大家都能发现基于HTTP的服务间调用会存在一些不便：

// 基于HTTP的服务调用需要大量样板代码
HttpClient client = HttpClients.createDefault();
HttpPost post = new HttpPost("http://user-service/getUser");
post.setHeader("Content-Type", "application/json");

String jsonBody = "{\"user_id\": 123}";
post.setEntity(new StringEntity(jsonBody));

HttpResponse response = client.execute(post);
if (response.getStatusLine().getStatusCode() == 200) {
    String responseBody = EntityUtils.toString(response.getEntity());
    User user = objectMapper.readValue(responseBody, User.class);
}
// 太多的底层细节需要处理！

每次调用都需要处理HTTP状态码、异常情况、序列化反序列化等重复工作。这让我们开始思考：能否让远程服务调用像调用本地方法一样简单？

RPC的核心理念：透明化的远程调用

RPC（Remote Procedure Call），又叫做远程过程调用，其目标就是让远程服务调用对开发者透明。

// 理想的RPC调用方式
User user = userService.getUser(123);

// 而不是处理各种网络通信细节

重要概念澄清（基于个人理解）：

RPC本身不是具体的协议，而是一种调用范式或技术思想。 它的核心目标是让程序员能够像调用本地方法那样调用远程服务。

但是我们不能说"使用RPC协议"，因为RPC本身不是协议。正确的表述方式：

  • ✅ "我们使用gRPC协议进行RPC调用"
  • ❌ "我们使用RPC协议"

因为RPC本身不是协议，而gRPC、Thrift、Dubbo等才是具体的协议实现。

RPC与HTTP的关系：不同维度的技术

RPC与HTTP的关系

这是最容易产生混淆的地方。通过学习和实践，我个人理解为：

RPC和HTTP根本不在同一个技术层级：

  • RPC是一种调用范式，对标的是本地方法调用
  • HTTP是一种具体的应用层协议
  • RPC可以通过HTTP实现，也可以通过自定义的TCP或UDP协议实现

比如gRPC选择基于HTTP/2协议实现，而很多早期的RPC框架使用自定义的TCP二进制协议。

RPC协议与RPC框架的完整生态

RPC协议：通信的基础规范

协议主要定义三个核心方面：

  1. 消息格式：定义消息如何开始、结束，头部和体部的结构
  2. 序列化方式：规定数据如何编码和解码
  3. 传输规则：确定通信流程和交互模式

RPC框架：基于协议的完整解决方案

现代RPC框架在基础协议之上提供了企业级的能力：

  • 核心层：实现通信协议本身
  • 组件层：提供序列化、服务发现、负载均衡等基础组件
  • 治理层：包含容错、监控、注册中心等运维能力
  • 应用层：让开发者透明地进行远程方法调用

总结： 协议定义了机器之间如何对话，框架让开发者无需关心对话过程而专注业务逻辑。

现代架构中的技术选型：各司其职的分工

通过参与实际项目，我逐渐理解了HTTP和RPC在现代架构中的分工原则。针对大部分公司而言，基本上都是如此。

内部服务调用：RPC框架的优势领域

在微服务架构内部，RPC框架因其性能优势成为首选：

RPC的高性能主要源于：

高效的序列化

// JSON序列化：可读性好但体积大
{"id": 123, "name": "Alice", "age": 30}  // 约40字节

// Protobuf二进制：体积小，解析快
\x08\x7B\x12\x05Alice\x18\x1E  // 仅11字节
// 体积减少70%以上，序列化速度提升明显

协议开销优化

  • 长连接减少TCP握手开销
  • 多路复用提升连接利用率
  • 头部压缩减少传输数据量

专为性能设计

  • 精简的协议头设计
  • 二进制编码效率
  • 零拷贝等技术应用

对外API暴露：HTTP协议的不可替代性

当需要向外部提供API时，HTTP协议展现出其独特价值：

HTTP的通用性优势：

  1. 无与伦比的生态系统：所有平台、语言、设备都支持H *成熟的工具链**：浏览器、Postman、curl等调试工具
  2. 网络友好性：80/443端口普遍开放
  3. 易于测试调试：直接通过浏览器或命令行工具测试
// 前端调用HTTP API简单直接
fetch('/api/users/123')
  .then((response) => response.json())
  .then((user) => {
    displayUser(user)
  })

真实世界的架构实践

现代互联网公司的典型架构体现了清晰的分层设计：

前端应用 ←→ HTTP/HTTPS ←→ API网关 ←→ RPC ←→ 微服务集群
   ↓                        ↓              ↓
浏览器/移动端              负载均衡        服务注册中心
                         认证授权         配置中心
                         限流熔断         监控告警

这种架构的智慧：

  1. 内外有别：对外保证兼容性，对内追求性能
  2. 关注点分离：网关处理横切关注点，业务服务专注核心逻辑
  3. 协议转换：在网关层完成HTTP到RPC的协议转换

总结与核心观点

针对文章内容，整体总结一下：

技术演进脉络：

  1. TCP层：解决网络层的可靠传输问题
  2. HTTP层：解决应用层的消息格式和语义问题
  3. RPC层：优化分布式系统的服务调用体验

现代架构的最佳实践：

公司内部服务调用：优先采用RPC框架（如gRPC、Dubbo）

  • 核心原因：极致性能。二进制编码、协议开销低、长连接复用

对外暴露接口：普遍采用HTTP协议（及RESTful风格）

  • 核心原因：无与伦比的通用性。生态系统成熟，客户端兼容性好

核心结论：

这是一个"内外有别"的最佳实践——性能至上的内部集群采用RPC框架，兼容性优先的对外开放接口采用HTTP协议。

Discuss on Twitter • View on GitHub