网络编程

目录

• 一.软件开发架构
  • 1.C/S架构
  • 2.B/S架构
• 二.架构总结
• 三.网络编程前戏
  • 1.什么是网络编程
  • 2.学习网络编程的目的
  • 3.网络编程的起源
  • 4.网络编程必备条件
• 四.OSI七层协议
  • 1.引入:
  • 2.七层协议详细
• 五.各种重点协议
  • 1.OSI七层协议之物理连接层
  • 2.OSI七层协议之数据链路层
  • 3.网络相关专业名词
  • 4.OSI七层协议之网络层
  • 5.OSI七层协议之传输层
  • 6.传输层之TCP与UDP协议
    • 1).TCP协议(重要)
    • 2).UDP协议
  • 7.OSI七层协议之应用层
• 六.socket模块
  • 1.引入
  • 2.socket代码简介
  • 3.socket代码优化
• 七.半连接池的概念
• 八.黏包
  • 1.黏包现象
  • 2.struct模块
  • 3.黏包代码实战
• 九.UDP协议(了解)

一.软件开发架构

1.C/S架构

Client:客户端
Server:服务端
我们使用计算机下载下来的一个个app本质是各大互联网公司的客户端软件
通过这些客户端软件我们就可以体验到各个互联网公司给我们提供的服务
eg:
下载淘宝客户端 打开 体验淘宝服务端提供的购物服务
下载抖音客户端 打开 体验抖音服务端提供的视频服务
ps:一般情况下客户端与服务端交互需要互联网但是有些不需要(因为客户端和服务端都在一台计算机上)

​ 客户端:即将要去消费的客人

​ 服务端:给客人提供服务的店

​

​ 作为服务端必备的多个条件

​ 1.24小时不间断提供服务

​ 2.固定的地址

​ 3.能够服务多个客人(高并发)

​

2.B/S架构

Browser:浏览器

Server:服务器/端

​ 浏览器可以充当所有服务端的客户端

​ ps: B/S架构本质还是C/S架构

C/S架构

​ 优势:不同公司的客户端有不同的公司独立开发 可以高度定制化客户端功能

​ 劣势:需要下载才能使用，需要占用一定的内存空间

B/S架构

​ 优势:不用下载直接访问

​ 劣势:无法高度定制化 并且需要遵守很多规则

二.架构总结

ATM:三层架构

选课系统:三层架构

本质也属于软件开发架构的范畴

软件设计的大方向>>>:统一接口

​ 微信小程序

​ 支付宝小程序

三.网络编程前戏

1.什么是网络编程

基于网格编写代码 能够实现数据的远程交互

2.学习网络编程的目的

能够开发C/S架构的软件

3.网络编程的起源

最早起源于美国军事领域

​ 想实现计算机之间数据的交互

​ 最早的时候只能用硬盘拷贝

​ 之后发明了网格编程

4.网络编程必备条件

数据的远程交互

​ 1.早期的电话

​ 电话线

​ 2.早期的大屁股电脑

​ 网线

​ 3.笔记本电脑、移动电话

​ 网卡

ps:实现数据的远程交互必备的基础条件是物理连接介质

四.OSI七层协议

1.引入:

OSI七层协议:规定了所有的计算机在远程数据交互的时候必须经过相同的处理流程、在制造过程中必须拥有相同的功能硬件

2.七层协议详细

应用层

表示层

会话层

传输层

网络层

数据链路层

物理连接层

ps:

​ 记忆方法：应、表、会、传、网、数、物

常见的是整合之后后五层或者四层

五层：

​ 应用层、传输层、网络层、数据链路层、物理连接层

四层：

​ 应用层、传输层、网络层、网络接口层

接收网络消息 数据由下往上传递

发送网络消息 数据由上往下传递

五.各种重点协议

1.OSI七层协议之物理连接层

主要用于确保计算机之间的物理连接介质 接收数据(bytes类型、二进制)

2.OSI七层协议之数据链路层

1.规定了电信号的分组方式

2.以太网协议

​ 规定了计算机在出厂的时候都必须有一块网卡 网卡上有一串数字

​ 该数字相当于是计算机的身份证号码是独一无二的

​ 该数字的特征:12位16进制数据

​ 前6位产商编号 后六位流水线号

​ 该数字也称之为:以太网地址/MAC地址

3.网络相关专业名词

计算机之间要想实现数据交互必须要“连接”到一起

1.交换机

能够将所有接入交换机的计算机彼此互联起来

2.广播

首次查找计入同一个交换机的其他计算机，需要朝交换机里面吼一嗓子

3.单播

首次被查找的计算机回应查找它的计算机，并附带自己的mac地址

