一 .基本概念：
什么是粘包
TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
长连接与短连接
1.长连接
Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。
2.短连接
Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点
通讯，比如多个Client连接一个Server.
二. TCP协议简介
TCP是一个面向连接的传输层协议，虽然TCP不属于ISO制定的协议集，但由于其在商业界和工业界的成功应用，它已成为事实上的网络标准，广泛应用于各种网络主机间的通信。
作为一个面向连接的传输层协议，TCP的目标是为用户提供可靠的端到端连接，保证信息有序无误的传输。它除了提供基本的数据传输功能外，还为保证可靠性采用了数据编号、校验和计算、数据确认等一系列措施。它对传送的每个数据字节都进行编号，并请求接收方回传确认信息（ACK）。发送方如果在规定的时间内没有收到数据确认，就重传该数据。
（1） 数据编号使接收方能够处理数据的失序和重复问题。
（2） 数据误码问题通过在每个传输的数据段中增加校验和予以解决，接收方在接收到数据后检查校验和，若校验和有误，则丢弃该有误码的数据段，并要求发送方重传。
（3） 流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，导致许多重传，造成网络拥塞恶性循环。
（4） TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。
TCP为用户提供了高可靠性的网络传输服务，但可靠性保障措施也影响了传输效率。因此，在实际工程应用中，只有关键数据的传输才采用TCP，而普通数据的传输一般采用高效率的UDP。
三.什么时候需要考虑粘包问题?
1:如果利用tcp每次发送数据，就与对方建立连接，然后双方发送完一段数据后，就关闭连接，这样就不会出现粘包问题（因为只有一种包结构,类似于http协议）。关闭连接主要要双方都发送close连接（参考tcp关闭协议）。如：A需要发送一段字符串给B，那么A与B建立连接，然后发送双方都默认好的协议字符如"hello
give me sth abour yourself"，然后B收到报文后，就将缓冲区数据接收,然后关闭连接，这样粘包问题不用考虑到，因为大家都知道是发送一段字符。
2：如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包
3：如果双方建立连接，需要在连接后一段时间内发送不同结构数据，如连接后，有好几种结构：那么需要考虑粘包问题
1)"hello give me sth abour yourself"
2)"Don't give me sth abour yourself"
那这样的话，如果发送方连续发送这个两个包出去，接收方一次接收可能会是"hello
give me sth abour yourselfDon't give me sth abour yourself" 这样接收方就傻了，到底是要干嘛？不知道，因为协议没有规定这么诡异的字符串，所以要处理把它分包，怎么分也需要双方组织一个比较好的包结构，所以一般可能会在头加一个数据长度之类的包，以确保接收。
又如：如果传送的是一个结构体，其内部为：typedef struct node
{ int a;
int b;
char c; }
接收数据时是将收到的数据按该结构体解析，如果第一次数据收到了int a,int b两部分，下一次收到char c 的时候仍是按该结构体的结构解析，即按int a方式解析，自然会产学生数据混乱。
四.粘包出现原因：
在流传输中出现，UDP不会出现粘包，因为它有消息边界(参考Windows 网络编程)
1 发送端需要等缓冲区满才发送出去，造成粘包
2 接收方不及时接收缓冲区的包，造成多个包接收
具体点：
1.Nagle算法导致的粘包：在使用一些协议通讯的时候，比如Telnet，会有一个字节字节的发送的情景，每次发送一个字节的有用数据，就会产生41个字节长的分组，20个字节的IP Header 和 20个字节的TCP Header，这就导致了1个字节的有用信息要浪费掉40个字节的头部信息，为了节省字节开销，Nagle就提出了一种通过减少需要通过网络发送包的数量来提高TCP/IP传输的效率，这就是Nagle算法，即TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个分组数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。
2.接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。
粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。
不是所有的粘包现象都需要处理，若传输的数据为不带结构的连续流数据（如文件传输），则不必把粘连的包分开（简称分包）。但在实际工程应用中，传输的数据一般为带结构的数据，这时就需要做分包处理。
在处理定长结构数据的粘包问题时，分包算法比较简单；在处理不定长结构数据的粘包问题时，分包算法就比较复杂。特别是粘在一起的包有不完整的包的粘包情况，由于一包数据内容被分在了两个连续的接收包中，处理起来难度较大。实际工程应用中应尽量避免出现粘包现象。
五.粘包解决办法：
如何处理粘包现象
（1）发送方
对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭Nagle算法。
（2）接收方
遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。
（3）应用层处理
应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。
解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？
如何区分一个整包消息，通常有如下五种做法：
1) 固定长度，例如每xxx 个字节代表一个整包消息，不足的前面补位。解码器在处理这类定常消息的时候比较简单，每次读到指定长度的字节后再进行解码；
2) 通过回车换行符区分消息，例如HTTP协议。这类区分消息的方式多用于文本协议；
3) 通过特定的分隔符区分整包消息；但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；
4) 通过在协议头/消息头中设置长度字段来标识整包消息。
5)通过协议号来确定解析协议的长度，由一个唯一协议标记就可以确定一个反序列化类，从而实现区分整包
六.保护消息边界和流
那么什么是保护消息边界和流呢?
保护消息边界，就是指传输协议把数据当作一条独立的消息在网上传输，接收端只能接收独立的消息。也就是说存在保护消息边界，接收端一次只能接收发送端发出的一个数据包。而面向流则是指无保护消息保护边界的，如果发送端连续发送数据，接收端有可能在一次接收动作中，会接收两个或者更多的数据包。
例如，我们连续发送三个数据包，大小分别是2k，4k ，8k,这三个数据包，都已经到达了接收端的网络堆栈中，如果使用UDP协议，不管我们使用多大的接收缓冲区去接收数据，我们必须有三次接收动作，才能够把所有的数据包接收完.而使用TCP协议，我们只要把接收的缓冲区大小设置在14k以上，我们就能够一次把所有的数据包接收下来，只需要有一次接收动作。
注意：
这就是因为UDP协议的保护消息边界使得每一个消息都是独立的。而流传输却把数据当作一串数据流，他不认为数据是一个一个的消息。所以有很多人在使用tcp协议通讯的时候，并不清楚tcp是基于流的传输，当连续发送数据的时候，他们时常会认识tcp会丢包。其实不然，因为当他们使用的缓冲区足够大时，他们有可能会一次接收到两个甚至更多的数据包，而很多人往往会忽视这一点，只解析检查了第一个数据包，而已经接收的其他数据包却被忽略了。所以大家如果要作这类的网络编程的时候,必须要注意这一点。
结论：
（1）TCP为了保证可靠传输，尽量减少额外开销（每次发包都要验证），因此采用了流式传输，面向流的传输，相对于面向消息的传输，可以减少发送包的数量，从而减少了额外开销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核中的socket的写法）
（2）UDP，由于面向的是消息传输，它把所有接收到的消息都挂接到缓冲区的接受队列中，因此，它对于数据的提取分离就更加方便，但是，它没有粘包机制，因此，当发送数据量较小的时候，就会发生数据包有效载荷较小的情况，也会增加多次发送的系统发送开销（系统调用，写硬件等）和接收开销。因此，应该最好设置一个比较合适的数据包的包长，来进行UDP数据的发送。（UDP最大载荷为1472，因此最好能每次传输接近这个数的数据量，这特别适合于视频，音频等大块数据的发送，同时，通过减少握手来保证流媒体的实时性）
七.TCP无保护消息边界的解决
针对这个问题，一般有3种解决方案：
(1)发送固定长度的消息
(2)把消息的尺寸与消息一块发送
(3)使用特殊标记来区分消息间隔
其解决方法具体解决可以参考：http://blog.csdn.net/zhangxinrun/article/details/6721427
本文转载于：https://www.cnblogs.com/qiaoconglovelife/p/5733247.html