黏包现象产生与tcp协议的通信中
1.服务端连续执行三次recv
2.客户端连续执行三次send
问题:服务端一次性接收到了客户端三次的消息 该现象称为"黏包现象"

黏包现象产生的原因:
	1.不知道每次的数据到底多大
	2.TCP也称为流式协议:数据像水流一样绵绵不绝没有间隔(TCP会针对数据量较小且发送间隔较短的多条数据一次性合并打包发送)
所以问题就在于如何得知一次send 到底传输的数据量的大小?

我们无法得知即将接受的数据量有多大。所以需要让客户端统计数据包大小，先提前告知服务端即将传来的数据大小。
避免黏包现象的核心思路\关键点:

如何明确即将接收的数据具体有多大

如何将长度变化的数据全部制作成固定长度的数据

import struct
info = b'hello big baby'

print(len(info))  # 数据真实的长度(bytes)  14

res = struct.pack('i', len(info))  # 将数据打包成固定的长度 i是固定的打包模式

print(len(res))  # 打包之后长度为(bytes)   4           报头
real_len = struct.unpack('i', res)

print(real_len)  # (14,)             根据固定长度的报头 解析出真实数据的长度
desc = b'hello my baby I will take you to play big ball'

print(len(desc))  # 数据真实的长度(bytes)  46

res1 = struct.pack('i', len(desc))

print(len(res1))  # 打包之后长度为(bytes)  4           报头
real_len1 = struct.unpack('i', res1)

print(real_len1)  # (46,)              根据固定长度的报头 解析出真实数据的长度

# 1.必须传入整数类型
import struct
info = b'hello big baby'  # 将要传输的信息
res = struct.pack('i', info)  # 打包信息产生报头  # 这里会失败  # struct.error: required argument is not an integer
'''struct.pack(打包的模式，将要传输的信息的字节数）'''

# 2.打包后的报头为bytes类型 且 字节数固定为4
import struct
info = b'hello big baby'

res = struct.pack('i', len(info))

print(res, type(res), len(res))  # b'\x0e\x00\x00\x00' <class 'bytes'> 4

# 3.unpack方法的使用

import struct

info = b'hello big baby'

res = struct.pack('i', len(info))

unpack = struct.unpack('i', res)

print(unpack)  # (14,)  # 结果是一个元祖

'''问题:struct模块无法打包数据量较大的数据 就算换更大的模式也不行'''
import struct
res = struct.pack('i', 12312222222233)  # struct.error: argument out of range
'''问题2:报头能否传递更多的信息  比如电影大小 电影名称 电影评价 电影简介'''

'''终极解决方案:字典作为报头打包 效果更好 数字更小'''
import struct
data_dict = {

'file_name': 'xxx老师教学.avi',

'file_size': 123132131232342342423423423423432423432,

'file_info': '内容很精彩 千万不要错过',

'file_desc': '一代神作 私人珍藏'

}

import json

data_json = json.dumps(data_dict)

print(len(data_json.encode('utf8')))  # 真实字典的长度  252

res = struct.pack('i', len(data_json.encode('utf8')))

print(len(res))  # 4

黏包问题终极方案

客户端

1.制作真实数据的信息字典(数据长度、数据简介、数据名称)

2.利用struct模块制作字典的报头

3.发送固定长度的报头(解析出来是字典的长度)

4.发送字典数据

5.发送真实数据

服务端

1.接收固定长度的字典报头

2.解析出字典的长度并接收

3.通过字典获取到真实数据的各项信息

4.接收真实数据长度

'''发送端'''
import socket
import os
import struct
import json
client = socket.socket()

client.connect(('127.0.0.1', 8081))
'''任何文件都是下列思路 图片 视频 文本 ...'''

# 1.获取真实数据大小

file_size = os.path.getsize(r'/Users/jiboyuan/PycharmProjects/day36/xx老师合集.txt')

# 2.制作真实数据的字典数据

data_dict = {

'file_name': '有你好看.txt',

'file_size': file_size,

'file_desc': '内容很长 准备好吃喝 我觉得营养快线挺好喝',

'file_info': '这是我的私人珍藏'

}

