粘包 和 拆包
百度一下很多文章都有解释的
链接:
MSS.
MTU.
原因的话，就是网络层级故意给你搞的。
TCP下，也没啥必要纠结这一块东西。
简单来说，就是 粘包就是 接收端一次收到2个包
拆包 就是 接收端里 有一个包不完整，只有一部分。
拆包 和 粘包 可能混合出现。
解决这个问题最好的办法，其实就是 数据包 有长度。
按照长度去获取 数据包，发现包体不完整，就等下一次Check。
例如
完整数据包 + 破损数据包（粘包 + 拆包，经常出现 很正常）
破损数据包（拆包，可能是你缓冲区太小了，单个数据包太大）
完整数据包 + 完整数据包 （粘包）
当然情况是不一定的，因为按照MSS和MTU的原理，你的消息包大小，会被网络底层切割，在并发高的时候，可能出现上面的情况。
但是在TCP的环境下，有一件事是一定的，消息包是有顺序的，可以信赖的。
也就是说，完整数据包 + 破损数据包 + 破损数据包，着这样中间夹着破损数据包的情况是不存在的， 破损只可能在队尾出现。
举例说明处理方案的逻辑：
假设现在数据包的长度固定为：4
包体内容统一为：1234
那么当前receive时候的 缓冲区内 内容为
1234 1234
解包得到 1234整包 1234整包
1234123412
解包得到 1234整包 + 1234整包 + 12破损包
123
解包得到破损包
那么怎么处理破损包那？
就很简单。。等下一次reveice。。因为TCP是可靠消息，破损包一定会由底层重连重新获取。
具体说明处理逻辑：
假定固定长度为：4
包：1234
包：5678
包：9012
那么收到缓冲区内容123456
1.解析得到1234为整包，解析56长度不为4失败
2.缓冲区切出1234，保留56
3.receive时候，向后继续写入缓冲区
缓冲区可能为56789
4.解析得到5678，解析9长度不为4保留
5.等待receive，向后继续写入缓冲区为9012
6.取得9012整包。
程序学无止尽。
