粘包问题
在 TCP 这种字节流协议上做 应用层分包 是网络编程的基本需求。分包指的是在发生一个消息 (message) 或一帧 (frame) 数据时，通过一定的处理，让接收方能从字节流中识别并截取 (还原) 出一个个消息。因此，“粘包问题”是个伪命题
短连接分包
对于短连接的 TCP 服务，分包不是一个问题，只要发送方主动关闭连接，就表示一个消息发送完毕，接收方 read() 返回 0，从而知道消息的结尾
TCP 发送机制
为了提高 TCP 的传输效率，TCP 有一套自己的发送机制
- TCP 维持一个变量，它等于
最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去 - 由发送方的应用进程指明要求发送报文段，即 TCP 支持的
推送 (push)操作 - 发送方的一个计时器期限到了，这时把当前已有的缓存数据装入报文段 (但长度不能超过 MSS) 发送出去
长连接分包
对于长连接的 TCP 服务，分包有四种方法
- 消息长度固定
- 使用特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以“rn”为字段的分隔符
- 在每条消息的头部加一个长度字段，这恐怕是最常见的做法
- 利用消息本身的格式来分包，例如 XML 格式的消息中
<root>…</root>的配对，或者 JSON 格式中的 {…} 的配对。解析这种消息格式通常会用到状态机(state machine)
复杂的分包
假如消息格式非常简单，“消息”本身是一个字符串，每条消息有一个 4 字节的头部，以网络序存放字符串的长度。消息直接没有间隙，字符串也不要求以 ‘0’ 结尾
发送两条消息“hello”和“smartboy”，打包后的字节流共有 21 字节
0x00, 0x00, 0x00, 0x05, 'h', 'e', 'l', 'l', 'o',
0x00, 0x00, 0x00, 0x08, 's', 'm', 'a', 'r', 't', 'b', 'o', 'y'假设数据最终都全部到达，数据解析逻辑至少能正确处理以下各种数据到达的次序
- 一个字节一个字节到达
- 数据分两次到达，第一次收到 2 个字节，不足消息的长度字段
- 数据分两次到达，第一次收到 4 个字节，刚好够长度字段，但是没有 body
- 数据分两次到达，第一次收到 8 个字节，长度完整，但 body 不完整
- 数据分两次到达，第一次收到 9 个字节，长度完整，但 body 也完整
- 数据分两次到达，第一次收到 10 个字节，第一条消息的长度完整、body 也完整，第二条消息长度不完整
- 请自行移动和增加分割点，一共有超过 100 万种可能(221-1)
- 数据一次就全部到达
《TCP 粘包拆包》原文链接：https://blog.maplemark.cn/2019/04/tcp 粘包拆包.html?utm=sf