# 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)  # 报头本身也是bytes类型 我们在看的时候用len长度是4

# 5.发送字典

client.send(data_dict_bytes)

# 6.最后发送真实数据

with open(r'/Users/jiboyuan/PycharmProjects/day36/xx老师合集.txt', 'rb') as f:

for line in f:  # 一行行发送 和直接一起发效果一样 因为TCP流式协议的特性

client.send(line)

import time

time.sleep(10)

'''接受端'''

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]

# 3.接收字典数据

data_dict_bytes = sock.recv(data_dict_len)

data_dict = json.loads(data_dict_bytes)  # 自动解码再反序列化

# 4.获取真实数据的各项信息

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)

1.UDP服务端和客户端'各自玩各自的'
2.UDP不会出现多个消息发送合并
3.UDP不会黏包 recvfrom(1024) 超过指定的字节数时 超过的部分就丢弃 传几次就接受几次

'''
饭店只有一个服务员 但是同时来了五桌客人
请问：如何让五桌客人都感觉服务员在服务它们？
拿菜单让客人看！客人看的时候 去给别人点菜！只要有空闲 就立即切换到其他桌 如此往复。
'''

计算机的CPU在两种情况下会切换
此时被切换的程序会被剥夺cpu的使用权,在原地停着:
# 1.程序有IO操作 输入\输出操作

比如：input、time.sleep、read、write

# 2.程序长时间占用cpu

我们得让多个程序都能被cpu运行起来 雨露均沾

cpu光会不停切换还是不够的
cpu每次切换走之前都需要保存当前操作的状态 下次切换回来基于上次的进度继续执行
'''比如你做饭时遇到有客人敲门 ---> 做菜 开门 接着做菜'''
CPU很快 能让人产生错觉 是好多服务员在服务客人

时间片轮转(Round Robin，RR)法的基本思路是让每个进程在就绪队列中的等待时间与享受服务的时间成比例。在时间片轮转法中，需要将CPU的处理时间分成固定大小的时间片，例如，几十毫秒至几百毫秒。如果一个进程在被调度选中之后用完了系统规定的时间片，但又未完成要求的任务，则它自行释放自己所占有的CPU而排到就绪队列的末尾，等待下一次调度。同时，进程调度程序又去调度当前就绪队列中的第一个进程。
      显然，轮转法只能用来调度分配一些可以抢占的资源。这些可以抢占的资源可以随时被剥夺，而且可以将它们再分配给别的进程。CPU是可抢占资源的一种。但打印机等资源是不可抢占的。由于作业调度是对除了CPU之外的所有系统硬件资源的分配，其中包含有不可抢占资源，所以作业调度不使用轮转法。
在轮转法中，时间片长度的选取非常重要。首先，时间片长度的选择会直接影响到系统的开销和响应时间。如果时间片长度过短，则调度程序抢占处理机的次数增多。这将使进程上下文切换次数也大大增加，从而加重系统开销。反过来，如果时间片长度选择过长，例如，一个时间片能保证就绪队列中所需执行时间最长的进程能执行完毕，则轮转法变成了先来先服务法。时间片长度的选择是根据系统对响应时间的要求和就绪队列中所允许最大的进程数来确定的。
      在轮转法中，加入到就绪队列的进程有3种情况：
      1. 一种是分给它的时间片用完，但进程还未完成，回到就绪队列的末尾等待下次调度去继续执行。
      2. 另一种情况是分给该进程的时间片并未用完，只是因为请求I/O或由于进程的互斥与同步关系而被阻塞。当阻塞解除之后再回到就绪队列。
      3. 第三种情况就是新创建进程进入就绪队列。
      如果对这些进程区别对待，给予不同的优先级和时间片从直观上看，可以进一步改善系统服务质量和效率。例如，我们可把就绪队列按照进程到达就绪队列的类型和进程被阻塞时的阻塞原因分成不同的就绪队列，每个队列按FCFS原则排列，各队列之间的进程享有不同的优先级，但同一队列内优先级相同。这样，当一个进程在执行完它的时间片之后，或从睡眠中被唤醒以及被创建之后，将进入不同的就绪队列。  

