tcp粘包（一）
https://blog.csdn.net/freeking101/article/details/78922846
socket的长连接、短连接、半包、粘包与分包
之所以出现粘包和半包现象,是因为TCP当中，只有流的概念，没有包的概念 。
TCP是一种流协议（stream protocol）。这就意味着数据是以字节流的形式传递给接收者的，没有固有的"报文"或"报文边界"的概念。从这方面来说，读取TCP数据就像从串行端口读取数据一样--无法预先得知在一次指定的读调用中会返回多少字节（也就是说能知道总共要读多少，但是不知道具体某一次读多少）
看一个例子:我们假设在主机A和主机B的应用程序之间有一条TCP连接，主机A有两条报文D1,D2要发送到B主机，并两次调用send来发送，每条报文调用一次。
半包
指接受方没有接受到一个完整的包，只接受了部分，这种情况主要是由于TCP为提高传输效率，将一个包分配的足够大，导致接受方并不能一次接受完。（ 在长连接和短连接中都会出现）。
粘包与分包
指发送方发送的若干个包数据到接收方接收时粘成一个完整的包数据，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。如下图：客户端同一时间发送几条数据，而服务端只能收到一大条数据，
由于传输的过程为数据流，经过 TCP 传输后，三条数据被合并成了一条，这就是数据粘包了。
出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。
发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。这么做优点也很明显，就是为了减少广域网的小分组数目，从而减小网络拥塞的出现。总的来说就是：发送端发送了几次数据，接收端一次性读取了所有数据，造成多次发送一次读取；通常是网络流量优化，把多个小的数据段集满达到一定的数据量，从而减少网络链路中的传输次数。
接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。（在长连接中都会出现）。总的来说就是：发送端发送了数量比较多的数据，接收端读取数据时候数据分批到达，造成一次发送多次读取（在实践中，客户端开启TCP_NODELAY后，服务端仍沾包，所以这里是多次发送一次读取）；通常和网络路由的缓存大小有关系，一个数据段大小超过缓存大小，那么就要拆包发送。
如图所示：
TCP粘包的解决方案有很多种方法，最简单的一种就是发送的数据协议定义发送的数据包的结构：
- 数据头：数据包的大小，固定长度。
- 数据内容：数据内容，长度为数据头定义的长度大小。
实际操作如下：
- 发送端：先发送数据包的大小，再发送数据内容。
- 接收端：先解析本次数据包的大小N，在读取N个字节，这N个字节就是一个完整的数据内容。
具体流程如下：
初涉socket编程的朋友经常有下面一些疑惑：
1. 为什么我发了3次，另一端只收到2次？
2. 我每次发送都成功了，为什么对方收到的信息不完整？
这些疑惑往往是对send和recv这两个函数理解不准确所致。send和recv都提供了一个长度参数。对于send而言，这是你希望发送的字节数，而对于recv而言，则是希望收到的最大字节数。
tcp粘包、半包的处理方式：一是采用分隔符的方式，采用特殊的分隔符作为一个数据包的结尾；二是采用给每个包的特定位置（如包头两个字节）加上数据包的长度信息，另一端收到数据后根据数据包的长度截取特定长度的数据解析，假设包头信息的数据长度为infoLen，接收到的数据包真实长度为trueLen，那么有如下几种情况：
- 1： infoLen>trueLen，半包。
- 2： infoLen<trueLen，粘包。
- 3： infoLen=trueLen，正常。
UDP 就不会有上面这种情况，它不会使用块的合并优化算法。当然除了优化算法，TCP 和 UDP 都会因为下面两种情况造成粘包：断包
断包比较好理解的，比如我们发送一条很大的数据包，类似图片和录音等等，很显然一次发送或者读取数据的缓冲区大小是有限的，所以我们会分段去发送或者读取数据。
无论是粘包还是断包，如果我们要正确解析数据，那么必须要使用一种合理的机制去解包。
这个机制的思路其实很简单：我们在封包的时候给每个数据包加一个长度或者一个开始结束标记。然后我们拆包的时候就能区分每个数据包了，再按照长度或者分解符去分拆成各个数据包。
什么时候需要考虑半包的情况?
Socket内部默认的收发缓冲区大小大概是8K，但是我们在实际中往往需要考虑效率问题，重新配置了这个值，来达到系统的最佳状态。
一个实际中的例子：用mina作为服务器端，使用的缓存大小为10k，这里使用的是短连接，所有不用考虑粘包的问题。
问题描述：在并发量比较大的情况下，就会出现一次接受并不能完整的获取所有的数据。
处理方式：
1.通过包头 包长 包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。
2.指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。
什么时候需要考虑粘包的情况?
- 1.当时短连接的情况下，不用考虑粘包的情况
- 2.如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包
- 3.如果双方建立连接，需要在连接后一段时间内发送不同结构数据
处理方式：
接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开
注：粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包
我的TCP协议的数据传输，并且数据传输最大4096byte，所以应该不会产生半包情况，但粘包的两种情况应该都会产生
示例代码：
解决思路：封包与拆包
在上面说到我们给每个数据包添加头部，头部中包含数据包的长度，这样接收到数据后，通过读取头部的长度字段，便知道每一个数据包的实际长度了，再根据长度去读取指定长度的数据便能获取到正确的数据了，这就是所谓的通讯协议。
通信协议就是通讯双方协商并制定好要传送的数据的结构与格式。并按制定好的格式去组合与分析数据。从而使数据得以被准确的理解和处理。如何去制定通讯协议呢？很简单，就是指定数据中各个字节所代表的意义。比如说：第一位代表封包头，第二位代表封类型，第三、四位代表封包的数据长度。然后后面是实际的数据内容。
如下面这个例子：
前面三部分称之为封包头，它的长度是固定的，第四部分是封包数据，它的长度是不固定的，由第三部分标识其长度。因为我们的协议将用在TCP中，所以我没有加入校验位。原因是TCP可以保证数据的完整性。校验位是没有必要存在的。
接下来我们要为这个数据封包声明一个类来封装它：
再来回顾一下 协议：
小结：
粘包出现原因
简单得说，在流传输中出现，UDP不会出现粘包，因为它有消息边界(参考Windows网络编程)
1发送端需要等缓冲区满才发送出去，造成粘包
2接收方不及时接收缓冲区的包，造成多个包接收
什么时候需要考虑粘包的情况?
- 1.当时短连接的情况下，不用考虑粘包的情况
- 2.如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包
为了避免粘包现象，可采取以下几种措施：
（1）对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
（2）对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。
以上提到的三种措施，都有其不足之处。
（1）第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。
（2）第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。
（3）第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。
只能通过 \n、分割符、指定长度、头里塞长度解决
