TCP的流式服务与拆包粘包

TCP的流式服务

客户端发送字节流时，tcp会保证服务器端按照顺序接受到全部的字节流，其他诸如数据包的大小等，tcp协议对我们来说是透明的，我们可以完全不考虑。我们发送数据和接受数据只用send或者recv函数，只需要关注其返回值，直到发送了多少数据或者接收到多少数据。其他的通通不管，在TCP通讯中，我们也不需要关心数据包的大小，个数，我们只需要在客户端建立一个缓冲区不断发送，在服务器端建立一个缓冲区不断的接收就ok了，当然我们也可以定义一个包头，来实现发送文件的强大功能。

字节流服务：发送端send()只是将数据写到TCP发送缓冲区中，然后将发送缓冲区中的数据打包成报文段发送出去。接收端又将接收到的报文段写到缓冲区中，最后recv()直接取数据。

字节流服务特点：数据没有明确分割（由底层做分割）,不分一定的报文段，什么时候想发便可将写入缓冲区的数据，进行打包再发送，即send()与recv()的次数没有必然联系。

数据报服务：发送端sendto()将数据直接打包成相对应的报文段发送。
数据报服务特点：数据有明确分割，拿数据按报文段拿。

Tcp的封装过程：

 

连续send两次，对方会接受几次

当每个socket建立后会有一个发送缓冲区和一个接收缓冲区，windows系统默认是8KB,send调用成功以后数据并没有立即发出去，而只是把发送的数据复制到发送缓冲区，由操作系统底层实现发送功能，发送到接受端的接收缓冲区。为了减轻网络负担，一般的TCP链接用了nagle算法，并不是发送缓冲区有数据就会发送的。 
   对于接收端来说，receive(char *buf,num)只是从接收缓冲区里面取数据，返回的值就是取得的数据大小。你多次send，如果数据量不大，而num的值超过了发送的总值，那么就会一次取完接受缓冲区的数据。

tcp 收发缓冲区值的设置
[root@ www.linuxidc.com]# cat /proc/sys/net/ipv4/tcp_rmem  
4096    87380   4161536
tcp接收缓冲区的默认值87380   最小值为4096   最大值为4161536
[root@ www.linuxidc.com]# cat /proc/sys/net/ipv4/tcp_wmem 
4096    16384   4161536
tcp 发送缓冲区的默认值16384   最小值为4096   最大值为4161536

粘包、拆包发生原因

发生TCP粘包或拆包有很多原因
1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

为什么会出现粘包？

由Nagle（内高）算法造成的发送端的粘包:Nagle算法是一种改善网络传输效率的算法.简单的说,当我们send一段数据给TCP发送时,TCP并不立刻发送此段数据,而是等待一小段时间,看看在等待期间是否还有要发送的数据,若有则会一次把这两段数据发送出去.这是对Nagle算法一个简单的解释

为什么TCP会有粘包拆包的问题而UDP没有

在socket网络程序中，TCP和UDP分别是面向连接和非面向连接的。因此TCP的socket编程，收发两端（客户端和服务器端）都要有成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小、数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。

对于UDP，不会使用块的合并优化算法，这样，实际上目前认为，是由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。所以UDP不会出现粘包问题。

粘包、拆包解决办法
解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。
等等。

测试的时候采用的是一台机器连续发送数据来模拟高并发的场景，所以在测试的时候会发现服务器端收到的数据包的个数经常会小于包的序号，好像发生了丢包。但经过仔细分析可以发现，这种情况是因为TCP发送缓存溢出导致的丢包，也就是这个数据包根本没有发出来。也就是说，发送端发送数据过快，导致接收端缓存很快被填满，这个时候接收端会把通知窗口设置为0从而控制发送端的流量，这样新到的数据只能暂存在发送端的发送缓存中，当发送缓存溢出后，就出现了我上面提到的丢包，这个问题可以通过增大发送端缓存来缓解这个问题。

 

既然保护消息边界和流是重点，那么什么是保护消息边界和流

保护消息边界，就是指传输协议把数据当作一条独立的消息在网上传输，接收端只能接收独立的消息。也就是说存在保护消息边界，接收端一次只能接收发送端发出的一个数据包。而面向流则是指无保护消息保护边界的，如果发送端连续发送数据，接收端有可能在一次接收动作中，会接收两个或者更多的数据包。

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

注意：

这就是因为UDP协议的保护消息边界使得每一个消息都是独立的。而流传输却把数据当作一串数据流，他不认为数据是一个一个的消息。所以有很多人在使用tcp协议通讯的时候，并不清楚tcp是基于流的传输，当连续发送数据的时候，他们时常会认识tcp会丢包。其实不然，因为当他们使用的缓冲区足够大时，他们有可能会一次接收到两个甚至更多的数据包，而很多人往往会忽视这一点，只解析检查了第一个数据包，而已经接收的其他数据包却被忽略了。所以大家如果要作这类的网络编程的时候,必须要注意这一点。

结论：

（1）TCP为了保证可靠传输，尽量减少额外开销（每次发包都要验证），因此采用了流式传输，面向流的传输，相对于面向消息的传输，可以减少发送包的数量，从而减少了额外开销。但是，对于数据传输频繁的程序来讲，使用TCP可能会容易粘包。当然，对接收端的程序来讲，如果机器负荷很重，也会在接收缓冲里粘包。这样，就需要接收端额外拆包，增加了工作量。因此，这个特别适合的是数据要求可靠传输，但是不需要太频繁传输的场合（两次操作间隔100ms，具体是由TCP等待发送间隔决定的，取决于内核中的socket的写法）

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

 

