python之路29 网络编程基础2之 两种架构 传输层常见协议 socket模块

软件开发架构

1.C/S架构(Client:客户端和Server:服务端)
    服务器-客户机，即Client-Server(C/S)结构。C/S结构通常采取两层结构。服务器负责数据的管理，客户机负责完成与用户的交互任务。
2.B/S架构(Browser:浏览器和Server:服务器)
    是目前应用系统的发展方向，BS是伴随着Internet技术的兴起，对C/S架构的改进，为了区别于传统的C/S 模式，特意称为B/S模式。在这种结构下，通过W3浏览器来进入工作界面，极少部分事务逻辑在前端（Browser）实现，主要事务逻辑在服务器端（Server）实现，形成三层（3-tier）结构。这样使得客户端电脑负荷大大简化（因此被称为瘦客户端），减轻了系统维护、升级的支出成本，降低了用户的总体成本（TCO）。客户机上只要安装一个浏览器，如Chrome、Safari、Microsoft Edge、Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互
优劣之分:
"""
C/S架构
	优势:不同公司的客户端由不同公司独立开发 可以高度定制化客户端功能
	劣势:需要下载才能使用
（1）优点：
　　●能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，所以CS客户端响应速度快。

　　●操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。  

　　●C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。
　　●安全性能可以很容易保证，C/S一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S结构适宜。
（2）缺点：
　　●需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。

　　●兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。  

　　●开发、维护成本较高，需要具有一定专业水准的技术人员才能完成，发生一次升级，则所有客户端的程序都需要改变。。
　　●用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户，所以适用面窄，通常用于局域网中。
B/S架构
	优势:不用下载直接访问
	劣势:无法高度定制化 并且需要遵守很多规则
（1）优点：

　　●分布性强，客户端零维护。只要有网络、浏览器，可以随时随地进行查询、浏览等业务处理。 

　　●业务扩展简单方便，通过增加网页即可增加服务器功能。  

　　●维护简单方便，只需要改变网页，即可实现所有用户的同步更新。 

　　●开发简单，共享性强。

（2）缺点：

　　●个性化特点明显降低，无法实现具有个性化的功能要求。 

　　●在跨浏览器上，BS架构不尽如人意。

　　●客户端服务器端的交互是请求-响应模式，通常动态刷新页面，响应速度明显降低（Ajax可以一定程度上解决这个问题）。无法实现分页显示，给数据库访问造成较大的压力。 

　　●在速度和安全性上需要花费巨大的设计成本。

　　●功能弱化，难以实现传统模式下的特殊功能要求。
PS:CS响应速度快，安全性强，一般应用于局域网中，但是开发维护成本高；BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构。
"""

网络编程前戏

1.什么是网络编程
	基于网络编写代码 能够实现数据的远程交互
2.学习网络编程的目的
	能够开发cs架构的软件
3.网络编程的起源
"""
  最早起源于美国军事领域
  想实现计算机之间数据的交互
  最早的时候只能用硬盘拷贝
  之后发明了网络编程
"""
4.网络编程必备条件
数据的远程交互
1.早期的电话
     电话线
2.早期的大屁股电脑
     网线
3.笔记本电脑、移动电话
     网卡
ps:实现数据的远程交互必备的基础条件是物理连接介质

网络编程常见协议

TCP与UDP都是用来规定通信方式的
	通信的时候可以随心所欲的聊 也可以遵循一些协议符合要求的聊
    随心所欲的聊:文字 图片 视频 小油腻话你侬我侬
    遵循一些协议:开头带尊称 首行空两格
PS:不遵循协议也可以通信 只不过遵循了更合规合法合理!!!!
1.TCP协议(重要)
	三次握手建链接
    1.TCP协议也称为可靠协议(数据不容易丢失)
       造成数据不容易丢失的原因不是因为有双向通道 而是因为有反馈机制
       给对方发消息之后会保留一个副本 直到对方回应消息收到了才会删除
    否则会在一定的时间内反复发送
   	2.洪水攻击
      同一时间有大量的客户端请求建立连接 会导致服务端一致处于SYN_RCVD状态
    3.服务端如何区分客户端建立链接的请求
      可以对请求做唯一标识
四次挥手断链接
    1.四次不能合并为三次
        因为中间需要确认消息是否发完(TIME_WAIT)
"""
三次握手和四次挥手也可以看成是小情侣谈恋爱的过程
     三次握手: 表白在一起
     四次挥手: 决裂要分手
"""
PS:课下可以深入研究一下TCP图片上每个状态的具体情况
2.UDP协议
	也称之为数据报协议、不可靠协议
    早期的QQ使用的是纯生的(没有加任何额外功能)UDP协议
    现在的QQ自己添加了很多技术和功能
      使用UDP的原因是因为很简单、快捷、粗暴、只要指定对方的地址就可以发消息了
