tcp粘包问题

一、造成粘包的原因

      我们常说tcp是一种流式连接，这里的“流”指的是数据向水流一样，并不区分数据包之间的界限。tcp协议允许发送端将几次发送的数据缓存起来合成一个数据包发送到网络上去，因此这样可以获得更多的效率，这一行为往往由操作系统中的socket提供，应用层对此毫无所觉。所以socket的send被调用发送数据时有可能不是立即发送，而是等待后续数据一起发送。

      网络传输中由MTU概念，即网络中一个数据包的最大长度，如果一次要发送的数据包大于这个最大长度，这个数据包就会被拆分再进行发送。

      发生上述现象，就会出现接收端的接收次数和发送次数不一样，这就是粘包现象。

举例：

假设A是发送端，B是接收端，MTU = 100字节

1、A调用send发送50字节数据，send将这50字节缓存起来

2、A继续发送50字节数据，send将这50个字节的数据和缓冲区的50个字节数据一并发送。

3、该过程理论上是A发送了两次，B接收两次，实际上A只发送了一次，那么这100个字节出现在接收方B的数据中并没有区分的界限，B在接收的时候就会发生粘包的现象

二、粘包问题的解决方法

1、短连接

      这是一种简单暴力的方法：当需要发送数据的时候简历tcp连接，发送完一次数据就断开连接，这样的方法建立了太多次的连接，稍微对效率有点追求的人不会去使用它

2、定长数据结构

      基于tcp连接的数据收发我们不能想当然的一位发送方发送了多少数据我们就能接收多少数据，因此如果发送方发送数据是一个固定长度，那么接收方在接收数据时则固定每次接收固定大小的数据，如果接收到的数据不够这个固定长度大小，则需要再次接收，如果接收的数据大于固定长度，则将多余的数据放入缓冲区，将多余的数据缓存起来以长度不足处理。

3、不定长结构

     定长数据结构是一种理想情况，在生活中我们大多数使用的是不定长的数据结构，对于不定长的数据结构，简单的做法就是选一个固定的字符作为结束标记，每当接收到该字符就表明一个数据包传输结束了。但是该做法只能应用于字符数据，因为二进制数据很难确定最后的字符是结束字符还是要传输的数据。

     目前最通用的方法是再固定的偏移位置写入数据包的长度，接收端只需要在固定的偏移位置获取数据长度，然后接收该长度的数据即可。

注意：

      通常我们使用2~4个字节来存放数据长度，多字节数据的网络传输需要注意字节序，所以要注意接受者和发送者要使用相同的字节序来解析数据长度。
      每次新开始接收一段数据时不要急着直接去解析数据长度，先确保目前收到的数据已经足够解析出数据长度，例如数据开头的2个字节存储了数据长度，那么一定确保接收了2个字节以上的数据后才去解析数据长度。 如果没做到这一点的服务器代码，收到了一个字节就去解析数据长度的，结果得到的长度是内存中的随机值，结果必然是崩溃的。有些非法客户端或者有bug的客户端可能会发出错误的数据，导致解析出的数据长度异常的大，一定要对解析出的数据长度做检查，事先规定一个合适的长度，一旦超过果断关闭SOCKET，避免服务器无休止的等待下去浪费资源。 
      处理完一个完整的数据包后一定检查是否还有未处理的数据，如果有的话要对这段多余的数据再次开始解析数据长度的过程。不要忙着去继续接受数据。 这应该是最常犯的一个错误，很多人以为完整的处理了一个数据包后就万事大吉，可以重新开始处理流程，但是别忘了，收到的数据有可能带着下一个数据包的数据，别把他们忘掉。