0.写在前面:
该层为教学模型的最后一层,某种意义上来说是最接近各位开发者的一层,正因如此,这层中的很多定义和概念大家都有属于自己的理解, 完全按照书本反而才是异类,因此在这里我会去结合我做前端开发的一些经验,来处理和讲解一些概念,另外本层中的部分协议也不会过多阐述了,大家有足够的机会去接触这些.
这篇博客的后半部分主要讲解一些应用进程的举例,前半部分则是一些定义和原理.
其实到这篇博客为止,这个系列也就告一段落了在这里再次感谢已经和即将为我的推文提出意见的同学,老师,还有诸位前辈们,那么的指点是我前进最大的动力!
(鞠躬)
一点碎碎念:
我是在9月份开始打算整理这个系列博客的,平均每篇博客的字数大概在1w+,这五篇博客的量加起来已经约等于一部中篇小说了. 其实在写这些博客的时候,让我回想起来自己的初中时光,那时候的我在一些网站写小说,认识了很多朋友,也认识了很厉害的前辈们,收获了现实世界难以得到的真挚友情,但是一切似乎都转瞬即逝了.
在动笔这篇博客的时候,已经即将步入新生活的我似乎重新遇到了当年的难题, 社交就像当年一样,在一个秋天慢慢随着树叶落下了. 在夏天的尾巴, 我喜欢上了一位优秀,温柔,美丽而独立的女孩子,也认识了很多可爱的小孩子们,也和一些很厉害的朋友搭档过,平时和我话不多但是仍然很照顾我的师兄师姐们
正当我以为我都生活马上就要回到正轨的时候,这个美好的泡沫似乎爆开了, 我不知道起因是什么,或许是急切的需要一些人来给我正向的反馈,或许是繁忙的课业,也或许是她.我不知道自己是在犯傻,主动割裂了所有的关系,还是因为大家本来就不需要我,抛下了我反而大家更能成为无话不谈的密友........时至今日我已经不想再回忆这些,因为每次回忆,我的复杂情感就会慢慢转化成一些恨意, 我恨大家不需要我,我恨大家对我的无视,我也恨自己的平庸和无能. 或许这就是我无法面对以前的朋友的原因了.
时至今日,生活已经逐渐趋于稳定,无论是悔恨,歉意,还是不放心,,,,甚至是爱,已经消失的差不多了,只剩下偶尔回想起来的惆怅.
我希望能成为别人需要的人,能成为别人出了事情第一个想到的人,不是人群的焦点,而是大家因为我在而安心的感觉,这就是我想要的一点点回馈, 但是不知道为什么我好像得不到这些了, 一年来,其实每天嘻嘻哈哈的,不知道为什么也很难受,我真的有努力在爱我身边的每一个朋友啊,但是又有多少人能来爱一下我呢? 就用和我一样的方式.
或许没有了吧,无论是友情也好,还是对于她的憧憬也好,我知道我现在一些熟悉我的人眼里就是一个表演人格的小丑, 但是我真的,真的一直不开心啊.....
当年因为无法正视自己的想法,整个人就变得越来越暴戾,越来越丑恶.......时至今日面对一个差不多的岔路口, 我想我应该做出一点不一样的抉择, 我想,既然没人能以同样的方式来爱一下我,那么我也没有必要在任何关系上,倾注自己的感情了. 我爱一下我自己,这就够了.
就当,我从来没有走进和打扰他们的生活.
至于情感,我大概是会坚持很长一段时间吧, 无论这次以何种方式收场,我想我这辈子大概也不会再信任感情了, 我无法接受自己因为爱而陷入这个不计回报,完全不理智的状态.
这个系列的五个博客,我写了两个月左右,从一开始的被嫉妒填满,到现在能写下这些文字,我也不知道自己现在是在低谷俯冲,还是在艰难前行,不管怎么说,我仍然会以一个很积极和阳光的想法去看待她和这份感情, 在我焦虑而艰难的时刻,我真的很感谢她对我的些许帮助, 也正是这段经历告诉我,要学着克服自己的恶意吧,哪怕是想法上, 其他的,就慢慢消失掉吧
你好,未来
文笔不畅,思路混乱,碎碎念
2023.11.26 22:34
vicemusic5
1.应用层提供了什么
1.1.运输层定义
在运输层结束以后,其实我们已经实现了端到端的数据交互,实现了进程之间的交互.
而应用层也并非是在物理上扩展了计算机网络的结构, 某种程度上来说实现了对于实际通信传输的封装, 为用户和网络应用提供了完整的服务.
总结:应用层的主要任务是通过进程的交互来实现特定的网络应用.
1.2.运输层提供服务
开发一种新的网络服务主要需要考虑两个问题, 这种程序有怎么样的组织形式,目前提供的服务来说,我们可以例举出两种:
客户/服务器模式(C/S)
这种模式如果是开发过web应用的各位肯定不会陌生, 如图所示:
服务器负责提供服务,用户负责请求服务,其中衍生出来的前后端分离技术也是基于此产生的. 在这种形势下,服务器一般具有固定的运输层端口号和网际层IP地址. 而其服务的客户进程通常是不固定的,通过网络向服务器获取服务.
对等方式(P2P)
在对等的方式中,没有固定的服务请求者和服务提供者,分布在网络边缘的各个设备被称作对等方,对等放之间是直接通信,这种服务方式拥有很高的扩展性
这两种方式都有各自的有点,例如客户-服务器模式需要大量的服务器组成服务器集群来提供对应的服务,而P2P模式下成本极低,等等, 未来的趋势是结合两种模式共同使用, 构建出更加强大的网络应用.
2.动态主机配置协议DHCP
2.1.为什么需要这个协议
嘛,其实我知道在这里弄这个协议是一件很突兀的事情,但是说实话, 这一届的内容就是比较突兀,因为默认有了一些程序上的铺垫...
首先在这里我们需要一些情况, 还记得我们在前面的博客中提到过关于"MAC"地址和"IP"地址的事情吗, 在那里我偶然提过一句"IP地址是可分配的,并且能够通过某些协议和MAC地址对应".
而且回想一下,当你接入一个计算机网络的时候,你的设备IP号是不是不会发生变化?
答案就在这里,当你接入一个网络的时候,网络会根据你设备上的MAC地址,来进行分配IP地址 !
具体怎么样分布呢,以及域名又是什么关系?
别急,下面慢慢的找机会告诉你.
在这里我们首先需要知道一个事情就是, 每一个接入互联网的设备,我们都需要一些网络参数,以TCP/IP协议为例, 我们一共需要如下四个网络参数.
- IP地址
- 子网掩码
- 默认网关
- DNS服务器(用于解析域名,后面会讲到)
整个网络的结构如图所示
这四个东西其实自然可以由用户进行手动指定,但是按照我个人的开发经验来说你最好不要过于相信用户......因此我们需要一个动态主机配置服务器来为本网络中的主机设置这些数值, 因此我们需要这样一个DHCP协议来约束行为.
如图所示:
2.2 DHCP协议工作原理
工作目的可以说是肥肠简单了,在这里我们需要说明一下协议的工作原理.
DHCP使用客户服务器模式, 负责为各个客户机器编辑网络参数的设备被称作DHCP服务器.
在客户机上运行的程序被称之为"DHCP客户进程",默认端口号为68
在服务器上运行的程序被称之为"DHCP服务进程",默认端口号为67
并且二者都是基于UDP数据报进行的封装,这一点需要注意一下.出于简单考虑,这里我们不再解释封装过程,直接阐述协议的工作原理:
其实协议的工作原理,我在这里简单的将其分成两部分,如果有不对的地方,还请多多指教:
分配IP地址阶段.和租约续期阶段,
2.2.1:分配IP地址阶段:
分配IP地址阶段,其实核心总结起来就是,
"我想要IP地址"
"给你IP地址,你看看要我的还是要别人的"
"我就要这个IP了"
"好的,给你这个IP,请检查以后慢用"
很抽象对吧,我们跟着图片进行解释.在这里我们使用两个DHCP服务器用来作为"多服务器提供IP"的典型样例;
(1)用户启动DHCP进程,发送一个广播的DHCP发现报文,在这个报文中,由于本机还没有IP地址,所以源地址为0.0.0.0, 并且由于是广播,目标地址为255.255.255.255. 会将其发布给每一个DHCP服务器上. 并且记得在这里封装一下端口68,目标端口67,以及请求IP的设备当前的MAC地址.
并且对于这个广播报文,可能会遇到其他客户也能接收到的情况.在这里我们使用这种逻辑进行处理:
对于用户来说,接收到这个报文,发现目标端口为67,自身无法交付这个服务,就会将其丢弃
对于服务器来说.接受到这个报文,就会在67端口上的DHCP进程来实现对于这个服务的回答
(2)当某个DHCP服务器接收到这个广播出来的DHCP发现报文以后,这是它发生的变化.
当一个DHCP接收到这样一个报文以后, 会检查其中封装的MAC地址, 并且和自身的数据库进行对应,查看是否有针对这个MAC的配置信息(如果没有就按默认生成),随后封装一个DHCP提供报文,源地址为该DHCP服务器的IP,目的地址仍然是255,也就是广播报文.
这个报文的意义就是"告知用户,我这里有你需要的报文,是否需要请回答确认"
当然啊,这都广播了肯定要处理上述问题"如何保证广播帧不会发给服务器和其他用户?"
对于发到其他服务器上的报文来说, 服务器会根据目标端口68和自己运行进程的端口不符合而丢弃这个包
而对于其他无关的用户来说,接收到这个报文以后,会根据其中的"事物ID"字段判断这是不是自己发出的字段,这就保证了其他用户不会胡乱地相应这个广播帧
(3)用户这个时候会接收到多个DHCP提供报文(本案例中是两个),用户会根据自己内部情况的选择,选择其中一个DHCP服务器进行答复,也就是DHCP请求报文,正式请求IP地址,但是注意此时仍然是IP源地址为0.0.0.0的广播报文. 这样做的目的是为了不用单播发送(这里存疑,等待后续补充)
(4)某个DHCP服务器给用户发送了DHCP确认报文,这个时候, 目的IP地址仍然是广播,但是源地址为该服务器, 用户接收到以后,就可以正常使用IP了(为什么这里是广播报文仍然等待后续的解释..)
但是需要注意的一点是,再使用这个租来的IP地址(还有其他网络参数)之前, 主机会自动进行ARP验证,防止这个IP被其他主机占用了,如果被占用,则会返回一个DHCP谢绝报文,重新开始执行DHCP发现(也就是最开始重来一遍)
2.2.2:租约续期阶段
每一个得到的IP都是由期限的,所以需要考虑是否进行续期:
当IP地址的租期到达一半的时候,DHCP就会向服务器发送一个DHCP请求报文试图更新租期,注意这个时候的DHCP请求报文是单播,而不是之前的广播,因为链接已经顺利完成.
在这里会有三种情况.
- DHCP服务器如果同意续期, 则会向客户发送一个DHCP确认报文来增长时间
- 如果不同意,则会向用户发送一个DHCP否认报文, 这种情况下就要立刻停止当当前IP的使用,重新申请新的IP
- 如果DHCP服务器没响应,则再时间到达0.875的时候,再次发送,如果再没反应就停止IP使用,重新申请
并且,客户可以随时选择停止IP地址的获取,这个时候只需要发送一个广播报文"DHCP释放报文"即可, 这个报文网络地址为0,0,0,0
2.3.DHCP中继代理
我们都知道DHCP在建立请求的过程中,发送了大量的广播报文,广播在路由器中是不允许通过的,因此我们的解决办法就是,给路由器配置DHCP服务器的IP地址,并且使之成为DHCP中继器
3.域名系统:
最近因为这一点有点焦头烂额,在这里需要提醒一下各位开发者,建立网站的时候一定要合法正规的在有关部门进行域名的备案!
域名这东西其实很简单, 说个很不正确的理解, 这个东西就相当于应用层的"地址", 它可以用来取代IP地址作为一个路径使用.同时也方便人们进行记忆.换句话说,域名和IP地址在理想状态下是对应的.
由于因特网的庞大性质,不可能只用一套域名和一个机器来存储域名,因此我们需要使用分布式,层次化的域名系统,这个东西在这里我们不多解释,主要focus在层次化这一点上.
另外主语,域名至少一个名称概念,和地理位置没有关系
3.1.域名服务器
域名和IP地址的对应关系必须保存在域名服务器中,这个域名服务器也被我们称之为DNS,在各大互联网企业也支持了DNS解析,也就是域名和IP地址之间的转化.
域名服务器可以划分三个层次结构,以及提供特殊类型
根域名服务器:在互联网上,根域名服务器一共有13个,分布在全球各地,根域名服务器并不直接提供IP地址和域名的转化,而是根据域名的层次结构, 返回该域名所属的顶级域名服务器的地址
顶级域名服务器: 顶级域名服务器负责管理在其下的所有的二级域名,可以给出DNS服务的应答,也可以给出下一级区域域名服务器的地址.
权限域名服务器:负责管理某个区域的域名......
以上三个构成了一个由大到小的域名服务器分层次机制
本地域名服务器:一种特殊的域名服务器,起到代理的作用, 有时候也被称之为默认域名服务器,DNS请求报文会优先发送到该服务器,然后由其进行代理发送
3.2.域名解析过程
域名解析的过程大概就分为两种
第一种,递归查询,不断深入寻找,找到合适的IP以后原路返回
第二种, 迭代查询,如图所示:
每次查询完一个服务器,其中获取下一次应该查询的服务器地址(也就是层次结构中的下一个服务器),最终在权限域名服务器得到我们想要的地址.
由于迭代查询成本较大,我们在这里实现的思路就是
在请求主机和本机域名服务器之间使用递归查询
在本地域名服务器和另外三个之间,使用迭代查询.
3.3.域名缓存
为了提升域名系统的查询效率,减少互联网上数据查询的数量,在一些关键节点上,我们习惯做一些缓存,也就是直接记录访问过的域名和IP地址之间的关系.
这种服务一般在主机上或者说本地域名服务器上实现 , 并且一般为每个条目都会设置一个计时器,一旦超出一定的时间,就会删除掉这个缓存.
4.文件传送协议FTP
文件传送协议(FTP)是因特网上使用最广的协议之一了,这个协议允许用户知名文件格式和类型,允许用户指明操作文件的权限.一般使用BS架构来进行实现,如图所示
FTP在构建链接和传输文件的时候,用到两个通道,
第一条通道是通过TCP,让用户和服务器之间进行链接的命令通道.
命令通道基本由TCP发起请求,FTP服务器以默认接口21作为应答,实现的TCP链接,如图所示
第二条通道被称之为数据通道,是为了发送数据而链接的通道,根据联系方式,应答端口的不同,我们根据数据通道不同的建立方式,将FTP协议的服务模式分为两种:主动模式,被动模式
主动模式下: 数据通道的TCP链接由FTP服务器发起,根据默认的端口号20完成链接建立服务,"我就在这里等你",服务器如是说
被动模式下:数据通道的TCP链接由客户发起,客户先告知服务器需要准备哪个端口,随后对这个端口进行TCP链接的建立.
另外要说明一点,链接控制在整个会话期间一直打开,也就是命令通道
而数据连接,也就是文件传送的数据通道,每次传送时才会建立,传送结束就会关闭.
5.电子邮件和SMTP协议
电子邮件算是最常见的网络应用之一了 , 特点为非实时通信 , 这个应用依然使用BS架构来进行实现,其三个主要构件为:用户代理(软件或者web), 邮件服务器,以及电子邮件所需要的协议
前两个我们不解释了,主要简单说说最后的这个协议以及会用到的东西,邮件需要的协议一共分为两种,一种是邮件发送协议,一种是邮件读取协议
先说说邮件发送协议中的SMTP
SMTP协议,又被称作简单邮件传输协议,这个协议没有那么多乱七八糟的处理机制,核心其实就是先进行确认,确认邮箱以及邮件有效就进行传送,然后断开链接即可,如图所示
在这个传输过程中,我们可以称呼电子邮件为这个协议的PDU,但是我觉得这个数据形式和头部大家应该熟的不能再熟了.
最开始的SMTP不能传输非ASCII以外的信息,因此后续提出了多用途因特网邮件扩展MIME
这个东西可以实现ASCII和非ACSII的转化了
然后再简单说一下邮件传输协议中的邮件阅读协议
常用的邮件阅读协议有两个,这两种协议都基于TCP链接实现
邮局协议POP:
简单,但是功能有限,不允许用户在邮件服务器上管理自己的邮件
因特网邮件访问协议IMAP:
可以
6.www
以前有个段子 world wide web的发音速度比读www还快...........
万维网是什么我们就不多解释了,其本身是一个巨大的集成样式应用,后面这些内容也和前端有很大关系了,所以这里就简单说明几个概念
1.统一资源定位符:
url通常由四个部分组成,协议,主机,端口,路径,也就是我们俗称的网址
2.万维网文档
前端三剑客
3.超文本传输协议http
HTTP的默认端口号为80,主要实现了浏览器(即万维网客户端进程),向万维网服务器发送请求文档,并且将文档返还.支持持续链接和非持续链接两种方式
报文格式.....无需多言,前端开发者们懂得都懂
4.cookie
我之前在面试的时候,面试官给我一个问题,前端里面都有哪些存储数据的东西?\
有一个我没答上来,就是cookie,因为cookie内可以存储一些和用户有关的东西.
cookie在功能上可以理解为后端给前端的一个表示符号,前端用这个表示符号向后端表明自己的身份,同时获取对应的服务.
5.缓存和代理
万维网的缓存也被称作web缓存,,位于服务器上的web缓存也可称之为代理服务器
