TCP 粘包拆包

粘包问题

在 TCP 这种字节流协议上作应用层分包是网络编程的基本需求。分包指的是在发生一个消息(message)或一帧(frame)数据时，经过必定的处理，让接收方能从字节流中识别并截取(还原)出一个个消息。所以，“粘包问题”是个伪命题html

短链接分包

对于短链接的 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' 结尾tcp

发送两条消息“hello”和“smartboy”，打包后的字节流共有21字节code

0x00, 0x00, 0x00, 0x05, 'h', 'e', 'l', 'l', 'o',
0x00, 0x00, 0x00, 0x08, 's', 'm', 'a', 'r', 't', 'b', 'o', 'y'

假设数据最终都所有到达，数据解析逻辑至少能正确处理如下各类数据到达的次序htm

• 一个字节一个字节到达
• 数据分两次到达，第一次收到2个字节，不足消息的长度字段
• 数据分两次到达，第一次收到4个字节，恰好够长度字段，可是没有 body
• 数据分两次到达，第一次收到8个字节，长度完整，但 body 不完整
• 数据分两次到达，第一次收到9个字节，长度完整，但 body 也完整
• 数据分两次到达，第一次收到10个字节，第一条消息的长度完整、body 也完整，第二条消息长度不完整
• 请自行移动和增长分割点，一共有超过 100 万种可能(2^21-1)
• 数据一次就所有到达

《TCP粘包拆包》 原文连接：https://blog.maplemark.cn/2019/04/tcp粘包拆包.html?utm=sfblog