stickypacketproblem在TCP等字节流协议上做应用层打包是网络编程的一个基本需求。打包是指当一条消息（message）或一帧（frame）数据出现时，通过一定的处理，接收方可以从字节流中识别并截取（恢复）每一条消息。因此，“粘包问题”是一个伪命题。短连接分包对于短连接TCP服务，分包不是问题。只要发送方主动关闭连接，就意味着一条消息已经发送，接收方的read()返回0，从而知道消息结束TCP发送机制为了提高TCP的传输效率，TCP有自己的发送机制。TCP维护一个变量，它等于最大段长度MSS。只要缓存中存储的数据达到MSS字节，就会组装成一个TCP报文段发送出去，发送方的应用进程会指定发送报文段的请求，也就是为发送方设置一个定时器TCP支持的push操作的截止时间到了，将当前存在的缓存数据加载到报文段中（但长度不能超过MSS）发送出去长连接分包对于长连接TCP服务，有四种分包方式.消息长度固定，使用特殊字符。或者一个字符串作为消息的边界。例如，HTTP协议的头部使用“rn”作为字段分隔符，为每条消息的头部添加一个长度字段。这可能是最常见的使用消息本身的格式来划分数据包的方法。例如XML格式消息中的...配对，或JSON格式的{...}配对。解析这种报文格式通常会用到状态机的复杂打包。如果消息格式很简单，“消息”本身就是一个字符串，每条消息都有一个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个字节，长度是完整的，但是bodyisincomplete数据到达两次，第一次收到9个字节，长度完整，但body也完整数据到达两次，第一次收到10个字节，第一个消息的长度完整，并且正文也完整了，第二条消息长度不完整，请自行移动增加分割点，有超过100万条可能（221-1）的数据一次到达《TCP粘包拆包》
