今日内容
黏包现象
1.服务端连续三次执行recv
2.客户端连续三次执行send
问题:服务端一次性接收到了客户端三次消息 该现象称为"黏包现象"
黏包现象产生的原因
1.不知道每次的数据到底多大
2.TCP也称为流式协议:数据像水流一样绵绵不绝没有间隔(TCP会针对数据量较小且发送间隔较短的多条数据一次性合并打包发送)
避免黏包现象的核心思路/关键点
如何明确即将接收的数据具体多大
ps:如何将长度变化的数据全部制作成固定长度的数据
struct模块
import struct
import struct
info = b'hello joyce'
res = struct.pack('i',len(info))
#将数据打包成固定的长度 ’i‘ 固定长度是 4 报头
print(res)
#打包之后长度为 bytes 4
real_len = struct.unpack('i',res)
print(real_len)
#(11,) 根据固定长度的报头 解析出真实数据的长度
字节长
import struct
desc = b'hello joyce you are very beautiful'
print(len(desc))
res1 = struct.pack('i',len(desc))
print(len(res1))
real_len = struct.unpack('i',res1)
print(real_len)
'''
解决黏包问题初次版本
客户端
1.将真实数据转成bytes类型并计算长度
2.利用struct模块将真是长度制作一个固定长度的报头
3.将固定长度的把头先发送给服务端 服务端只需要在recv括号内填写固定长度的报头数字即可
4.然后在发送真实数据
服务端
1.服务端先接收固定长度的报头
2.利用struct模块反向解析出真实数据长度
3.recv接收真实数据长度即可
'''
'''问题1:struct 模块无法打包数据量较大的数据 就算换更大的模式也不行'''
# res = struct.pack('i', 12313213123)
# print(res)
'''问题2:报头能否传递更多信息 比如电影大小 电影名称 电影评价 电影简介'''
'''终极解决方案:字典作为报头打包 效果更好 数字更小'''
data_dict = {
'file_name':'xxx电影',
'file_size':1235643,
}
import json
data_json = json.dumps(data_dict)
print(len(data_json.encode('utf8')))
res = struct.pack('i',len(data_json.encode('utf8')))
print(len(res))
'''
黏包问题终极方案
客户端
1.制作真实数据的信息字典(数据长度、数据简介、数据名称)
2.利用struct模块制作字典的报头
3.发送固定长度的报头
4.发送字典数据
5.发送真实数据
服务端
1.接收固定长度的字典报头
2.解析出字典的长度并接收
3.通过字典获取倒真是数据的各项信息
4.接收真实数据长度
'''
黏包代码实战
import socket
import struct
import json
server = socket.socket()
server.bind(('127.0.0.1', 8081))
server.listen(5)
sock,addr = server.accept()
#1.接收固定长度的字典报头
data_dict_head= sock.recv(4)
#2.接收报头解析出字典数据的长度
data_dict_len = struct.unpack('i',data_dict_head)[0]
data_dict_bytes = sock.recv(data_dict_len)#自动化解码再反序列化
#获取真实数据的各项信息
total_size = data_dict.get('file_size')
with open(data_dict.get('file_name'),'wb')as f:
f.write(sock.recv(total_size))
'''接收真实数据的时候 如果数据量非常大 recv括号内直接填写该数据量 不太合适 我们可以每次接收一点点 反正直到总长度'''
total_size = data_dict.get('file_size')
recv_size = 0
with open(data_dict.get('file_name'),'wb')as f:
while recv_size < total_size:
data = sock.recv(1024)
f.write(data)
recv_size += len(data)
print(recv_size)
import socket
import os
import struct
import json
client = socket.socket()
client.connect(('192.168.1.186', 8088))
'''任何文件都是下列思路 图片 视频 文本'''
#1.获取真实数据大小
file_size= os.path.getsize(r'C:\Users\李宗月\Pictures\Saved Pictures\沈腾.jpg')
#2.制作真实数据的字典数据
data_dict = {
'file_name':'沈腾.jpg',
'file_size':file_size,
}
#3.制作字典的报头
data_dict_bytes = json.dumps(data_dict).encode('utf8')
data_dict_len = struct.pack('i',len(data_dict_bytes))
#4.发送字典报头-
client.send(data_dict_len)
client.send(data_dict_bytes)
#5.最后发送真实数据
with open(r'C:\Users\李宗月\Pictures\Saved Pictures\沈腾.jpg','rb')as f:
for line in f: #一行一行发送和直接一起发效果一样 因为TCP流式协议的特性
client.send(line)
import time
time.sleep(10)
UDP协议(了解)
1.UDP服务端喝客服端'各自玩各自的'
2.UDP不会出现多个消息发送合并
并发编程理论
'''计算机中真正干活的是CPU'''
操作系统发展史
1.穿孔卡片阶段
计算机很庞大 使用很麻烦 一次只能给一个人使用 期间很多时候计算机都不工作
好处:程序员独占计算机 为所欲为
坏处:计算机利用率太低 浪费资源
2.练级批处理系统
提前使用磁带一次性录入多个程序员编写的程序 然后交给计算机执行 cpu工作效率有所提升 不用反复等待程序录入
3.脱机批处理系统
极大地提升了cpu的利用率
总结:CPU提升利用率的过程
多道技术
'''
在学习并发编程的过程中 不做可以提醒的情况下 默认一台计算机就一个CPU(只有一个干活的人)
'''
单道技术:
所有的程序排队执行 过程中不能重合
多道技术:
利用空闲时间提前准备其他数据 最大化提升CPU利用率
多道技术详细
1.切换
计算机的CPU在两种情况下会切换(不让你用 给别人用)
1.程序有IO操作
input、time.sleep、read、write
2.程序长时间占用CPU
我们得雨露均沾 让多个程序都能被CPU运行一下
2.保存状态
cpu每次切换走之前都需要保存当前操作的状态 下次切回来基于上一次的进度继续执行
'''
开了一家饭店 只有一个服务员 但是同时来了五桌客人
请问:如何让污浊客人都感觉到服务员在服务他们
让服务员化身闪电侠 只要客人有停顿 就立刻换到其他桌 如此往复
'''
进程理论
进程与程序的区别
程序:一堆死代码(还没有被运行起来)
进程:正在运行的程序(被运行起来了)
进程的调度算法(重要)
1.FCFS(先来先服务)
对短作业不友好
2.短作业优先调度
对长作业不友好
3.时间片轮转法+多级反馈队列(目前还在用)
将时间均分 然后根据进程时间长短再分多个等级
等级越靠下表示耗时越长 每次分到的时间越多 但是优先级越低
进程理论进程的并行与并发
并行
多个程序同时执行 必须要有多个CPU参与 单个CPU无法实现并行
并发
多个进程看上去像同时执行 单个CPU可以实现 多个肯定也可以
进程的三种状态
就绪态
所有的进程在被CPU执行之前都必须先进入就绪态等待
运行态
CPU正在执行
阻塞态
进程运行过程中出现了IO操作 阻塞态无法直接进入运行态 需要先进去就绪态
标签:struct,黏包,len,dict,进程,报头,data,size
From: https://www.cnblogs.com/lzy199911/p/16900473.html