粘包问题

1 什么是粘包现象

　　TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

2 为什么出现粘包现象

　　（1）发送方原因

　　我们知道，TCP默认会使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。

　　所以，正是Nagle算法造成了发送方有可能造成粘包现象。

　　（2）接收方原因

　　TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

 

4 如何处理粘包现象

 

　　（1）发送方

　　对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭Nagle算法。

　　（2）接收方

　　遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。

　　（3）应用层处理

　　应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。

　　解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？

　　两种途径：

　　　　1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；

　　　　2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4位是数据的长度，应用层处理时可以根据长度来判断每条数据的开始和结束。

　　当时在做购物车的时候，我最开始的做法是设置开始符（0x7e）和结束符（0xe7），但在测试大量数据的时候，发现了数据异常。正如我所猜测，在调试过程中发现某些数据内部包含了它们。因为要处理的数据是量非常庞大，为做到万无一失，最后我采用了发送长度的方式。再也没有因为粘包而出过问题。

 

保护消息边界和流 ，那么什么是保护消息边界和流呢?  保护消息边界，就是指传输协议把数据当作一条独立的消息在网上  传输,接收端只能接收独立的消息.也就是说存在保护消息边界,接收  端一次只能接收发送端发出的一个数据包.  而面向流则是指无保护消息保护边界的,如果发送端连续发送数据,  接收端有可能在一次接收动作中,会接收两个或者更多的数据包. 我们举个例子来说,例如,我们连续发送三个数据包,大小分别是2k,  4k , 8k,这三个数据包,都已经到达了接收端的网络堆栈中,如果使  用UDP协议,不管我们使用多大的接收缓冲区去接收数据,我们必须有  三次接收动作,才能够把所有的数据包接收完.而使用TCP协议,我们  只要把接收的缓冲区大小设置在14k以上,我们就能够一次把所有的  数据包接收下来.只需要有一次接收动作.  这就是因为UDP协议的保护消息边界使得每一个消息都是独立的.而  流传输,却把数据当作一串数据流,他不认为数据是一个一个的消息. 所以有很多人在使用tcp协议通讯的时候,并不清楚tcp是基于流的  传输,当连续发送数据的时候,他们时常会认识tcp会丢包.其实不然,  因为当他们使用的缓冲区足够大时,他们有可能会一次接收到两个甚  至更多的数据包,而很多人往往会忽视这一点,只解析检查了第一个  数据包,而已经接收的其他数据包却被忽略了.所以大家如果要作这  类的网络编程的时候,必须要注意这一点.  结论：  根据以上所说，可以这样理解，TCP为了保证可靠传输，尽量减少额外 开销（每次发包都要验证），因此采用了流式传输，面向流的传输， 相对于面向消息的传输，可以减少发送包的数量。从而减少了额外开 销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。 当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里 粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特 别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（  两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核 中的socket的写法）   而UDP，由于面向的是消息传输，它把所有接收到的消息都挂接到缓冲 区的接受队列中，因此，它对于数据的提取分离就更加方便，但是， 它没有粘包机制，因此，当发送数据量较小的时候，就会发生数据包 有效载荷较小的情况，也会增加多次发送的系统发送开销（系统调用， 写硬件等）和接收开销。因此，应该最好设置一个比较合适的数据包 的包长，来进行UDP数据的发送。（UDP最大载荷为1472，因此最好能 每次传输接近这个数的数据量，这特别适合于视频，音频等大块数据 的发送，同时，通过减少握手来保证流媒体的实时性

 

UDP不存在粘包问题，是由于UDP发送的时候，没有经过Negal算法优化，不会将多个小包合并一次发送出去。另外，在UDP协议的接收端，采用了链式结构来记录每一个到达的UDP包，这样接收端应用程序一次recv只能从socket接收缓冲区中读出一个数据包。也就是说，发送端send了几次，接收端必须recv几次（无论recv时指定了多大的缓冲区）。