我很负责任的告诉你，能做的了。看看我的数据包格式
0xa5a5xxx; xxxx表示协议版本
packetLen ;数据包总长度。
aa
bb
cc
.. ..以上是数据包头，下面是附加数据
accachLen ;附加数据长度
data;附加数据数组

黏包的原因不必找，任何服务器都存在黏包的可能，这是TCP协议决定的。除了黏包，TCP还会分包，就是你接到的数据未必是一个整包，可能存在一包分多次才能接受完整的情况。处理的方法很简单，就是在服务器端对接收到的数据进行缓存，然后另外一个线程负责解析这些数据，典型的生产者消费者模式。你这个协议做的有问题，通常有两种方法，一是先发数据长度，服务器端根据长度来收后边的数据，收够了就认为是一包完整的数据，然后再收长度，再收数据，规定好数据长度的固定字节，比如说2字节一般。第二种方法就是指定一个帧开头和结尾，中间的数据全部做16进制变换，可以避免数据与帧开头结尾冲突，也可以采用转义字符的方式处理。你你这种格式很有可能碰到数据与开头相同的问题，黏包的时候就分不开了。

黏包了就拆包啊，收到数据后先摘出来一包的数据，如果还有没处理的字节就再摘出一包数据来，直至本次收到的数据全处理完成。

应用层把黏包解开  不就可以了吗？     我们都是这样做的

TCP是流式的，就像自来水水流过水管。 实际上并没有“包”的概念。  所谓的“黏包”是伪命题。

包，你可以自己封装。 每“一堆”数据加上头尾，做成一个所谓的“包”，服务器收到后根据头尾解析。在头中包含长度，这样更可靠。

不过服务器也要写得好才行。比如你一个包是20字节发了2个包。有可能服务器第一次收到了30字节，是第一个包以及第二个包的前前半部分。 然后过了一会儿才收到最后10字节。

服务器必须要能可靠的处理这种情况，才能长期稳定工作。