"""
TCP我们可以看成是打电话:双方你侬我侬
UDP我们可以看成是发短信:只要发了就行 不管对方看不看
"""
IP协议:规定了接入互联网的计算机都必须有一个ip地址
        ipv4点分十进制 数量有限
        ipv6冒分十六进制 能够宝石地球上的每一粒沙子
特征: IP能够标识出地球上独一无二的一台接入互联网的计算机
"""
ARP协议:能够根据IP地址动态解析到一个MAC地址
"""
PORT协议:计算机通过端口号管理正在运行的诸多应用程序

网络相关专业名词

1.交换机
	能够将所有接入交换机的计算机彼此互联起来
2.广播
	首次查找接入同一个交换机的其他计算机 需要朝交换机里面吼一嗓子
3.单播
	首次被查找的计算机回应查找它的计算机 并附带自己的mac地址
4.广播风暴
	接入同一台交换机的多台计算机同时发广播
5.局域网
	可以简单的理解为有单个交换机组成的网络
	在局域网内可以直接使用mac地址通信
6.广域网
	可以简单的理解为范围更大的局域网
7.互联网
	由所有的局域网、广域网连接到一起形成的网络
8.路由器
	不同的局域网计算机之间是无法直接实现数据交互的 需要路由器连接

socket概念

socket层

理解socket

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

如果我们需要编写基于网络进行数据交互的程序意味着我们需要自己通过代码来控制我们之前所学习的OSI七层(很繁琐 很复杂 类似于我们自己编写操作系统)
socket类似于操作系统 封装了丑陋复杂的接口提供简单快捷的接口

socket也叫套接字
    基于文件类型的套接字家族(单机)
    AF_UNIX
    基于网络类型的套接字家族(联网)
    AF_INET

socket代码简介

服务端代码:
import socket

"""以后养成查看源码编写代码的思路     写注释!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"""

# 1.产生一个socket对象并指定采用的通信版本和协议(TCP)
server = socket.socket()  # 括号内不写参数 默认就是TCP协议 family=AF_INET 基于网络的套接字type_SOCK_STREAM流式协议即TCP
# 2.绑定一个固定的地址(服务端必备的条件)
server.bind(('127.0.0.1', 8080))  # 127.0.0.1为本地回环地址 只有自己的电脑可以访问
# 3.设立半连接池(暂且忽略)
server.listen(5)  # listen() 限制访问数量 有一个缓冲区
# 4.等待 连接客户
sock, addr = server.accept()  # return sock,addr 三次握手
# 5.服务客户
data = sock.recv(1024)  # 接收客户端发送过来的消息 1024字节
print(data.decode('utf8'))
sock.send('尊敬的客人 您说什么就是什么 一切按照您的要求来'.encode('utf8'))  # 给客户端发生消息 注意消息必须是bytes类型
# 6.关闭双向通道
sock.close()  # 四次挥手
# 7.关闭服务端
server.close()  # 店倒闭了

客户端代码:
import socket

# 1.生成socket对象指定类型和协议
client = socket.socket()
# 2.通过服务端的地址链接服务端
client.connect(('127.0.0.1', 8080))
# 3.直接给服务器发生消息
client.send('打野 有钱 把你们店最好的给我叫出来'.encode('utf8'))
# 4. 接收服务端发送过来的消息
data = client.recv(1024)
print(data.decode('utf8'))
# 5.断开与服务端的链接
client.close()

socket代码优化

循环通信
服务端:
import socket

server = socket.socket()
server.bind(('127.0.0.1', 8080))
server.listen(5)
while True:  # 链接循环
    sock, addr = server.accept()
    while True:  # 通信循环
        try:
            data = sock.recv(1024)
            if len(data) == 0:
                break
            print(f'来自于客户端{addr}的消息>>>:', data.decode('utf8'))
            msg = input('请输入发送给客户端的消息>>>:').strip()
            sock.send(msg.encode('utf8'))
        except BaseException:
            break

客户端:
import socket

client = socket.socket()
client.connect(('127.0.0.1', 8080))
while True:
    msg = input('请输入您想要发送给服务端的消息>>>:').strip()
    if len(msg) == 0:
        print('不能发空消息')
        continue
    client.send(msg.encode('utf8'))
    data = client.recv(1024)
    print('来自于服务端发送过来的消息>>>:', data.decode('utf8'))

1.聊天内容自定义
      针对消息采用input获取
2.让聊天循环起来
      将聊天的部分用循环包起来
3.用户输入的消息不能为空
   本质其实是两边不能都是recv或者send 一定是一方收一方发
