标签:sock tput 握手 OSI七层 框架 知识 应用 syn 获取
用途:未来的web框架的学习 未来的工作场景做铺垫
两个运行中的程序如何传递信息?
通过文件
两台机器上的两个运行中的程序如何通信?
通过网络
网络应用开发架构
C/S
client 客户端
server 服务端
例如:迅雷 qq 浏览器 飞秋 输入法 百度云 pycharm git VNC 红蜘蛛 各种游戏
B/S
browser 浏览器
server 服务端
例如:淘宝 邮箱 各种游戏 百度 博客园 知乎 豆瓣 抽屉
统一程序的入口
B/S和C/S架构的关系:B/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
公网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 确认一台机器上的一个应用
特点:
可靠,慢,全双工通信
建立连接时:三次握手
断开连接时:四次挥手
在建立起连接之后
发送的每一条信息都有回执
为了保证数据的完整性,还有重传机制
长连接:会一直占用双方的端口
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,那么就是两次请求和两次回复,一共是四次操作
可以结束两端的数据发送,表示链接断开了
特点:
无连接的,速度快
可能会丢消息
能够传递的数据长度是有限的,是根据数据传递设备的设置有关系
应用场景:
即时通信类
qq,微信,飞秋等
tcp协议和udp协议的区别
tcp协议:是一个面向连接的,流式的,可靠的,慢的,全双工通信
邮件 文件 http web
udp协议:是一个面向数据报的,无连接的,不可靠,快的,能完成一对一、一对多、多对一、多对多的高效通讯协议
即时聊天工具 视频的在线观看
定义:同时执行多条命令之后,得到的结果很可能只有一部分,在执行其他命令的时候又接收到之前执行的另外一部分结果,这种现象就是粘包
黏包成因:只有TCP有粘包现象,UDP永远不会粘包
TCP协议中的数据传递
tcp协议的拆包机制
面向流的通信特点
会发生粘包的两种情况:
情况一 发送方的缓存机制
情况二 接收方的缓存机制
总结:
粘包现象只发生在tcp协议中
从表面上看,粘包问题主要是因为发送方和接收方的缓存机制、tcp协议面向流通信的特点
实际上,主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的
tcp协议的粘包现象
什么是粘包现象
发生在发送端的粘包
由于两个数据的发送时间间隔短+数据的长度小
所以由tcp协议的优化机制将两条信息作为一条信息发送出去了
为了减少tcp协议中的“确认收到”的网络延迟时间
发生再接收端的粘包
由于tcp协议中所传输的数据无边界,所以来不及接收的多条
数据会在接收放的内核的缓存端黏在一起
本质: 接收信息的边界不清晰
解决粘包问题
自定义协议1
首先发送报头,报头长度4个字节,内容是即将发送的报文的字节长度
struct模块 pack 能够把所有的数字都固定的转换成4字节
再发送报文
自定义协议2
我们专门用来做文件发送的协议
先发送报头字典的字节长度,再发送字典(字典中包含文件的名字、大小),再发送文件的内容
第七层:应用层
第六层:表示层
第五层:会话层
第四层:传输层
第三层:网络层
第二层:数据链路层
第一层:物理层
层数 | 名称 | 协议 | 物理设备 | |
---|---|---|---|---|
第五层 | 应用层 | python代码相关 | http/https/ftp/smtp协议 | |
第四层 | 传输层 | port端口相关 | tcp/udp协议 | 四层路由器,四层交换机 |
第三层 | 网络层 | ip地址相关 | ipv4/ipv6协议 | (三层)路由器,三层交换机 |
第二层 | 数据链路层 | mac地址相关 | arp协议 | 网卡,(二层)交换机 |
第一层 | 物理层 |
标签:sock tput 握手 OSI七层 框架 知识 应用 syn 获取
原文地址:https://www.cnblogs.com/zengyi1995/p/11329059.html