一、粘包拆包现象演示

说实话，我第一次遇到粘包问题的时候，整个人是懵的。

那会儿我刚转做网络编程，写了个简单的客户端发数据，服务端收数据。客户端明明发了三次数据，服务端却只收到两次——而且数据还混在一起。我当时第一反应是：是不是我代码写错了？

排查了半天，最后发现，嗯，不是代码的问题。是TCP自己的“脾气”。

今天我们就通过两个实际案例，把粘包和拆包这两个现象彻底讲清楚。

案例一：短连接连续发送

先看一个最简单的场景。

客户端连续发送三条消息：

// 客户端代码片段
socket.send("Hello");
socket.send("World");
socket.send("TCP");

服务端接收时，你以为会收到三条独立的消息：

收到: Hello
收到: World
收到: TCP

但实际上，服务端可能只收到一条：

收到: HelloWorldTCP

这就是典型的粘包——多个数据包粘在了一起。

为什么会这样？

因为TCP内部有个Nagle算法。这个算法会把多个小数据包合并成一个大的数据包再发送。目的是提高网络利用率。你想想看，如果每个字节都单独发一个包，那网络开销得多大？

我在项目中遇到过类似的情况。有一次做支付网关，客户端发送订单信息，每次发送的数据量都很小。结果服务端收到的数据经常粘在一起，导致解析失败。后来排查才发现，就是Nagle算法在“捣乱”。

案例二：长连接粘包

短连接的问题相对好理解。长连接场景下，粘包问题会更隐蔽。

看这个例子：

// 长连接场景
// 客户端连续发送
socket.send("第一条消息");
Thread.sleep(10);  // 间隔10ms
socket.send("第二条消息");
Thread.sleep(5);   // 间隔5ms
socket.send("第三条消息");

服务端接收到的数据可能是这样的：

第一次读取: "第一条消息第二条消息"
第二次读取: "第三条消息"

或者这样：

第一次读取: "第一条消息"
第二次读取: "第二条消息第三条消息"

甚至这样：

第一次读取: "第一条消息第二条"
第二次读取: "消息第三条消息"

最后这种情况，就是拆包——一条完整的消息被拆成了两半。

我曾经在一个即时通讯项目中遇到过拆包问题。客户端发送的消息体比较大（几KB），服务端用固定缓冲区读取，结果一条消息被拆成了3段。那段代码我调试了整整一个下午，最后发现是TCP的MSS（最大报文段长度）限制导致的。

粘包拆包的本质

说了这么多，我们来总结一下本质原因。

TCP是一个流式协议。它没有消息边界的概念。

你发送的：

• 应用层视角：消息A、消息B、消息C
• TCP层视角：字节流 [A的字节][B的字节][C的字节]

你接收的：

• 应用层视角：不知道从哪里切分
• TCP层视角：连续的字节流

说白了，TCP只保证两件事：

1. 字节顺序不变
2. 字节不丢失

但它不保证：

1. 发送几次，接收就几次
2. 每次接收的数据长度等于发送的数据长度

知识体系总览

下面这张图，把粘包拆包的核心知识点串了起来：

小结

粘包和拆包，说白了就是TCP流式传输带来的“副作用”。

你发送的是消息，TCP传输的是字节流。这两者之间的鸿沟，就是我们需要解决的问题。

我曾经带过一个新人，他写网络通信代码时，总是假设“发一次收一次”。结果上线第一天就出了生产事故。从那以后，我要求团队所有人在写TCP代码时，第一行注释必须是：“TCP不保证消息边界”。

嗯，这个习惯，我建议你也养成。