今日内容总结

粘包现象

1.服务器连续执行三次recv
2.客服端连续执行三次send
'''
	我们代码想要实现的效果是每一次输入和获取都一一对应上
'''
# 执行效果：三次的输入结果都被一个输出结构接收
>>>服务端一次性接收到了客户端三次的消息 该现象称为"黏包现象"

粘包现象产生的原因
	1.不知道每次的数据的数据有多大
    2.TCP也称流水协议:数据就像水流一样绵绵不绝没有间隔(TCP会针对数据量较小且发送间隔较短的多条数据一次性合并打包发送)
        
避免粘包现象的核心思路\关键点
	如何获取到即将接受的数据的大小
    
ps：怎么将数据的长度变成全部制作成固定的长度

struct模块

import struct

info = b'hello world'
print(len(info)) #获取到数据的真实长度 >>> 11
res = struct.pack('i',len(info)) # 将数据打包成固定长度 i模式
print(len(res))  # 打包后的固定长度是4(bytes)>>> 报头
real_len = struct.unpack('i',res)
print(real_len) # 获取真实的长度 打印出的结果是一个元组 (11,)

'''
解决粘包问题的初级版本
	客户端
		1.将真实数据转成bytes类型并计算长度
		2.利用struct模块将真实长度制作一个固定长度的长度
		3.将固定的长度的报头先发送给服务端 服务端再通过报头获取到真实的长度 然后再填写固定的长度就行
		4.然后再发送真实的数据
		
	服务段
		1.服务端先接收固定长度的报头
		2.利用struct模块反向解析出真实数据长度
		3.recv接收真实数据长度即可
'''
#问题一：struct模块无法打包数据量较大的数据 就算更换模式也不行
res = struct.pack('i',1231546415)
print(res) #>>>直接报错
#问题二：报头只能传递数据的长度无法获取到其他信息

'''终极解决方案:字典作为报头打包 效果更好 数字更小'''
data_dict = {
    'fale_name':'某某电影简介.avi',
    'file_size':15345121565453531321135,
    'file_info':'满满干货'
}
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.接收真实的数据长度
'''

struct中含有的多种模式

怎么解决粘包现象

'''服务端'''
import socket
import struct
import json

server = socket.socket()
server.bind(('127.0.0.1',8081))
server.listen(5)

sock,addr = server.accpet()
#1.接收固定长度的字典报头
data_dict_hand = sock.recv(4)
#2.根据报头解析出字典数据的长度
data_dict_len = struct.uppack('i',data_dict_hand)[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:
    while recv_size < total_size:
        data = sock.recv(1024)
        f.write(data)
        recv_size += len(data)
'''以1024个字节为单位来读取数据 缓解压力'''


'''客户端'''

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'绝对路径')
# 2.制作真实数据的字典数据
data_size = {
    'file_name':'文件名.后缀名',
    '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)
# 5.发送字典
client.send(data_dict_bytes)
# 6.发送真实的数据
with open(r'绝对路径','rb')as f:
    for line in f:
        #一行行发送 和直接一起发效果一样 因为TCP流式协议的特性
        client.send(line)
import time
time.sleep(10)
# 让客服端不要立马断开通道 等数据传过去后再断

UDP基本代码使用

1.UDP服务端和客户端'各自玩各自的'
2.UDP不会出现多个消息发送合并
# 由于UDP的特性 所以基本有关聊天的软件都是使用UDP的

并发编程理论之操作系统发展史

研究网络编程其实就是在研究计算机的底层原理及发展史

'''
计算机中真正干活的是>>>cpu
'''
操作系统发展史
	1.穿孔卡片阶段
  	计算机很庞大 使用很麻烦 一次只能给一个人使用 期间很多时候计算机都不工作
    	好处:程序员独占计算机 为所欲为
  		坏处:计算机利用率太低 浪费资源
 	2.联机批处理系统
  	提前使用磁带一次性录入多个程序员编写的程序 然后交给计算机执行
    	CPU工作效率有所提升 不用反复等待程序录入
	3.脱机批处理系统
  	极大地提升了CPU的利用率
	总结:CPU提升利用率的过程

多道技术

'''
在学习并发编程的过程中 不做可以提醒的情况下 默认一台计算机就一个CPU
'''
单道技术
	所有的程序排队执行 过程中不能重合
多道技术
	利用空闲时间提前准备其他数据 最大化利用CPU利用率
    
多道技术详细
	1.切换
    计算机的CPU在两种情况下会切换(不让你用 给别人用)
    	1.程序有IO操作
        输出\输出操作
        	input time.sellp read write
        2.程序长时间占用CPU
        我们得与雨露均沾 让每一个程序都能被CPU运行一下
        
    2.保存状态
    	CPU每次切换走之前都需要保存当前得操作状态 下次切换回来基于上次的进度继续执行
'''
开了一家饭店 只有一个服务员 但是同时来了五桌的客人
	请问:如何让五桌客人都感觉到服务员在服务他们
		让服务员化身为闪电侠 只要有客人停顿 就立刻切换到其他桌
'''

进程理论及调度算法

进程与程序的区别
	程序：一堆死代码(还没有被运行起来)
	进程：正在运行的程序(被运行起来了)
    
进程的调度算法(重要)
	1.FCFS(先来先服务)
  	对短作业不友好
	2.短作业优先调度
  	对长作业不友好
	3.时间片轮转法+多级反馈队列(目前还在用)
  	将时间均分 然后根据进程时间长短再分多个等级
    等级越靠下表示耗时越长 每次分到的时间越多 但是优先级越低

进程的并行与并发

并行
	多个进程同时执行 必须要有多个cpu参与 单个cpu无法实现并行
并发
	多个进程看上去像同时执行 单个cpu可以实现 多个cpu肯定也可以
    
判断下列两句话孰对孰错
	我写的程序很牛逼，运行起来之后可以实现14个亿的并行量(×)
  	并行量必须要有对等的CPU才可以实现
  我写的程序很牛逼，运行起来之后可以实现14个亿的并发量(√)
  	合情合理 完全可以实现	以后我们的项目一般都会追求高并发
ps:目前国内可以说是最牛逼的>>>:12306

进程的三状态

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

原文地址：http://www.cnblogs.com/xiaochenxiangchangpang/p/16900934.html