4.服务端多次重启可能会报错
   Address already in use 主要是mac电脑会报
    方式1: 改端口号
    方式2:
import socket
udp_sk = socket.socket(type=socket.SOCK_DGRAM)   #创建一个服务器的套接字
udp_sk.bind(('127.0.0.1',9000))        #绑定服务器套接字
msg,addr = udp_sk.recvfrom(1024)
print(msg)
udp_sk.sendto(b'hi',addr)                 # 对话(接收与发送)
udp_sk.close()                         # 关闭服务器套接字

 5.当客户端异常端开的情况下 如何让服务端继续服务其他客人
    windows服务端会直接报错
    mac服务端会有一段时间反复接收空消息延迟报错
       异常处理、空消息判断

socket参数的详解

socket.socket(family=AF_INET,type=SOCK_STREAM,proto=0,fileno=None)

创建socket对象的参数说明:

family	地址系列应为AF_INET(默认值),AF_INET6,AF_UNIX,AF_CAN或AF_RDS。（AF_UNIX 域实际上是使用本地 socket 文件来通信）
type	套接字类型应为SOCK_STREAM(默认值),SOCK_DGRAM,SOCK_RAW或其他SOCK_常量之一。SOCK_STREAM 是基于TCP的，有保障的（即能保证数据正确传送到对方）面向连接的SOCKET，多用于资料传送。SOCK_DGRAM 是基于UDP的，无保障的面向消息的socket，多用于在网络上发广播信息。
proto	协议号通常为零,可以省略,或者在地址族为AF_CAN的情况下,协议应为CAN_RAW或CAN_BCM之一。
fileno	如果指定了fileno,则其他参数将被忽略,导致带有指定文件描述符的套接字返回。与socket.fromfd()不同,fileno将返回相同的套接字,而不是重复的。这可能有助于使用socket.close()关闭一个独立的插座。

半连接池概念

server.listen(5)   #  半连接池

当有多个客户端来链接的情况下  我们可以设置等待数量(不考虑并发问题)
假设服务端只有一个人的情况下

在测试半连接池的时候 可以不用input 获取消息 直接把消息写死即可

黏包现象

1.服务端连续执行三次recv
2.客户端连续执行三次send
问题:服务端一次性接收到了客户端三次的消息 该现象称为"黏包现象"
黏包现象产生的原因
    1.不知道每次的数据到底多大
    2.TCP也称为流式协议:数据像水流一样绵绵不绝没有间隔(TCP会针对数据量较小且发送间隔较短的多条数据一次性合并打包发送)
避免黏包现象的核心思路\关键点
   如何明确即将接收的数据具体有多大
ps:如何将长度变化的数据全部制作成固定长度的数据
服务端:
import socket

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

sock, addr = server.accept()
data1 = sock.recv(5)
print(data1)
data2 = sock.recv(1024)
print(data2)
data3= sock.recv(5)
print(data3)

sock.close()
server.close()

客户端:
import socket

client = socket.socket()
client.connect(('127.0.0.1',8082))

client.send(b'hello')
client.send(b'jason')
client.send(b'jerry')

struct模块

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(res1)   # 打包之后长度为(bytes)   4    报头
#
#
# real_len1= struct.unpack('i', res1)
# print(real_len1)   #  (46,)    根据固定长度的包头 解析出真实数据的长度

"""
解决黏包问题初级版本
    客户端
        1.将真实数据转成bytes类型并计算长度
        2.利用struct模块将真实长度制作一个固定长度的报头
        3.将固定长度的报头先发送给服务端 服务端只需要在recv括号内填写固定拆解过的报头数字即可
        4.然后再发送真实数据
    服务端
        1.服务端先接收固定长度的报头
        2.利用struct模块反向解析出真实数据长度
        3.recv接收真实数据长度即可
"""

'''问题1:struct模块无法打包数据量较大的数据'''
# res = struct.pack('i',111122324324)
# print(res)
'''问题2:报头能否传递更多的信息  比如 电影大小 电影名称  电影评价  电影简介'''

'''终极解决方案'''

data_dict = {
    'file_name': 'xxxxx老师教学!!!!!',
    'file_size': 143434343432513,
    'file_info': '内容精彩 不容错过',
    'file_desc': '一代神作 私人珍藏'
}

import json

data_json = json.dumps(data_dict)
print(len(data_json.encode('utf8')))  # 真实字典的长度  213
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]
# 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)

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)

UDP协议(了解)

1.UDP服务端和客户端'各自玩各自的'
	socket  用于UDP协议时 需要把 socket.socket(type=socket.SOCK_DGRAM)   默认参数改一下
2.UDP不会出现多个消息发送合并