Tcp是个“流协议”,所谓流,就是没有界限的一连串数据,没有界限。TCP底层不了解业务数据的含义,它会根据TCP缓冲区的实际情况进行包的划分,所以业务上认为,一个完整的包可能被TCP拆分为多个包进行发送,也可能把多个小包封装成一个大的数据包进行发送,这就是所谓的TCP粘包和拆包问题。
粘包/拆包问题说明
假设客户端分别发送了两个数据包,D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下情况:
- 服务端分别收到了D1和D2,没有粘包和拆包
- 服务端一次性收到了D1和D2,称为TCP粘包
- 服务端两次读取到了两个数据包,第一次读到了D1的完整部分和D2的部分数据,第二次读到了D2的剩余部分。 这称为TCP拆包
- 服务端两次读取到两个数据包,第一次是D1的部分,第二次是D1的剩余部分和D2的完整部分,也为TCP拆包
也有可能D1和D2非常大,期间发生多次拆包。
产生tcp粘包和拆包的原因
我们知道tcp是以流动的方式传输数据,传输的最小单位为一个报文段(segment)。tcp Header中有个Options(选项)字段,常见的字段为mss(Maximum Segment Size)指的是,连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit),一般是1500比特,超过这个量要分成多个报文段,mss则是这个最大限制减去TCP的header,光是要传输的数据的大小,一般为1460比特。换算成字节,也就是180多字节。
tcp为提高性能,发送端会将需要发送的数据发送到缓冲区,等待缓冲区满了之后,再将缓冲中的数据发送到接收方。同理,接收方也有缓冲区这样的机制,来接收数据。
发生TCP粘包、拆包主要是由于下面一些原因:
- 应用程序写入的数据大于套接字缓冲区大小,这将会发生拆包。
- 应用程序写入数据小于套接字缓冲区大小,网卡将应用多次写入的数据发送到网络上,这将会发生粘包。
- 进行mss(最大报文长度)大小的TCP分段,当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
- 接收方法不及时读取套接字缓冲区数据,这将发生粘包。
粘包、拆包解决办法
既然知道了tcp是无界的数据流,且协议本身无法避免粘包,拆包的发生,那我们只能在应用层数据协议上,加以控制。通常在制定传输数据时,可以使用如下方法:
1、发送端给每个数据包添加包首部,首部中应该至少包含数据包的长度,这样接收端在接收到数据后,通过读取包首部的长度字段,便知道每一个数据包的实际长度了。
补充:在tcp数据包处理的实战中,总会确定payload(数据部分)的长度,但是呢,tcp头部中没有确定的tcp_len长度。所以一般如下确定payload长度:从IP报头(IP .len)中提取“总长度”,然后减去“IP报头长度”(IP .hdr_len)和“TCP头长度”(TCP.hdr_len)。
2、发送端将每个数据包封装为固定长度(不够的可以通过补0填充),这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
3、可以在数据包之间设置边界,如添加特殊符号,这样,接收端通过这个边界就可以将不同的数据包拆分开,如在包尾增加回车换行符进行分割,FTP协议就是这样。