一、网络基础
- 用途:未来的web框架的学习 未来的工作场景做铺垫
- 两个运行中的程序如何传递信息?
- 通过文件
- 两台机器上的两个运行中的程序如何通信?
- 通过网络
- 两个运行中的程序如何传递信息?
- 网络应用开发架构
- C/S
- client 客户端
- server 服务端
- 例如:迅雷 qq 浏览器 飞秋 输入法 百度云 pycharm git VNC 红蜘蛛 各种游戏
- B/S
- browser 浏览器
- server 服务端
- 例如:淘宝 邮箱 各种游戏 百度 博客园 知乎 豆瓣 抽屉
- 统一程序的入口
- B/S和C/S架构的关系:B/S是特殊的C/S架构
- C/S
- 网卡 :是一个实际存在在计算机中的硬件
- mac地址 :每一块网卡上都有一个全球唯一的mac地址
- 交换机 :是连接多台机器并帮助通讯的物理设备,只认识mac地址
- 交换机进行局域网通信
- 广播:发送给所有机器
- 单播:发送给一个机器
- 组播:发送给一组机器
- 交换机进行局域网通信
- 协议 :两台物理设备之间对于要发送的内容,长度,顺序的一些约定
- ip地址
- ipv4协议 4位的点分十进制 32位2进制表示
- 0.0.0.0 - 255.255.255.255
- ipv6协议 6位的冒分十六进制 128位2进制表示
- 0:0:0:0:0:0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
- ipv4协议 4位的点分十进制 32位2进制表示
- 公网ip:能被所有人访问到ip地址
- 为什么你的外地朋友的电脑我们访问不了?
- 每一个ip地址要想被所有人访问到,那么这个ip地址必须是你申请的
- 为什么你的外地朋友的电脑我们访问不了?
- 内网ip:这些区间的ip地址公网不会使用,避免了公网ip和内网ip的重叠
- 192.168.0.0 - 192.168.255.255
- 172.16.0.0 - 172.31.255.255
- 10.0.0.0 - 10.255.255.255
- arp协议:通过ip地址获取mac地址
- 交换机实现的
- 使用了广播和单播
- 网关ip:一个局域网的网络出口,访问局域网之外的区域都需要经过路由器和网关
- 网段:指的是一个地址段 ,如x.x.x.0或x.x.0.0或x.0.0.0
- 子网掩码:判断两台机器是否在同一个网段内的
- port:端口,0-65535
- ip 地址能够确认一台机器
- ip + port 确认一台机器上的一个应用
二、tcp / udp 协议
2.1 tcp协议
- 特点:
- 可靠,慢,全双工通信
- 建立连接时:三次握手
- 断开连接时:四次挥手
- 在建立起连接之后
- 发送的每一条信息都有回执
- 为了保证数据的完整性,还有重传机制
- 长连接:会一直占用双方的端口
- IO(input,output)操作,输入和输出是相对内存来说的
- write send - output
- read recv - input
- 能够传递的数据长度几乎没有限制
- 应用场景:
- 文件的上传下载
- 发送邮件,网盘,缓存电影等
- 文件的上传下载
- 简述三次握手和四次挥手
- 三次握手
- accept接受过程中等待客户端的连接
- connect客户端发起一个syn链接请求
- 如果得到了server端响应ack的同时还会再收到一个由server端发来的syc链接请求
- client端进行回复ack之后,就建立起了一个tcp协议的链接
- 三次握手的过程再代码中是由accept和connect共同完成的,具体的细节再socket中没有体现出来
- 四次挥手
- server和client端对应的在代码中都有close方法
- 每一端发起的close操作都是一次fin的断开请求,得到‘断开确认ack‘之后,就可以结束一端的数据发送
- 如果两端都发起close,那么就是两次请求和两次回复,一共是四次操作
- 可以结束两端的数据发送,表示链接断开了
- 三次握手
2.2 udp协议
- 特点:
- 无连接的,速度快
- 可能会丢消息
- 能够传递的数据长度是有限的,是根据数据传递设备的设置有关系
- 应用场景:
- 即时通信类
- qq,微信,飞秋等
- 即时通信类
- tcp协议和udp协议的区别
- tcp协议:是一个面向连接的,流式的,可靠的,慢的,全双工通信
- 邮件 文件 http web
- udp协议:是一个面向数据报的,无连接的,不可靠,快的,能完成一对一、一对多、多对一、多对多的高效通讯协议
- 即时聊天工具 视频的在线观看
- tcp协议:是一个面向连接的,流式的,可靠的,慢的,全双工通信
2.3 粘包现象
- 定义:同时执行多条命令之后,得到的结果很可能只有一部分,在执行其他命令的时候又接收到之前执行的另外一部分结果,这种现象就是粘包
- 黏包成因:只有TCP有粘包现象,UDP永远不会粘包
- TCP协议中的数据传递
- tcp协议的拆包机制
- 面向流的通信特点
- TCP协议中的数据传递
- 会发生粘包的两种情况:
- 情况一 发送方的缓存机制
- 情况二 接收方的缓存机制
- 总结:
- 粘包现象只发生在tcp协议中
- 从表面上看,粘包问题主要是因为发送方和接收方的缓存机制、tcp协议面向流通信的特点
- 实际上,主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的
- tcp协议的粘包现象
- 什么是粘包现象
- 发生在发送端的粘包
- 由于两个数据的发送时间间隔短+数据的长度小
- 所以由tcp协议的优化机制将两条信息作为一条信息发送出去了
- 为了减少tcp协议中的“确认收到”的网络延迟时间
- 发生再接收端的粘包
- 由于tcp协议中所传输的数据无边界,所以来不及接收的多条
- 数据会在接收放的内核的缓存端黏在一起
- 本质: 接收信息的边界不清晰
- 发生在发送端的粘包
- 解决粘包问题
- 自定义协议1
- 首先发送报头,报头长度4个字节,内容是即将发送的报文的字节长度
- struct模块 pack 能够把所有的数字都固定的转换成4字节
- 再发送报文
- 首先发送报头,报头长度4个字节,内容是即将发送的报文的字节长度
- 自定义协议2
- 我们专门用来做文件发送的协议
- 先发送报头字典的字节长度,再发送字典(字典中包含文件的名字、大小),再发送文件的内容
- 自定义协议1
- 什么是粘包现象
三、osi七层模型/osi五层协议
3.1 osi七层模型
- 第七层:应用层
- 第六层:表示层
- 第五层:会话层
- 第四层:传输层
- 第三层:网络层
- 第二层:数据链路层
- 第一层:物理层
3.2 osi五层协议
层数 | 名称 | 协议 | 物理设备 | |
---|---|---|---|---|
第五层 | 应用层 | python代码相关 | http/https/ftp/smtp协议 | |
第四层 | 传输层 | port端口相关 | tcp/udp协议 | 四层路由器,四层交换机 |
第三层 | 网络层 | ip地址相关 | ipv4/ipv6协议 | (三层)路由器,三层交换机 |
第二层 | 数据链路层 | mac地址相关 | arp协议 | 网卡,(二层)交换机 |
第一层 | 物理层 |
原文地址:https://www.cnblogs.com/zengyi1995/p/11329059.html
时间: 2024-08-01 05:36:16