一、粘包拆包问题概述

1.1 什么是粘包和拆包？

先问大家一个问题：你用 TCP 发了两条消息，接收方收到的是几条？

很多人会脱口而出：两条啊。但实际开发中，你收到的可能是一条、三条，甚至是一条半。这就是粘包和拆包。

粘包，说白了就是发送方发了多个小数据包，接收方一次全收走了，几个包粘在一起。我在项目中遇到过最典型的场景：客户端连续发了 3 条 JSON 消息，服务端 recv 一次就全读出来了，结果 JSON 解析直接报错——因为三个 JSON 对象连在一起，根本没法解析。

拆包正好相反。你发了一个大包，TCP 把它切成了好几段，接收方分几次才能收完。我记得有一次调试文件传输协议，发送方一次发了 64KB 数据，接收方每次只读到 1460 字节左右，循环了 40 多次才收全。嗯，这就是拆包。

你想想看，这两个问题本质上是一个硬币的两面。根源都在于 TCP 是流式协议，它不关心你的消息边界。

1.2 为什么 TCP 是流式协议？

这个问题我面试过很多人，能答到点子上的不多。

TCP 的设计初衷是可靠传输，不是消息边界保护。它只保证两件事：数据按顺序到达、数据不丢失。至于你发的是几条消息，TCP 根本不 care。

来看一个直观的例子：

// 发送方连续发送两个数据包
send(sock, "Hello", 5, 0);
send(sock, "World", 5, 0);

// 接收方可能一次性收到
recv(sock, buf, 10, 0);  // buf = "HelloWorld"  → 粘包

// 也可能分两次收到
recv(sock, buf, 3, 0);   // buf = "Hel"          → 拆包
recv(sock, buf, 7, 0);   // buf = "loWorld"

为什么会这样？因为 TCP 底层用的是滑动窗口 + 拥塞控制。发送方发出去的数据，先进入发送缓冲区。TCP 协议栈会根据网络状况、接收窗口大小等因素，决定什么时候发、发多少。接收方也一样，应用层调用 recv 时，协议栈把缓冲区里已有的数据交给你，有多少给多少。

我个人习惯把 TCP 想象成一根水管。你往水管里倒水（发送数据），对方在水管另一头接水（接收数据）。水管不会记住你倒了几次，它只管把水送过去。你倒一次 10 毫升，对方可能一次接走 10 毫升；你连续倒三次，对方可能一次接走 30 毫升。这就是流式协议的本质。

1.3 粘包拆包对应用层的影响

这个问题很实际。粘包拆包不是 TCP 的 bug，它是 TCP 的特性。但如果你在应用层不做处理，后果很严重。

我总结了一下，主要有三类影响：

影响类型	具体表现	典型场景
数据解析错误	消息边界错乱，解析出非法数据	JSON/XML 协议、自定义二进制协议
业务逻辑异常	指令被拆分或合并，导致逻辑错乱	即时通讯、游戏协议、RPC 调用
性能下降	频繁的 recv 循环或缓冲区溢出	大文件传输、流媒体、日志采集

数据解析错误是最直接的。你发了一个完整的 JSON 对象，接收方只收到一半，JSON 解析器直接抛异常。或者你发了两个 JSON 对象，接收方收到一个拼接体，解析同样失败。我在做物联网网关项目时就踩过这个坑——设备上报的数据包被粘在一起，服务端解析全部失败，整整丢了 3 个小时的数据。

业务逻辑异常更隐蔽。比如你设计了一个协议：前 4 字节是消息长度，后面是消息体。如果发生拆包，你只收到前 2 个字节，长度字段都不完整，后续所有解析都会错位。我记得有一次调试金融交易系统，就是因为拆包导致消息长度字段被截断，服务端读到一个巨大的非法长度值，直接申请了 2GB 内存，系统 OOM 崩溃。

性能下降容易被忽视。拆包意味着你需要多次 recv 才能拼凑出一条完整消息。如果每次 recv 只读到几十个字节，而你的消息体有几十 KB，那循环次数会非常可观。我在优化一个视频流服务时发现，因为没做粘包处理，服务端每次 recv 只读到 100-200 字节，CPU 全耗在系统调用上了。加上简单的消息边界处理后，系统调用次数减少了 90% 以上。

1.4 本章知识体系

下面这张图可以帮你快速建立本章的知识框架：

从这张图可以看得很清楚：粘包拆包的根源在 TCP 流式特性，表现形式是边界丢失，影响覆盖了解析、逻辑和性能三个层面。而解决方案的核心思路只有一个——在应用层定义消息边界。

后面的章节，我会带着大家逐一深入这些解决方案，从最简单的固定长度协议，到最常用的长度字段法，再到高性能的 Netty 框架实现。每个方案我都会结合自己踩过的坑来讲，希望能帮你少走弯路。