TCP粘包是其面向流特性的自然结果，因TCP无消息边界概念，发送端合并、接收端未及时读完或网络分片均会导致粘包；解决需在应用层自定义边界，如固定长度、分隔符或长度前缀法。
TCP 粘包问题不是 TCP 协议的“bug”，而是其面向流（stream-oriented）特性的自然结果：TCP 保证数据按序、可靠传输，但不保留应用层的消息边界。发送方调用一次 send()，不等于接收方调用一次 recv() 就能拿到完整的一“包”数据。
为什么会出现粘包？
根本原因在于 TCP 没有“消息”概念，只有字节流。以下情况都会导致粘包：
- 发送端合并发送：小数据频繁调用
send()，而 Nagle 算法可能将多个小段合并成一个 TCP 报文段发出； - 接收端未及时读完：一次
recv(1024)只取前 1024 字节，但内核缓冲区里已存了 2000 字节，剩余数据下次recv()就会和新到的数据“粘”在一起； - 网络层分片与重组：虽然 IP 层可能分片，但 TCP 在传输层已重组为连续字节流，应用层无法感知原始分界。
如何识别是否发生了粘包？
关键看你的协议有没有明确的消息边界。例如：
- 你约定每条消息固定 100 字节 → 接收方每次必须收满 100 字节才算一条完整消息；
- 你用换行符
n分隔 → 需要缓存未完成的行，直到遇到n才切分； - 你用头部 + 内容格式（如前 4 字节表示长度）→ 必须先读够头部，再按长度读内容。
一旦实际收到的数据不能按预期边界切分（比如该结束的地方没结束、不该合并的地方合并了），就说明发生了粘包或半包。
立即学习“Python免费学习笔记（深入）”；
怎么解决粘包问题？
核心思路是：**在应用层自己定义并解析消息边界**。常见方案有：
- 固定长度法：简单但浪费带宽，适合消息长度高度可控的场景（如传感器心跳包）；
- 分隔符法：用特殊字符（如
n、|）标记结尾，注意需转义或避免出现在正文里； - 长度前缀法（推荐）：先发 4 字节整数表示后续内容长度，接收方先读 4 字节 → 解出长度 → 再读指定字节数；
- 自定义协议头：包含魔数、版本、长度、类型等字段，更健壮，适合复杂业务。
无论哪种方式，接收逻辑都必须是“累积+缓冲+按规则提取”，不能依赖单次 recv() 返回完整消息。
python 实现时容易忽略的关键点
很多初学者直接写 conn.recv(1024) 就以为拿到了一条消息，这是典型误区：
-
recv(n)最多返回 n 字节，但可能返回 1 字节、0 字节（对端关闭），甚至阻塞——它不保证填满缓冲区； - 必须用循环或状态机持续读取，直到满足你的消息边界条件；
- 建议封装一个
recv_exact(conn, n)函数，确保读够 n 字节；再配合协议头解析做分包逻辑。
不复杂但容易忽略。