什么是 TCP 粘包和拆包？怎么解决？

简化版

TCP 是面向字节流的，它不保留「消息边界」——你发送的多条消息，接收方可能一次读到多条（粘包），或一条消息被分几次读到（拆包）。根源是 TCP 只管传字节，不懂应用层「一条消息」的概念。解决办法是在应用层自己划定消息边界：固定长度、特殊分隔符，或最常用的消息头带长度字段。UDP 不存在这个问题（它保留数据报边界）。

详细版

什么是粘包/拆包：

粘包：发送方发了两条消息「AB」「CD」，接收方一次 read 读到「ABCD」，两条粘在一起了。
拆包：发送方发一条消息「ABCD」，接收方分两次读到「AB」和「CD」，一条被拆开了。

为什么会发生：TCP 把应用数据看成无边界的字节流，它有权：

把多个小的 write 合并成一个 TCP 段发送（Nagle 算法会攒小包）；
把一个大的 write 拆成多个 TCP 段（超过 MSS 就得拆）；
接收方 read 一次读多少，取决于当时缓冲区里有多少字节，和「消息」无关。

三种解决方案（都是在应用层加「边界」信息）：

固定长度：每条消息定长，不足补齐。简单但浪费、不灵活。
分隔符：消息之间用特殊字符分隔（如 \n、\r\n）。要处理内容里出现分隔符的转义。
消息头 + 长度字段（最常用）：消息头里写明消息体长度，接收方先读头拿到长度，再精确读这么多字节。灵活高效，是主流做法。

完整版教学

一、根源：TCP 是字节流，没有「消息」概念

理解粘包的关键，是分清 TCP 和应用视角的差异：

应用视角：我发送的是「一条条消息」，有清晰的边界。
TCP 视角：我收到的是「一堆字节」，我只保证这些字节有序、不丢、不重复地送达，但我不知道也不关心哪几个字节算「一条消息」。

所以「粘包/拆包」严格说不是 TCP 的 bug，而是应用层误以为 TCP 会保留消息边界造成的错觉。TCP 从设计上就是字节流，边界本来就该应用层自己管。

这也解释了为什么 UDP 没有粘包问题：UDP 是数据报，一个 sendto 对应一个 recvfrom，边界被保留（详见「TCP 和 UDP 的区别」那道题）。

二、消息头带长度：最通用的解法

主流协议几乎都用「长度字段」方案。设计一个简单协议：

+----------+------------------+
| 长度(4B) |   消息体(N字节)   |
+----------+------------------+

接收方的读取逻辑变成：

先读固定的 4 字节，解析出消息体长度 N；
再精确读 N 个字节，就是完整的一条消息；
循环处理缓冲区里剩下的字节。

这样无论 TCP 怎么粘、怎么拆，接收方总能按长度精确切出每一条消息。Netty 的 LengthFieldBasedFrameDecoder、Dubbo/RPC 框架、Redis 的 RESP 协议本质都是这个思路。

三、Netty 提供的现成解码器

实际开发不用自己从零处理粘包，成熟框架（如 Netty）内置了对应的解码器：

FixedLengthFrameDecoder：固定长度；
LineBasedFrameDecoder / DelimiterBasedFrameDecoder：按换行/分隔符；
LengthFieldBasedFrameDecoder：按长度字段（最常用、最灵活）。

面试能说出「用 Netty 的 LengthFieldBasedFrameDecoder 解决」是很实的加分点。

四、和 Nagle 算法的关系

Nagle 算法会把多个小的发送数据攒一攒再一起发（减少大量小包对网络的浪费），这会加剧粘包。可以用 TCP_NODELAY 关闭 Nagle 来降低延迟（如实时交互场景）。

但要注意：关掉 Nagle 并不能解决粘包——因为接收方一次读多少字节仍不确定，拆包依然可能发生。粘包/拆包的正解永远是应用层划边界，而不是调 TCP 参数。

五、常见误区

❌ 以为粘包是 TCP 的 bug——它是字节流的正常特性，边界该应用层管。
❌ 以为关闭 Nagle（TCP_NODELAY）能解决粘包——不能，接收侧拆包依旧。
❌ 以为 UDP 也有粘包——UDP 保留数据报边界，不粘包。
❌ 用分隔符方案却不处理转义——消息内容里出现分隔符会切错，需转义或改用长度字段。

六、常见误区与追问

考点	正确口径
根源	TCP 是字节流，没有消息边界
粘包	多个应用消息被读成一段
拆包	一个应用消息分多次读到
解决	长度字段、分隔符、固定长度或协议解码器

frame = length(4 bytes) + payload
read length first
then read exactly length bytes as one message

粘包拆包不是 TCP 出错，而是应用层把字节流误当成消息流。

误区：粘包是 TCP 把数据弄乱了。 TCP 保证字节顺序，但不保留应用层 write 的消息边界。
误区：关掉 Nagle 就能彻底解决粘包。 Nagle 影响小包合并发送，但接收端读取仍可能出现任意边界。
误区：每次 read 都对应一次 send。 流式协议里 read 返回多少取决于缓冲区和网络时机，不等于发送次数。
追问：最通用的解决方案是什么？ 在应用协议头里带长度，解码器按长度拆出完整帧。
追问：分隔符方案有什么风险？ payload 中若可能出现分隔符，需要转义或选择不会冲突的编码。
追问：HTTP 为什么没有这个问题？ HTTP 自身定义了报文格式、Content-Length、chunked 等边界规则。

七、加强记忆

TCP 面向字节流、不保留消息边界，导致多条消息被粘（粘包）或一条被拆（拆包），根源是应用误以为 TCP 有消息概念。解决靠应用层划边界：固定长度、分隔符、或最常用的消息头带长度字段（Netty 的 LengthFieldBasedFrameDecoder）。关 Nagle 不能解决，UDP 因保留数据报边界而无此问题。

简化版

详细版