1. 粘包拆包问题概述：什么是TCP粘包与拆包？

做网络编程的朋友，十有八九都遇到过这么个怪现象：客户端明明发了两次数据，服务端却一次全收走了。或者反过来，发了一次，服务端分两次才收完。

这其实就是TCP的粘包和拆包问题。说白了，粘包就是多个数据包粘在一起被接收，拆包就是一个数据包被拆成多段接收。我刚开始接触这个问题时，也觉得挺诡异的——明明上层逻辑是分开发送的，怎么到了对端就乱套了？

核心定义：

要理解这个问题，得先搞清楚TCP的本质。TCP是个流式协议——它不关心你发的是什么内容，只关心字节流的顺序和可靠性。你想想看，TCP就像一根水管，你把水倒进去，它只管往前流，至于水流里混了几种液体，它才不管呢。

具体来说，粘包拆包的原因主要有这么几个：

TCP的Nagle算法：这个算法会把多个小数据包合并成一个大的TCP报文再发送，目的是减少网络中的小包数量，提高网络利用率。但副作用就是——粘包。
TCP的MSS（最大报文段长度）：如果应用层数据超过了MSS，TCP就会把数据拆成多个报文段发送。这就是拆包的根源。
接收方的缓冲区策略：应用层读取数据的速度，可能跟不上数据到达的速度。数据在接收缓冲区里积压，一次read可能读到多个包（粘包），也可能只读到半个包（拆包）。
IP分片与重组：虽然这层通常对上层透明，但在某些极端网络环境下，IP层也会参与拆包。

我个人习惯：在调试粘包问题时，第一件事就是关掉Nagle算法（设置TCP_NODELAY选项）。这能排除一个最常见的干扰因素，让你更快定位到真正的协议设计问题。

我画了一张图，帮你直观理解这两种情况：

我把原因整理成了一张表，方便你对照理解：

我曾经踩过的一个坑：有一次做游戏服务器，客户端每帧发送一个很小的状态包（不到20字节）。服务端那边收到的数据总是乱序拼接，调试了整整一天才发现是Nagle算法在作祟。从那以后，凡是需要实时交互的场景，我第一件事就是关Nagle。

这个问题经常有人问。UDP是报文协议，它保留了消息边界。每次sendto发送的数据，recvfrom接收时就是完整的一条消息。TCP是流协议，没有消息边界的概念。

说白了，UDP的每个数据报都是独立封装的，内核不会帮你合并或拆分。但TCP不同，它只保证字节流的顺序和可靠性，至于你怎么切分数据，那是应用层的事。

我的建议：如果你在TCP上做应用层协议设计，一定要把「消息边界」这个问题放在第一位考虑。不管你用哪种方案（后面几章会详细讲），核心目标只有一个——让接收方能准确判断一条消息从哪里开始、到哪里结束。

这个问题不解决，后果很严重：