前面介绍的各种用作进程调度的算法都有一定的局限性。如短进程优先的调度算法，仅照顾了短进程而忽略了长进程，而且如果并未指明进程的长度，则短进程优先和基于进程长度的抢占式调度算法都将无法使用。
而多级反馈队列调度算法则不必事先知道各种进程所需的执行时间，而且还可以满足各种类型进程的需要，因而它是目前被公认的一种较好的进程调度算法。在采用多级反馈队列调度算法的系统中，调度算法的实施过程如下所述。
(1) 应设置多个就绪队列，并为各个队列赋予不同的优先级。第一个队列的优先级最高，第二个队列次之，其余各队列的优先权逐个降低。该算法赋予各个队列中进程执行时间片的大小也各不相同，在优先权愈高的队列中，为每个进程所规定的执行时间片就愈小。例如，第二个队列的时间片要比第一个队列的时间片长一倍，……，第i+1个队列的时间片要比第i个队列的时间片长一倍。
(2) 当一个新进程进入内存后，首先将它放入第一队列的末尾，按FCFS原则排队等待调度。当轮到该进程执行时，如它能在该时间片内完成，便可准备撤离系统；如果它在一个时间片结束时尚未完成，调度程序便将该进程转入第二队列的末尾，再同样地按FCFS原则等待调度执行；如果它在第二队列中运行一个时间片后仍未完成，再依次将它放入第三队列，……，如此下去，当一个长作业(进程)从第一队列依次降到第n队列后，在第n 队列便采取按时间片轮转的方式运行。
(3) 仅当第一队列空闲时，调度程序才调度第二队列中的进程运行；仅当第1～(i-1)队列均空时，才会调度第i队列中的进程运行。如果处理机正在第i队列中为某进程服务时，又有新进程进入优先权较高的队列(第1～(i-1)中的任何一个队列)，则此时新进程将抢占正在运行进程的处理机，即由调度程序把正在运行的进程放回到第i队列的末尾，把处理机分配给新到的高优先权进程。
多级反馈队列

# 就绪态
	所有的进程在被cpu执行之前都必须先进入就绪态等待
# 运行态
	cpu正在执行
# 阻塞态
	进程运行过程中出现了IO操作 阻塞态无法直接进入运行态 需要先进入就绪态

在了解其他概念之前，我们首先要了解进程的几个状态。在程序运行的过程中，由于被操作系统的调度算法控制，程序会进入几个状态：就绪，运行和阻塞。
　　（1）就绪(Ready)状态
　　当进程已分配到除CPU以外的所有必要的资源，只要获得处理机便可立即执行，这时的进程状态称为就绪状态。
　　（2）执行/运行（Running）状态当进程已获得处理机，其程序正在处理机上执行，此时的进程状态称为执行状态。
　　（3）阻塞(Blocked)状态正在执行的进程，由于等待某个事件发生而无法执行时，便放弃处理机而处于阻塞状态。引起进程阻塞的事件可有多种，例如，等待I/O完成、申请缓冲区不能满足、等待信件(信号)等。

# 并行
多个进程同时执行 必须要有多个CPU参与 
单个CPU无法实现并行
eg:两人比赛赛跑
>>> 真正意义上的同时运行两个程序 一个cpu负责一个程序
# 并发 
多个进程看上去像同时执行 单个CPU可以实现 多个CPU肯定也可以
eg:一个服务员服务多个客人
>>> cpu在两个程序之间快速切换
请判断下列两句话孰对孰错：

我写的程序很牛逼，运行起来之后可以实现14个亿的并行量 要14个亿的CPU 并行量必须要对等的cpu实现

我写的程序很牛逼，运行起来之后可以实现14个亿的并发量 一个cpu够吗
以后我们的项目会追求高并发。

一个服务同时服务（切换）很多客人 并发！
ps：国内最牛逼的>>>:12306

能抗的并发量很大 一个服务员来回切换几百个人没问题!