以前碰到过，有办法解决。
由于粘包不可避免，所以可以从协议上下手，使用包头或者包尾来从粘包数据中区分每一包的数据。但是不做特殊处理，粘包后包头包尾可能会和数据混淆，所以可以按照下面的方法来做，将包头包尾从数据中区分开来。
比如发送[11,bb,cc]的数据过去，可以将11这个十六进制拆分成两个字节[31,31]，在服务器端再进行解析，31也就是1的ascii码。
对于所有数据来说，都可以是十六进制的，十六进制的字符范围也就是0-9,a-f，比如f0,12,ff,00这些，都可以拆分成两个字节。拆分之后，他们的范围就是30-39(0-9)，61-66(a-f)，而不在这些范围之内的就可以用作包头包尾了。
那到了这里就简单了，只要看到特定的包头(例如60)，那么就认为后面的是新一包的数据，直到再碰到下一个包头，服务端只要用这个规则对数据进行解析即可，例如 60,31,32,61,66(包头,12,af)。
当然，11不仅仅可以拆成[31,31]，也可以拆成[01,01]，fa也可以拆成[0f,0a]，也就是不按照ascii码来拆，那么所有数据范围就是00-0f，除了这些以外的都可以做包头包尾。

很简单，tcp数据包每一个条第一个字节就是后面的长度，完成第一个包，再循环即可，tcp可靠流式传输

很简单，tcp数据包每一个条第一个字节就是后面的长度，完成第一个包，再循环即可，tcp可靠流式传输

本帖最后由 tribear 于 2017-1-12 19:58 编辑

TCP粘包一般是2个或者以上的TCP包粘结在一起,一般不会出现数据帧不完整的情况所以,可以用递归调用的方法处理TCP的粘包问题.
比如说你封装一个解析TCP数据帧的函数DecodeTCPFrame(uint8_t *TCPData, int TCPLength)  (TCPData[]为缓冲数组,TCPLength为TCP包的字节),
通过对比你自定义协议帧中的Len长度和TCP的包长度就能判断是不是有粘包的情况,
如果有粘包的情况就再递归调用一遍DecodeTCPFrame(&TCPData[第二帧起始字节下标],TCPLength - 上一个帧的完整长度).
一直对比到TCPLength 和数据帧Len符合时跳出DecodeTCPFrame函数.

把上面解析到的数据帧存到一个结构体数组里,搞定~

怀疑不是模块自动帮忙组包上传造成的，仔细看看模块手册是不是有包间隔时间之类的参数。