前言👀~
上一章我们介绍了传输层协议的报文格式以及协议机制,今天接着介绍其他层的协议
网络层
IP协议
地址管理
路由选择
数据链路层
DNS(域名解析系统)
如果各位对文章的内容感兴趣的话,请点点小赞,关注一手不迷路,讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话,欢迎各位评论纠正 🤞🤞🤞
个人主页:N_0050-CSDN博客
相关专栏:java SE_N_0050的博客-CSDN博客 java数据结构_N_0050的博客-CSDN博客 java EE_N_0050的博客-CSDN博客
网络层
网络层要做的事情,主要是两个,也可以说是核心功能
1.地址管理:制定一系列的规则,通过地址来描述一个设备在网络上所处的位置。类似我们收件的地址
2.路由选择:因为网络环境比较复杂,一个节点到另外一个节点之间有不同的路径可以走,通过这种方式可以规划出合适的路径进行数据传输。前面初始网络提到过这点,类似快递要经过的路线有很多选择一条合适的去进行运送
IP协议
报头中的字段:
1.32位源IP地址和32位目的IP地址:IP协议中最关键的内容,采用点分十进制表示
2.4位版本:写4即是ip v4,写6即是ip v6,大规模版本使用这两个
3.4位首部长度:IP协议报头的长度,也是变长的,取值范围0-0xf和TCP一样也是60字节
4.选项字段:能变长也是因为这个选项字段,这个选项是可以有也可以没有
5.8位服务类型(Type Of Service):3位优先权字段(已经弃用),4位TOS字段,和1位保留字段(必须置为0)
只有4位TOS字段能进行设置,并且彼此之间冲突,只有一位能设置成1。不同位设置1,IP协议的形态也不同,有最小延时,最大吞吐量(单位时间内传输数据量最多),最高可靠性,最小成本这四个形态,根据场景进行选择。类似你可以想想迪迦能变红变蓝之间有什么不同
6.16位总长度(total length):IP数据包最长是多长,也就是IP数据报整体占多少个字节,也就是限制了IP协议所能携带的数据有多长,虽然IP协议也存在64KB这样的限制,但是IP协议自身支持拆包组包的功能,UDP只能靠代码去实现
7.8位生存时间(Time To Live,TTL):TTL单位是次数,数据报到达目的地的最大报文跳数。一般是64。每次经过一个路由,TTL减1,一直减到0还没到达,那么就丢弃了。这个字段主要是用来防止出现路由循环
8.8位协议:表示上层协议的类型,描述的是IP数据包的载荷部分,也就是传输层是哪个协议
9.16位头部校验和:和之前的TCP和UDP的还是有区别的,使用CRC进行校验,来鉴别头部是否损坏,不管IP载荷部分,因为载荷部分包含UDP/TCP这样的协议都有校验和
下面这三个属性就能表示拆包和组包的支持:
1.16位标识:就是如果一个大的IP数据包被拆分多个小包,用这个字段来进行区分如果IP报文在数据链路层被分片了,那么每一个片里面的这个id都是相同的
2.13位片偏移:用来区分拆解后每个小包(分片)的顺序,因为可能会出现后发先至的情况
3.3位标志:第一位保留,第二位表示是否允许拆包,1是不能0则能,第三位表示是否是最后一个包,是则置为0,反之1。类似于一个结束标记
地址管理
IP地址,是一个32位的整数,2^32=>42亿9千万,地址理论上不应该重复
如何解决IP地址不够用呢?
方案1:动态分配IP,如果当前使用了计算机或网络就分配IP地址,当前没使用就不分配,这样提高了IP地址的利用率
方案2:NAT技术(网络地址转换),让一个IP地址代表一批设备。就类似我们在学校都使用这个地址买东西,使用的都是同一个地址
NAT技术把IP地址分为两大类:
1.内网IP(也可以叫局域网IP/私网IP)
如果一个IP地址,是以10.*或172.16.*-172.31.*或192.168.*,满足其一就是内网IP
在同一个局域网内部,内网IP地址不能重复,不同的局域网内部,内网IP地址可以重复。内网IP无法在广域网中使用需要先转换成外网IP
2.外网IP(也可以叫广域网IP/公网IP)
除了上面的剩下的都是外网IP,外网IP无论无何都不能重复,唯一的
例子:我们的学校或者公司就属于一个大的局域网,在这个局域网内有很多很多的设备,都是使用一个外网IP来表示
NAT技术的例子:就比如你要传输数据到外网IP的某台设备,此时你不能传输的数据包中的源IP经过路由器,这个IP地址会被转成外网IP,不只是你这台别人的电脑要传输数据的时候也会进行转换,然后经过广域网传输到对方的设备上,对方服务器看到的就是你IP地址被替换掉的外网IP。然后这台服务器传输回来的时候也是以外网IP进行传输,经过路由器进行转换,传输到你这的时候又经过路由器会把外网IP转成内网IP
如果同一局域网内 不同主机要访问同一服务器 转换的IP地址一样,此时端口号就起作用了,不仅可以区分同一主机的不同进程,还可以区分不同主机的不同进程,这样就能返回数据的时候,路由器就能根据端口号返回替换回对应的源IP地址传回对应的主机
如果源端口号一样访问同一服务器,此时路由器也会进行转换,将两数据包的源端口号都替换掉然后进行传输,传输回来后根据路由表进行映射,表中记录了对应的源IP
总结:带有NAT机制的设备,不仅能将IP地址进行转换,还能将端口号进行替换
方案3:IPv6,使用16个字节表示IP地址,IPv4上面说了2^32有这些数字用来表示地址,这里IPv6则是2^128有这些数字用来表示地址
网段划分:
IP地址划分为网络号(标识一个局域网)+主机号(标识局域网中的一个设备),同一局域网内,网络号必须相同,主机号必须不同。相邻的局域网,网络号必须不同,主机号全0代表这个IP是 网络号(192.168.1.0),全1是 广播地址(192.168.1.255)
一个IP地址,哪部分是网络号,哪部分是主机号,不一定。子网掩码就是用来确认网络号的
路由选择
之前说过路由选择就是对路径进行合理的规划,描述IP数据包的转发过程
就像我们生活中会使用地图看到达目的地路线,根据自己的需求去选择对应的路线。地图的相关信息都是存储在地图的服务器上的,但是数据包在进行转发的时候,路由器无法知道网络的全貌,只知道一些局部信息(一个路由器相邻的一些设备),所以在转发过程中就有点摸黑了,一点一点进行摸索。类似问路的意思,没有地图,靠嘴问,走到一个地方问一下以此类推就慢慢摸索出目的地了。所以一个网络层的数据包没经过一个路由器就按这样的方式进行
每个路由器中都有一个路由表,这样在传输的时候到达一个路由器就去查一下,有的话就按路由表给的地址接着转发,没有的话就按默认的地址走
数据链路层
数据链路层有很多协议,比较常见常用的就是"以太网协议",通过网线/光纤来通信使用的协议就是"以太网协议",以太网属于是跨数据链路层和物理层,网线的一些标准属它规定的
以太网数据帧格式:
组成:帧头+载荷(IP数据报)+帧尾(校验和),帧头中有源地址和目的地址、帧协议类型,源地址和目的地址(各6个字节能表示的范围比IP地址大)不是表示IP地址,是MAC地址一般用16进制表示的(物理地址),初识网络中提到mac地址表示网卡的地址
MTU:数据链路层的数据包能携带的最大载荷长度,IP数据包进行拆包分包和这个MTU有关系,以及不同数据链路层协议的MTU不同,就类似每辆车的承载重量
帧协议类型字段:描述载荷数据是一个啥类型的数据,有三种类型,分别对应IP、ARP、RARP。ARP不是一个单纯的数据链路层的协议,而是一个介于 数据链路层和网络层之间的协议,ARP协议建立了主机 IP地址 和 MAC地址 的映射关系
IP地址和MAC地址的用途是什么?
IP协议关注大局,完成整个通信过程的路径规划。以太网关注局部,相邻两个设备之间的通信
怎么解释呢?例子:上海->杭州->嘉兴->绍兴,上海->杭州->宁波->绍兴,IP协议关注的是路径啥样的,无论走哪条源IP都是上海,目的IP都是绍兴
然后数据链路层关注的是相邻节点之间如何转发,上海->杭州坐飞机,此时源IP是上海,目的IP是绍兴,源mac是上海,目的mac杭州,然后到了杭州坐高铁,此时源IP还是上海,目的IP还是绍兴,源mac是杭州,目的mac嘉兴,源IP和目的IP始终不变,变的是相邻节点。mac地址会在每次往下一个节点转发的时候变化 ,就类似快递,你可以看到一整条路线是没变化的,相邻节点之间不断变化
DNS(域名解析系统)
DNS是一整套从域名映射到IP的系统,前面用IP地址来描述设备在网络上的设备,IP地址不适合进行宣传,引入"域名"的方式来解决,使用单词来表示,www.baidu.com 这时通过DNS解析把域名翻译成IP地址,可以理解域名和IP地址是一组键值对
最早的域名解析系统,通过一个hosts文件来实现的,这种维护域名和IP映射关系不太方便。于是后来搭建一套DNS系统(一组服务器),此时想访问某个域名,发起请求到DNS服务器,然后找到对应的IP进行访问。后续进行域名只需在服务器更新即可
一组DNS服务器能扛住大量的请求吗?
一个服务器硬件资源有限,处理请求的时候会消费一定的资源,单位时间内请求量太大,消耗的资源超过了机器能承受的上限就会挂了
高并发问题如何解决?
1.开源:搞个镜像服务器,网络运营商都自己搭建一组DNS镜像服务器,镜像服务器的数据都从台真正的DNS服务器同步过来,此时用户优先访问离自己近的镜像服务器,所以我们平时访问的这些网站都是离自己最近的镜像服务器
2.节流:让请求量变少,让每个上网的设备搞个本地缓存。如果一台设备要多次访问用一个域名的情况下,请求一次DNS后,把请求得到的结果存储在本地,后续的请求都使用第一次的结果即可
以上便是本章内容分了三篇分别讲,下一篇讲解应用层的协议HTTP和HTTPS💕