TCP协议中的粘包问题
1.粘包现象
基于TCP实现一个简易远程cmd功能
#服务端 import socket import subprocess sever = socket.socket() sever.bind(('127.0.0.1', 33521)) sever.listen() while True: client, address = sever.accept() while True: try: cmd = client.recv(1024).decode('utf-8') p1 = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr= subprocess.PIPE) data = p1.stdout.read() err_data = p1.stderr.read() client.send(data) client.send(err_data) except ConnectionResetError: print('connect broken') client.close() break sever.close() "color: #ff0000">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类型)
import struct s = 123456789 res = struct.pack('i', s) print(res) "htmlcode">#服务器端 import socket import subprocess import struct sever = socket.socket() sever.bind(('127.0.0.1', 33520)) sever.listen() while True: client, address = sever.accept() while True: try: cmd = client.recv(1024).decode('utf-8') #利用子进程模块启动程序 p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) #管道输出的信息有正确和错误的 data = p.stdout.read() err_data = p.stderr.read() #先将数据的长度发送给客户端 length = len(data)+len(err_data) #利用struct模块将数据的长度信息转化成固定的字节 len_data = struct.pack('i', length) #以下将信息传输给客户端 #1.数据的长度 client.send(len_data) #2.正确的数据 client.send(data) #2.错误管道的数据 client.send(err_data) except Exception as e: client.close() print('连接中断。。。。') break "htmlcode">#服务器端 import socket import subprocess import datetime import json import struct sever = socket.socket() sever.bind(('127.0.0.1', 33520)) sever.listen() while True: client, address = sever.accept() while True: try: cmd = client.recv(1024).decode('utf-8') #启动子进程 p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) #得到子进程运行的数据 data = p.stdout.read() #子进程运行正确的输出管道数据,数据读出来后是字节 err_data = p.stderr.read() #子进程运行错误的输出管道数据 #计算数据的总长度 length = len(data) + len(err_data) print('数据总长度:%s' % length) #先需要发送报头信息,以下为创建报头信息(至第一次发送) #需要添加时间信息 time_info = datetime.datetime.now() #设置一个字典将一些额外的信息和长度信息放进去然后json序列化,报头字典 masthead = {} #将时间数据放入报头字典中 masthead['time'] = str(time_info) #时间格式不能被json序列化,所以将其转化为字符串形式 masthead['length'] = length #将报头字典json序列化 json_masthead = json.dumps(masthead) #得到json格式的报头 # 将json格式的报头编码成字节形式 masthead_data = json_masthead.encode('utf-8') #利用struct将报头编码的字节的长度转成固定的字节(4个字节) masthead_length = struct.pack('i', len(masthead_data)) #1.发送报头的长度(第一次发送) client.send(masthead_length) #2.发送报头信息(第二次发送) client.send(masthead_data) #3.发送真实数据(第三次发送) client.send(data) client.send(err_data) except ConnectionResetError: print('客户端断开连接。。。') client.close() break #客户端 import socket import struct import json client = socket.socket() client.connect(('127.0.0.1', 33520)) while True: cmd = input('请输入cmd指令(Q\q退出):').strip() if cmd == 'q': break #发送CMD指令至服务器 client.send(cmd.encode('utf-8')) #1.第一次接收,接收报头信息的长度,由于struct模块固定长度为4字节,括号内直接填4 len_masthead = client.recv(4) #利用struct反解报头长度,由于是元组形式,取值得到整型数字masthead_length masthead_length = struct.unpack('i', len_masthead)[0] #2.第二次接收,接收报头信息,接收长度为报头长度masthead_length 被编码成字节形式的json格式的字典, # 解字符编码得到json格式的字典masthead_data masthead_data = client.recv(masthead_length).decode('utf-8') #得到报头字典masthead masthead = json.loads(masthead_data) print('执行时间%s' % masthead['time']) #通过报头字典得到数据长度 data_length = masthead['length'] #3.第三次接收,接收真实数据,真实数据长度为data_length # data = client.recv(data_length) #有可能真实数据长度太大会撑爆内存。 #所以循环读取数据 all_data = b'' length = 0 #循环直到长度大于等于数据长度 while length < data_length: data = client.recv(1024) length += len(data) all_data += data print('数据的总长度:%s' % data_length) #我的电脑是Windows系统,所以用gbk解码系统发出的信息 print(all_data.decode('gbk'))总结:
1.TCP协议中,会产生粘包现象。粘包现象产生本质就是读取数据长度未知。
2.解决粘包现象本质就是处理读取数据长度。
3.报头的作用就是解决数据传输过程中数据长度怎么计算传达和传输其他额外信息的。
以上所述是小编给大家介绍的python中TCP协议中的粘包问题详解整合,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对网站的支持!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
稳了!魔兽国服回归的3条重磅消息!官宣时间再确认!
昨天有一位朋友在大神群里分享,自己亚服账号被封号之后居然弹出了国服的封号信息对话框。
这里面让他访问的是一个国服的战网网址,com.cn和后面的zh都非常明白地表明这就是国服战网。
而他在复制这个网址并且进行登录之后,确实是网易的网址,也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情,因为以前都没有出现这样的情况,现在突然提示跳转到国服战网的网址,是不是说明了简体中文客户端已经开始进行更新了呢?
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]