怎样封包和拆包

封包

封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了(以后讲过滤非法包时封包会加入"包尾"内容)。包头其实上是个大小固定的结构体，其中有个结构体成员变量表示包体的长度，这是个很重要的变量，其他的结构体成员可根据需要自己定义。根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。

拆包

对于拆包目前我最常用的方式：利用底层的缓冲区来进行拆包

由于TCP也维护了一个缓冲区,所以我们完全可以利用TCP的缓冲区来缓存我们的数据，这样一来就不需要为每一个连接分配一个缓冲区了。另一方面我们知道recv或者wsarecv都有一个参数,用来表示我们要接收多长长度的数据。利用这两个条件我们就可以对第一种方法进行优化。

对于阻塞SOCKET来说，我们可以利用一个循环来接收包头长度的数据，然后解析出代表包体长度的那个变量，再用一个循环来接收包体长度的数据。

编程实现见：http://blog.csdn.net/zhangxinrun/article/details/6721495

这个问题产生于编程中遇到的几个问题：

1、使用TCP的Socket发送数据的时候，会出现发送出错，WSAEWOULDBLOCK，在TCP中不是会保证发送的数据能够安全的到达接收端的吗？也有窗口机制去防止发送速度过快，为什么还会出错呢？

应该是你的缓冲区不够大,

2、TCP协议，在使用Socket发送数据的时候，每次发送一个包，接收端是完整的接受到一个包还是怎么样？如果是每发一个包，就接受一个包，为什么还会出现粘包问题，具体是怎么运行的？

tcp是流,没有界限.也就没所谓的包.

3、关于Send，是不是只有在非阻塞状态下才会出现实际发送的比指定发送的小？在阻塞状态下会不会出现实际发送的比指定发送的小，就是说只能出现要么全发送，要么不发送？在非阻塞状态下，如果之发送了一些数据，要怎么处理，调用了Send函数后，发现返回值比指定的要小，具体要怎么做？

阻塞也会出现这种现象,出现后继续发送没发送出去的.

4、最后一个问题，就是TCP/IP协议和Socket是什么关系？是指具体的实现上，Socket是TCP/IP的实现？那么为什么会出现使用TCP协议的Socket会发送出错。

tcp是协议,socket是一种接口,没必然联系.错误取决于你使用接口的问题,跟tcp没关系.

如何解决拆包粘包

既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：

1. 使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
2. 设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
3. 设置消息边界，服务端从网络流中按消息编辑分离出消息内容。

问题杂述：

问题1、粘包问题

解决方法一：TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；

解决方法二：发送固定长度的消息

解决方法三：把消息的尺寸与消息一块发送

解决方法四：双方约定每次传送的大小

解决方法五：双方约定使用特殊标记来区分消息间隔

解决方法六：标准协议按协议规则处理，如Sip协议

问题2、字符串编码问题

将中文字符串用utf8编码格式转换为字节数组发送时，一个中文字符可能会占用2～4个字节（假设为3个字节），这3个字节可能分3次接收，接收端每次接收完后用utf8编码格式转换为字符串，就会出现乱码，并导致接收长度计算错误的情况。

解决方法一：以字节数做为消息长度的计算单位，而不是字符个数。

解决方法二：发送方和接收方都采用unicode编码格式。

问题3、长连接的保活问题

标准TCP层协议里把对方超时设为2小时，若服务器端超过了2小时还没收到客户的信息，它就发送探测报文段，若发送了10个探测报文段（每一个相隔75S）还没有收到响应，就假定客户出了故障，并终止这个连接。因此应对tcp长连接进行保活。

以下是异步通信时会遇到的问题：

问题4、缓冲区脏数据问题

同步发送的拷贝，是直接拷贝数据到基础系统缓冲区，拷贝完成后返回；

异步发送消息的拷贝，是将Socket自带的Buffer空间内的所有数据，拷贝到基础系统发送缓冲区，并立即返回；

因此异步发送时缓冲区设置不好会导致接收到脏数据的问题，如下所示：

第一次发送数据：1234567890

第一次接受数据：1234567890

第二次发送数据：abc

第二次接受数据：abc4567890

请参考：http://www.cnblogs.com/tianzhiliang/archive/2010/09/08/1821623.html

解决方法一：将缓冲区的大小设置为实际发送数据的大小。

问题5、内存碎片问题

频繁的申请缓冲区会导致内存碎片的问题。

解决方法一：使用对象池和内存池。

请参考MSDN：http://msdn.microsoft.com/zh-cn/library/bb517542(v=vs.100).aspx

http://msdn.microsoft.com/zh-cn/library/system.net.sockets.socketasynceventargs.socketasynceventargs(v=vs.100).aspx

问题6、乱序问题

多个线程使用异步通信方式向同一个接收端(socket)同时发送数据，会导致接收端接收的数据混乱。如下所示：

线程1第一次发送：123456789，假设未发送完，只发送了123

线程2第一次发送：abcdefgh，假设未发送完，只发送了abc

线程1第二次发送：456789，发送完成

线程2第二次发送：defgh，发送完成

接收端最终接收的数据为：123abc456789defgh。

解决方法一：一个连接的发送端线程排队发送数据。

https://blog.csdn.net/zhangxinrun/article/details/6721495

 

参考：http://blog.csdn.net/zhangxinrun/article/details/6721427