TCP粘包问题

本篇博客从以下四个问题进行分析，来理解TCP粘包问题。
什么是TCP粘包问题？
为什么会存在TCP粘包问题？
如何解决TCP粘包问题？
UDP是否存在粘包问题？为什么？

什么是TCP粘包问题？

TCP是面向连接的，即客户端和服务端要成对维护socket连接。如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。
举个例子
正常情况下，如图两个数据包在网络中传输，分别到达服务端

但是发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小、数据量小的数据，合并成一个大的数据块，然后进行封包。假设这里的packet1和packet2都比较小，两个包的长度之和小于MTU。则会出现粘包情况。

粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。

不是所有的粘包现象都需要处理，若传输的数据为不带结构的连续流数据（如文件传输），则不必把粘连的包分开（简称分包）。但在实际工程应用中，传输的数据一般为带结构的数据，这时就需要做分包处理。

为什么会存在TCP粘包问题？

粘包问题的产生是由于TCP是基于流的传输。可以这么理解，TCP的数据传输就像一种水流一样，并不区分不同数据包之间的界限。 就像我们打开水龙头后，水流自然的流出，我们并不知道背后水泵是分了几次将水供上来的。操作系统提供的SOCKET支持缓存发送和分包发送。
TCP为了保证可靠传输，尽量减少额外开销（每次发包都要验证），因此采用了流式传输，面向流的传输，相对于面向消息的传输，可以减少发送包的数量，从而减少了额外开销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核中的socket的写法）

例如，我们连续发送三个数据包，大小分别是2k，4k ，8k,这三个数据包，都已经到达了接收端的网络堆栈中，如果使用UDP协议，不管我们使用多大的接收缓冲区去接收数据，我们必须有三次接收动作，才能够把所有的数据包接收完。而使用TCP协议，我们只要把接收的缓冲区大小设置在14k以上，我们就能够一次把所有的数据包接收下来，只需要有一次接收动作。

具体点分析就是：

• 发送端需要等缓冲区满才发送出去，造成粘包
• 接收方不及时接收缓冲区的包，造成多个包接收

（1）发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。

（2）接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。

如何解决TCP粘包问题？

短连接

最简单的方法就是短连接，也就是需要发送数据的时候建立TCP连接，发送完一个数据包后就断开TCP连接，这样接收端自然就知道数据结束了。
但是这样的方法因为会多次建立TCP连接，性能低下。随便用用还可以，只要稍微对性能有一点追求的人就不会使用这种方法。

长连接

使用长连接能够获得更好的性能但不可避免的会遇到如何判断数据结构的开始与结束的问题。
而此时的处理方式根据数据结构的类型分两种方式。

定长结构

因为粘包问题的存在，接收端不能想当然的以为发送端一次发送了多少数据就能一次收到多少数据。如果发送端发送了一个固定长度的数据结构，接收端必须每次都严格判断接收到额数据的长度，当收到的数据长度不足时，需要再次接收数据，直到满足长度，当收到的数据多于固定长度时，需要截断数据，并将多余的数据缓存起来，视为长度不足需要再次接收处理。

不定长结构

定长的数据结构是一种理想的情况，真正的应用中通常使用的都是不定长的数据结构。
对于发送不定长的数据结构，简单的做法就是选一个固定的字符作为数据包结束标志，接收到这个字符就代表一个数据包传输完成了。
但是这只能应用于字符数据，因为二进制数据中很难确定结束字符到底是结束还是原本要传输的数据内容（使用字符来标识数据的边界在传输二进制数据时时可以实现的，只是实现比较复杂和低效。想了解可以参考以太网传输协议）。
目前最通用的做法是在每次发送的数据的固定偏移位置写入数据包的长度。
接收端只要一开始读取固定偏移的数据就可以知道这个数据包的长度，接下来的流程就和固定长度数据结构的处理流程类似。
所以对于处理粘包的关键在于提前获取到数据包的长度，无论这个长度是提前商定好的还是写在在数据包的开头。 因为在每次发送的数据的固定偏移位置写入数据包的长度的方法是最通用的一种方法，所以对这种方法实现中的一些容易出错误的地方在此特别说明。

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

UDP是否存在粘包问题？为什么？

在分析完TCP的粘包问题后，我们来看看UDP是否会存在此类问题。相比于TCP，UDP是面向无连接的，面向消息的传输。
这里先说明一下保护消息边界和面向流
保护消息边界，就是指传输协议把数据当作一条独立的消息在网上传输，接收端只能接收独立的消息。也就是说存在保护消息边界，接收端一次只能接收发送端发出的一个数据包。而面向流则是指无保护消息保护边界的，如果发送端连续发送数据，接收端有可能在一次接收动作中，会接收两个或者更多的数据包。
上面给出的列子中指出我们连续发送三个数据包，大小分别是2k，4k ，8k,这三个数据包，都已经到达了接收端的网络堆栈中，如果使用UDP协议，不管我们使用多大的接收缓冲区去接收数据，我们必须有三次接收动作，才能够把所有的数据包接收完。这里也可以看出UDP是不存在粘包问题的。

UDP，由于面向的是消息传输，它把所有接收到的消息都挂接到缓冲区的接受队列中，因此，它对于数据的提取分离就更加方便，但是，它没有粘包机制，因此，当发送数据量较小的时候，就会发生数据包有效载荷较小的情况，也会增加多次发送的系统发送开销（系统调用，写硬件等）和接收开销。因此，应该最好设置一个比较合适的数据包的包长，来进行UDP数据的发送。（UDP最大载荷为1472，因此最好能每次传输接近这个数的数据量，这特别适合于视频，音频等大块数据的发送，同时，通过减少握手来保证流媒体的实时性）
参考：
https://blog.csdn.net/bjrxyz/article/details/73351248
https://www.cnblogs.com/smark/p/3284756.html
https://www.cnblogs.com/kex1n/p/6502002.html
https://blog.csdn.net/scythe666/article/details/51996268