4.广播风暴

接入同一台交换机的多台计算机同时发广播

5.局域网

可以简单的理解为有单个交换机组成的网络

在局域网内可以直接使用mac地址通信

6.广域网

可以简单的理解为范围更大的局域网

7.互联网

由所有的局域网、广域网连接到一起形成的网络

8.路由器

不同的局域网计算机之间是无法直接实现数据交互的，需要路由器连接

4.OSI七层协议之网络层

IP协议：规定了所有接入互联网的计算机都必须有一个IP地址 类似于身份证号

​ mac地址是物理地址可以看成永远无法修改

​ IP地址是动态分配的，不同的场所IP是不同的

IP地址特征:

​ IPV4:点分十进制

​ 0.0.0.0

​ 255.255.255.255

​ IPV6:能够给地球上每一粒沙分一个IP地址

​ IP地址可以跨局域网传输

ps:IP地址可以用来标识全世界独一无二的一台计算机

5.OSI七层协议之传输层

PORT协议(端口协议)

用来标识一台计算机上面的某一个应用程序

范围:0-65535

​ 特征:动态分配(洗浴中心号码牌)

建议:

​ 0--1024 系统默认需要使用

​ 1024--8000 常见软件的端口号

​ 8000之后的是我们建议使用的

URL：

统一资源定位符(网址)

网址本质是由IP和PORT组成的！！！

IP+PORT：

能够定位全世界独一无二的一台计算机上面的某一个应用程序

域名解析：

将网址解析成IP+PORT

我们之所以不直接使用IP+PORT的原因是太难记 所以发明了域名(网址)

6.传输层之TCP与UDP协议

TCP与UDP都是用来规定通信方式的

​ 通信的时候可以随心所欲的聊 也可以遵循一些协议符合要求的聊

​ 随心所欲的聊:文字 图片 视频等等

​ 遵循一些协议:开头带尊称 首行空两格 只准用官话

ps：不遵守上述协议也可以通信 只不过遵循了更加合规合法合理！！！

1).TCP协议(重要)

三次握手建链接

第一次握手：客户端这边向服务端发送建立连接的请求（SYN seq = x）

第二次握手：服务端接收请求并回应，回应的同时向客户端发送建立连接的请求（这里可以看成同时进行了两步，如果服务端同意建立连接，这时候就会建立起客户端发送数据到服务端的数据传输通道，之后的服务端向客户端发送建立连接的请求是为了建立服务端返回数据到客户端的数据传输通道。SYN seq = y，ACK = x + 1）

第三次握手：客户端向服务端进行回应（ACK = y + 1）这时就建立起了两者的双向数据传输通道

1.TCP协议也称之为可靠协议(数据不容易丢失)

造成数据不容易丢失的原因不是因为有双向通道，而是因为有反馈机制

给对方发消息之后会保留一个副本，直到对方回应消息收到了才会删除，否则会在一段时间内反复发送

2.洪水攻击

同一时间有大量的客户端请求建立链接，会导致服务端一致处于SYN_RCVD状态

3.服务端如何区分客户端建立链接的请求

可以对请求做唯一标识

四次挥手断链接

第一次挥手：当客户端没有信息需要发送给服务端的时候，客户端会发送断开连接的请求（SYN seq = x+2）

第二次挥手：这时服务端会回应客户端，确认断开客户端传输信息给服务端的数据传输通道（ACK=x+3）

TIME_WAIT状态：当断开客户端传输数据到服务端的数据传输通道后，服务端需要先确认是否还有消息需要发送给客户端，发送完毕、确认无误后才会继续后续操作断开连接

第三次挥手：服务端向客户端发送断开通道连接的请求（seq = y + 1）

第四次挥手：客户端向服务端发送回应然后断开服务端跟客户端进行数据传输的通道（ACK = y + 2）

四次不能合并为三次

因为中间需要确认消息是否发完(TIMME_WAIT)

三次握手和四次挥手也可以看成是小情侣谈恋爱的过程

​ 三次握手：表白在一起

​ 四次挥手：决裂要分手

2).UDP协议

也称之为数据协议、不可靠协议

早期的qq使用的是纯生的(没有加任何额外功能)UDP协议

现在qq自己添加了很多技术和功能

使用UDP的原因就是因为很简单 快捷粗暴 只要指定对方的地址就可以发消息了

"""
TCP我们可以看成是打电话：双方来往互发消息
UDP我们可以看成是发短息：只要发了就行，不管对方看不看
"""

7.OSI七层协议之应用层

应用层相当于是程序员自己写的应用程序，里面的协议非常的多

