2. TCP协议基础回顾：面向连接、可靠传输、字节流特性
聊粘包拆包之前，我建议咱们先把TCP的老底翻一翻。很多人在应用层调了半天的bug，最后发现根子其实在TCP协议本身。说白了，你不了解TCP的脾气，就搞不懂它为什么要把数据“粘”在一起，又为什么有时候会“拆”得七零八落。
这一节我们不讲三次握手四次挥手那些老生常谈的东西，我带你从面向连接、可靠传输、字节流这三个核心特性入手，看看它们跟粘包拆包到底有什么关系。
2.1 面向连接：不是“连上就行”那么简单
TCP是面向连接的协议。什么意思？就是通信双方在发数据之前，必须先建立一条虚拟的“管道”。
我记得刚入行那会儿，有个同事问我：“TCP连接不就是IP加端口吗？有什么好讲的？”后来他在生产环境遇到一个诡异问题——客户端发数据偶尔会丢，查了半天发现是中间防火墙把空闲连接给掐了。嗯，从那以后他再也不说“连上就行”这种话了。
面向连接的本质：
- 通信前必须建立连接（三次握手）
- 通信结束后必须释放连接（四次挥手）
- 连接状态由两端的内核维护，不是“无状态”的
- 中间网络设备（路由器、防火墙）也可能感知连接状态
你想想看，这个“连接”跟粘包拆包有什么关系？关系大了去了。因为TCP连接是全双工的，数据可以同时在两个方向上流动。而且连接一旦建立，两端的内核都会为这个连接分配缓冲区。这个缓冲区，就是粘包拆包发生的“第一现场”。
2.2 可靠传输：TCP为了“靠谱”做了多少事
TCP的可靠传输，说白了就是“发了就一定要让对方收到，收不到我就重发”。这个特性让应用层省了很多心，但也带来了一些“副作用”。
我给大家拆解一下TCP为了保证可靠，到底干了哪些事：
| 机制 | 作用 | 对粘包拆包的影响 |
|---|---|---|
| 确认应答（ACK） | 接收方收到数据后回复确认 | 发送方必须缓存已发未确认的数据 |
| 超时重传（RTO） | 没收到ACK就重发 | 可能导致接收方收到重复数据 |
| 序列号（SEQ） | 给每个字节编号 | 接收方按序号重组，可能乱序到达 |
| 流量控制 | 接收方告诉发送方“我还能收多少” | 发送方可能攒数据等窗口变大 |
| 拥塞控制 | 网络拥堵时主动降速 | 发送方可能合并小包减少发送次数 |
看到没有？TCP为了“可靠”，引入了缓存、重传、排序、流控、拥塞控制等一系列机制。这些机制共同作用的结果就是：应用层写一次数据，TCP不一定会立刻发出去；应用层读一次数据，TCP也不一定只返回一次写入的内容。
避坑指南：我曾经在一个网关项目里遇到过一个问题——客户端每次发送100字节的数据，服务端用recv()接收，结果有时候一次收到100字节，有时候一次收到200字节，有时候一次只收到50字节。当时我第一反应是“代码写错了”，查了半天才发现，这就是TCP的可靠传输机制在“捣乱”。
2.3 字节流特性：这才是粘包拆包的“罪魁祸首”
前面两个特性是铺垫，这个才是重点。TCP是面向字节流的协议，不是面向消息的协议。这句话怎么理解？
我打个比方：你把TCP连接想象成一根水管，应用层写入的数据就是流进水管的水。水进了水管就混在一起了，你没办法从水管里把“第一杯水”和“第二杯水”区分开。接收端从水管里接水，接多少、什么时候接，完全由接收端自己决定。
这就是字节流的核心：TCP不关心应用层的数据边界。
字节流 vs 消息包：
- 应用层视角：我发了3条消息，每条100字节
- TCP视角：我收到了300个字节，至于这300个字节是几条消息，我不关心
- 接收端视角：我调用recv()，可能一次拿到300字节，也可能分3次各拿100字节，还可能一次拿150字节、一次拿150字节
为什么会这样？因为TCP的发送和接收都是基于缓冲区的。发送方把数据写到发送缓冲区，TCP协议栈决定什么时候把缓冲区里的数据打包成报文段发出去。接收方收到报文段后放到接收缓冲区，应用层再从缓冲区里读。
这个过程中，有几个关键因素会导致“粘包”或“拆包”：
- Nagle算法：为了减少小包数量，TCP会等缓冲区攒够一定数据再发。这就是“粘包”的常见原因之一。
- MSS（最大报文段长度）：如果应用层写入的数据超过MSS，TCP会拆成多个报文段发送。这就是“拆包”。
- 接收缓冲区大小：应用层读取速度跟不上接收速度，数据会在缓冲区里堆积，下次读取时可能一次读到多个消息。
- 网络延迟和乱序：报文段可能走不同路径到达，接收方需要等所有报文段到齐才能重组。
我的经验：很多初学者以为“我发一次，对方就能收一次”，这是典型的UDP思维。TCP不是这样的。我建议你在写网络程序时，永远不要假设一次send()对应一次recv()。这个假设一旦成立，粘包拆包的问题就会找上门来。
2.4 一张图看懂TCP的核心特性
下面这张图展示了TCP协议栈的工作流程，以及粘包拆包发生的环节：
2.5 三个特性如何共同导致粘包拆包
现在我们把三个特性串起来看：
- 面向连接建立了全双工管道，两端都有缓冲区
- 可靠传输要求数据必须按序到达，所以TCP会缓存、重排、重传
- 字节流让TCP不关心数据边界，只关心字节顺序
这三个特性叠加在一起，就导致了这样一个结果：应用层写入的数据，在TCP层面被当作一个连续的字节流来处理。发送端可能合并多个写入，接收端可能拆分或合并读取。
这就是粘包拆包的根本原因。不是TCP有bug，而是TCP的设计哲学就是“我只管把字节流可靠地传过去，至于你怎么切分这些字节，那是你应用层的事”。
一句话总结：TCP粘包拆包不是TCP协议的问题，而是应用层没有处理好消息边界的问题。TCP只负责把字节流可靠地传过去，不负责告诉你“哪几个字节是一条消息”。
搞清楚了这一点，后面我们讲粘包拆包的解决方案时，你就能理解为什么需要“消息边界标识”、“固定长度”、“分隔符”这些手段了。说白了，就是在TCP这个“水管”里，给水流打上标记，让接收端知道从哪里切分。