TCP 粘包的原因和处理方式是什么？

核心回答

TCP 提供有序的字节流，不保留应用消息边界。发送方连续写两条消息，接收方可能一次读到两条，也可能分几次才读完一条，通常称为粘包、拆包或半包。这是字节流的正常语义，不表示 TCP 把数据弄乱了。

解决办法是在应用层定义消息如何结束，并持续解析接收缓冲区。常见方式是固定长度、分隔符、长度字段。接收端必须同时处理“消息未收全”和“一次收到多条消息”，不能假定一次 send 对应一次 recv。

原因应该分两层说

根本原因是协议没有提供业务消息边界。TCP 把应用交来的字节组成 TCP 段，网络分段边界、应用写入边界、应用读取边界没有一一对应关系。

具体读到多少，又受发送与接收缓冲、MSS、流量和拥塞控制、调度及本次读取上限等因素影响。Nagle 等机制可能改变小数据的发送时机，但关闭它也不会让 TCP 获得消息边界。接收端读得慢时，多条消息也可能已经积在接收缓冲区中。

例如应用依次发送 hello、world，对端可能读到 helloworld，也可能依次读到 hel、lowor、ld。只要字节顺序正确，这些读取结果都可以成立；如果应用没有约定分界规则，就无法仅从这一串内容判断原来的两条消息在哪里分开。

三种常见处理方式

固定长度：约定每帧总是固定的字节数，收满一帧再处理，不足时继续累计。实现简单，但短消息需要填充，变长数据不灵活；一次读取仍可能不足一帧或包含多帧。

分隔符：例如文本协议用换行结束一条消息。解析器累计字节并查找完整分隔符，消息体若允许包含分隔符，需要转义或采用能明确处理它的编码规则。多字节分隔符也可能跨两次读取，不能只在当前这次收到的数据里查找。还要限制一直找不到分隔符时可累计的长度。

长度字段：头部记录正文有多少字节，接收端先取得完整头部，再根据长度取得正文。双方需要约定长度字段大小、字节序、长度是否含头部、编码及最大允许值。这种方式适合变长或二进制消息，但不能信任对端随意声明的长度。

已有 HTTP、WebSocket 或 RPC 等应用协议时，按协议及框架的解码规则处理，通常不需要在业务层再发明一套与其冲突的分包规则。

长度头方案如何正确解析

假设协议约定：前 4 字节为大端无符号整数，表示正文的字节数，随后是正文。发送 abc 和 de 两条消息时，线上字节依次为长度 3、abc、长度 2、de。

接收端维护每条连接自己的未消费缓冲区，重复执行：

1. 少于 4 字节时，继续等待，不能把不完整的头当作长度。
2. 头部收全后解析长度，先检查协议上限，再等待正文；不能根据一个未经检查的巨大长度直接分配内存。
3. 缓冲区达到“4 字节头部＋正文长度”后，取出一条完整消息，交给业务处理。
4. 消费这一帧后继续解析剩余字节，直到不足下一帧；保留不足的部分，等待后续数据。

这里即使第一次只收到长度头的前 2 字节，或一批数据同时含两条完整消息，解析逻辑也应得到同样的 abc、de。长度通常按编码后的字节计算，不能把中文字符数直接当作 UTF-8 字节数；文本解码应在收齐相应消息后进行，或使用正确的增量解码器。

还要处理连接关闭时的残帧、非法长度、超时和缓冲区总量限制。若对端在正文收全前关闭，当前帧是被截断，不能把剩余内容悄悄当成完整业务请求。发送端也需处理部分写入，确保预期发送的所有字节都交给连接。

常见追问

关闭 Nagle、调用 flush 或睡一会儿能解决吗？

这些操作会影响发送时机或缓冲行为，不定义应用消息边界。无论如何调参，接收程序都应能处理任意合法分段和合并读取。

TCP 首部不是有长度吗？

TCP 段的结构和 IP 所携带的数据长度用于传输层处理，不代表上层的一条消息。一个业务消息可以跨多个 TCP 段，一个 TCP 段也可以装多条业务消息的字节，PSH 标志同样不是消息结束标记。

增大接收缓冲区能否保证一次读完？

不能。缓冲区变大只是提高可存放或本次可读取的上限，数据到达时机及分段不受业务读取调用控制。固定请求长度的读取也可能需要多次完成。

参考资料