python中TCP协议中的粘包问题
TCP协议中的粘包问题
1.粘包现象
基于TCP实现一个简易远程cmd功能
1 | #服务端 |
上述是基于TCP协议的远程cmd简单功能,在运行时会发生粘包。
2、什么是粘包?
只有TCP会发生粘包现象,UDP协议永远不会发生粘包;
TCP:(transport control protocol,传输控制协议)流式协议。在socket中TCP协议是按照字节数进行数据的收发,数据的发送方发出的数据往往接收方不知道数据到底长度是多长,而TCP协议由于本身为了提高传输的效率,发送方往往需要收集到足够的数据才会进行发送。使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
UDP:(user datagram protocol,用户数据报协议)数据报协议。在socket中udp协议收发数据是以数据报为单位,服务端和客户端收发数据是以一个单位,所以不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
TCP协议不会丢失数据,UDP协议会丢失数据。
udp的recvfrom是阻塞的,一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y>x数据就丢失,这意味着udp根本不会粘包,但是会丢数据,不可靠。
tcp的协议数据不会丢,没有收完包,下次接收,会继续上次继续接收,己端总是在收到ack时才会清除缓冲区内容。数据是可靠的,但是会粘包。
3、什么情况下会发生粘包?
1.由于TCP协议的优化算法,当单个数据包较小的时候,会等到缓冲区满才会发生数据包前后数据叠加在一起的情况。然后取的时候就分不清了到底是哪段数据,这是第一种粘包。
2.当发送的单个数据包较大超过缓冲区时,收数据方一次就只能取一部分的数据,下次再收数据方再收数据将会延续上次为接收数据。这是第二种粘包。
粘包的本质问题就是接收方不知道发送数据方一次到底发送了多少数据,解决问题的方向也是从控制数据长度着手,也就是如何设置缓冲区的问题
4、如何解决粘包问题?
解决问题思路:上述已经明确粘包的产生是因为接收数据时不知道数据的具体长度。所以我们应该先发送一段数据表明我们发送的数据长度,那么就不会产生数据没有发送或者没有收取完全的情况。
1.struct 模块(结构体)
struct模块的功能可以将python中的数据类型转换成C语言中的结构体(bytes类型)
1 | import struct |
2.粘包的解决方案基本版
既然我们拿到了一个可以固定长度的办法,那么应用struct模块,可以固定长度了。
为字节流加上自定义固定长度报头,报头中包含字节流长度,然后一次send到对端,对端在接收时,先从缓存中取出定长的报头,然后再取真实数据
1 | #服务器端 |
#总结:
1 | 服务器端: 1.在服务器端先收到命令,打开子进程,然后计算返回的数据的长度 2.先利用struct模块将数据长度转成固定4个字节传给客户端 3.再向客户端发送真实的数据。 客户端(两次接收): 1.第一次只接受4个字节,因为长度数据就是4个字节。这样防止了数据粘包。解码得到长度数据 2.第二次循环接收真实数据,拼接真实数据完成解码读取数据。 |
很显然,如果仅仅只是这样肯定无法满足在实际生产中一些需求。那么该怎么修改?
我们可以把报头做成字典,字典里包含将要发送的真实数据的详细信息,然后json序列化,然后用struck将序列化后的数据长度打包成4个字节(4个字节足够用了)
我们可以将自定义的报头设置成这种这种格式。
发送时:
1先发报头长度
2再编码报头内容然后发送
3最后发真实内容
接收时:
1先收报头长度,用struct取出来
2根据取出的长度收取报头内容,然后解码,反序列化
3从反序列化的结果中取出待取数据的详细信息,然后去取真实的数据内容
1 | #服务器端 |
总结:
1.TCP协议中,会产生粘包现象。粘包现象产生本质就是读取数据长度未知。
2.解决粘包现象本质就是处理读取数据长度。
3.报头的作用就是解决数据传输过程中数据长度怎么计算传达和传输其他额外信息的。