常见的有：HTTP、HTTPS、FTP

ps：后续框架部分再做介绍

六.socket模块

1.引入

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

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

2.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为本地回环地址 只有自己的电脑可以访问，8080为端口号
# 3.设立半连接池(后面会讲)
server.listen(5)
# 4.等待接客
sock, addr = server.accept()  # return sock, addr  三次握手
print(sock, addr)  # sock就是双向通道 addr就是客户端地址
# 5.服务客人
data = sock.recv(1024)  # 接收客户端发送过来的消息 1024字节（基于网络传输数据得是二进制）
print(data.decode('utf8'))  # 因为二进制我们看不懂，所以要解码
sock.send('尊敬的客人 您说什么就是什么 一切按照您的要求来'
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()

3.socket代码优化

1.聊天内容自定义

针对消息采用input获取

2.让聊天循环起来

将聊天部分用循环包起来

3.用户输入的消息不能为空

本质其实是两边不能都是recv或者send 一定是一方收一方发

4.服务器多次重启可能会报错

Address already in use

主要是mac电脑会报错

方式1：改端口号

方式2：

#加入一条socket配置，重用ip和端口
import socket
from socket import SOL_SOCKET,SO_REUSEADDR
sk = socket.socket()
sk.setsockopt(SOL_SOCKET,SO_REUSEADDR,1) #就是它，在bind前加
sk.bind(('127.0.0.1',8898))  #把地址绑定到套接字
sk.listen()          #监听链接
conn,addr = sk.accept() #接受客户端链接
ret = conn.recv(1024)   #接收客户端信息
print(ret)              #打印客户端信息
conn.send(b'hi')        #向客户端发送信息
conn.close()       #关闭客户端套接字
sk.close()        #关闭服务器套接字(可选)

5.当客户端异常断开的情况下 如何让服务端继续服务其他客人？

windows服务端会直接报错
mac服务端会有一段时间反复接收空消息延迟报错
处理方式：使用异常处理、空消息判断，对上面的情况进行判断并给出解决方案

服务端代码：

import socket
from socket import SOL_SOCKET, SO_REUSEADDR

server = socket.socket()
server.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
server.bind(('127.0.0.1', 8081))
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', 8081))
while True:
    msg = input('请输入您想要发送给服务端的消息>>>:').strip()
    # 把发送的信息设置成自定义
    if len(msg) == 0:
        print('不能发送空消息')
        continue
    client.send(msg.encode('utf8'))
    data = client.recv(1024)
    print('来自于服务端发送过来的消息>>>:', data.decode('utf8'))

七.半连接池的概念

​ server.listen(5)

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

​ 比如上面我们半连接池设置成五个，在优化后的代码中，由于用while循环包裹了代码，当我们在运行代码的时候可以这样理解，第一个客户端就会直接跟服务端进行交互，除此之外还有五个客户端可以排队，但是发出去的信息服务端那边暂时不会处理，要等到第一个客户端处理结束断开连接才会根据先后顺序依次往后处理在测试半连接池的时候 可以不用input获取消息 直接把消息写死即可

八.黏包

1.黏包现象

1.服务端连续执行三次recv

2.客户端连续执行三次send

问题：服务端一次性接收到客户端三次的消息，该现象称为“黏包现象”

黏包现象产生的原因

1.不知道每次的数据到底多大

2.TCP也称为流式协议：数据想水流一样绵绵不绝没有间隔(TCP会针对数据量较小且发送间隔较短的多条数据一次性合并打包发送)

避免黏包现象的核心思路/关键点

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

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

2.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(len(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接收真实数据长度即可

问题一：struct模块无法打包数据较大的数据 就算换跟打的模式也不行

res = struct.pack('i', 123123123123)
print(res)

问题二：报头能否传递更多的信息，比如电影大小、电影名称、电影评价、电影简介

终极解决方案：字典作为报头打包，效果更好，数字更小

data_dict = {
    'file_name': 'xxx老师教学.avi',
    'file_size': 1231234234123414123123412341424,
    'file_info': '内容很精彩 千万不要错过',
    'file_desc': '一代神作 私人珍藏'
}
import json
data_json = json.dumps(data_dict)
print(len(data_json.encode('utf8')))  # 真实字典长度  228
res = struct.pack('i', len(data_json.encode('utf8')))
print(len(res))

黏包问题终极方案

客户端

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

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

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

4.发送字典数据

5.发送真实数据

服务端

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

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

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

4.接收真实数据长度

3.黏包代码实战

客户端

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)
        prinnt(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'E:\a.txt')
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服务端和客户端'各自玩各自的'

2.UDP不会出现多个消息发送合并