UDP只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。
UDP在IP数据报的头部仅仅加入了复用和数据校验。
由于缺乏可靠性且属于非连接导向协议，UDP应用一般必须允许一定量的丢包、出错和复制粘贴。
1 在接收udp包时，如果接收包时给定的buffer太小的话，就要自己解决粘包问题。
2 udp包的发送和接收不保证一定成功，不保证按正确顺序抵达。
3 如果不允许丢包的情况出现的话，要有重发机制来保证，如：反馈机制确认。
服务端
客户端
TCP协议下的粘包与拆包，如何解决一、粘包、拆包1.1 粘包原因1.1.1 滑动窗口1.1.2 Nagle算法1.1.3 应用层原因1.2 拆包原因1.2.1 滑动窗口1.2.2 MSS限制1.2.3 应用层原因1.2 Netty提供的解决方案二、自定义协议解决粘包、拆包2.1 自定义协议要素
因为TCP/IP在起初，所有的请求是串行化的，之后做成了滑动窗口的概念。那么在接收方，如果接收不及时且窗口大小足够大，就可能出现粘包的情况。
因为每次数据发送的时候，都需要加上消息头等特殊数据，TCP与IP协议分别会加20Byte数据，因此哪怕只是发送1Byte数据，最终接收方还是会接收到41Byte；在这样的背景下，Nagle算法可能会将多个数据包合并在一起发送。
接收方ByteBuf设置太大（Netty默认为1024Byte），因此如果客户端发送的报文都非常小，抛开上述 1.1.1.1 中的原因不谈，光在Netty这一处也非常容易出现粘包现象
假设接收方的窗口只剩128Bytes，发送方的报文大小是256Bytes，这时放不下了，只能先发送前128Bytes，等待ack后，窗口有剩余空间了才会发送剩余部分，这就导致了拆包
当发送数据超过MSS限制后，会将数据切分发送，而这个MSS是根据不同类型网卡的限制来看，譬如某笔记本网卡可以发送1500Byte，除去一次数据包中的TCP/IP固定40Byte外，真正的数据也只能发送1460Byte。
Netty中ByteBuf设置的大小小于数据包大小。
未完待续... ...
粘包和分包是利用Socket在TCP协议下内部的优化机制。
1、什么是粘包
只有TCP有粘包现象，UDP永远不会粘包，为何，且听我娓娓道来。发送数据时间间隔很短，数据了很小，也就是发送数据比较频繁，会合到一起，产生粘包；
2、什么是分包
当我们发送的数据量很大的时候，可能是几千字节，TCP就会自动分开发送，其实说通俗点，就是你去拿快递，一看20个，一次拿不完，分几次拿！
3、总结
指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。
发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。
若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。
这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。
在前面的测试程序中，是没有粘包问题的，这时候你可能有疑惑，我为啥数据会发送的特别快，我们以游戏服务器举例，比如游戏有联机对战功能，这时候肯定是需要同步位置信息的，这个频率是很快的，大约每秒就要40~80次，这个时候就会出现粘包问题。
其实很简单只要简单修改一下客户端即可。
1、程序测试 — 粘包问题
客户端：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
从客户端接收到的数据：0
从客户端接收到的数据：123
从客户端接收到的数据：4567
从客户端接收到的数据：8910
从客户端接收到的数据：1112131415
从客户端接收到的数据：161718
从客户端接收到的数据：192021222324
从客户端接收到的数据：25262728
从客户端接收到的数据：2930313233
从客户端接收到的数据：34353637
从客户端接收到的数据：38394041
从客户端接收到的数据：42434445
从客户端接收到的数据：46474849
从客户端接收到的数据：50515253
从客户端接收到的数据：5455565758
从客户端接收到的数据：59606162636465666768
从客户端接收到的数据：6970717273
从客户端接收到的数据：74757677
从客户端接收到的数据：78798081
从客户端接收到的数据：82838485
从客户端接收到的数据：86878889
从客户端接收到的数据：90919293
从客户端接收到的数据：9495969798
从客户端接收到的数据：99
（很明显数据没有发送100次）
1、程序测试 — 粘包问题
客户端：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
从客户端接收到的数据：
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000撒大声地所多所多所多所多所多所多所多所多所多所000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000撒大声地所多所多所多所多所多所多所多所多所多所多所多所多所多所多撒大声地所 多所多所多所多所多所多所多所多所多所多所多所多所多所多撒大声地所多所多所多所多所多所多所多所多所多所多所多所多所多所多000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000----------------------------------------------------------------撒大声地所多所多所多所多所多所多所多所多所?
从客户端接收到的数据：
77777777777777777777777777777777777777777777777777777777790909090909090909090909090909090909090000000000000000000000000099
（可以看出服务器是分两次接收的，但其实只要static byte[] dataBuffer = new byte[1024]给的空间足够大，分包问题就可解决）
其实也很好解决，我们在发送数据的时候事先存储数据的长度，不过用来存储数据长度的内存大小需要指定好，否则就没法判断了。
假设我们现在的数据出现了粘包，如下图所示：
这里只是演示一下，如果只有连续发送4次数据，一般是不会出现粘包的，看上图橙色部分表示我们用一个int32类型储存数据的长度，蓝色部分为我们实际要发送的数据，现在发生了粘包，也就是这四条数据合在一起发送给了服务器，
此时这条数据的总大小为 4字节 * 4 + 5 + 7 + 10 + 4 = 42字节
我们通过读取4字节数据可以知道数据的实际长度，以第一个数据为例，我们读取4字节数据，知道了这个数据有5个字节，程序如下：
int data_length = BitConverter.ToInt32(_data, 0)
此时的data_length = 5此时我们就读取这5个字节的数据即可！
string s = Encoding.UTF8.GetString(_data, 4, 5)
然后我们截取数据，从源数据的第4 + 5的位置开始截取到一个新数组，新字节数组索引从零开始，此时新字节数据的长度为42 - (5 + 4)；（下图为新字节数组）
Array.Copy(_data, 5 + 4, _data, 0, 42 - (5 + 4))
依次循环下去，粘包就被成功的分包了。当然这个不要忘记每次更新一下当前数据长度。
_curLength = _curLength - (data_length + 4)// _curLength = 42 - (5 + 4)
1、客户端
创建Message类，用于发送数据前做处理，使得首4字节储存数据长度。
Message：
Main：
2、服务端
创建Message类，解决粘包问题！
Main：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
解析到一条数据：0米
4
8
解析到一条数据：1米
4
630
解析到一条数据：2米
4
622
解析到一条数据：3米
4
614
解析到一条数据：4米
4
606
解析到一条数据：5米
4
598
解析到一条数据：6米
4
590
解析到一条数据：7米
4
582
解析到一条数据：8米
4
574
解析到一条数据：9米
4
566
解析到一条数据：10米
5
558
..............................................................................
解析到一条数据：98米
5
18
解析到一条数据：99米
5
9
有客户端退出.....
你解决个屁，异步接收的情况下，把_data数组调大点就完了，傻逼，咱们是做游戏！一般不会有分包问题！！
