[计算机网络]-应用层-CSDN博客

本文链接：https://blog.csdn.net/renboyu010214/article/details/106896805

应用层概述

参考模型中的各层一般都满足“应用下层的服务，为上层提供服务”，但应用层较为特殊，因为应用层没有上层，所以应用层直接为模型外的用户提供服务，应用层是最靠近用户的一层

应用层特点

没有应用层，就没有网络通信支持
参考模型中唯一的一层，不需为它的上层服务
它向参考模型之外的用户提供服务
网络应用程序可被分为两大类
- 直接网络应用程序 Browser , e-mail ,FTP , Telnet
- 间接网络应用程序 Word , resource manager , (via Redirector)

重定向器(Redirector)

置于应用中的一种小软件
是透明的
间接网络应用都是通过重定向器实现网络功能

主要的直接应用

传统经典的应用

DNS，电子邮件E-mail，万维网World wide web，文件传输ftp，远程登陆telnet

新应用

微信，多媒体，App

域名系统DNS概述

在互联网中，直接使用IP地址作为机器的绝对地址是行不通的，具体原因有2点：1.计算机可能常常地更换IP地址，所以，通过IP地址去访问某台机器就会发生问题。2.IP地址难于记忆，且毫无规律。因此，我们只需要通过一个有规律性且永久不会更换的名字来标识某个IP地址，就可以解决上述问题，这就是我们所说的域名。

但是在传输数据的过程中，或是为数据加上MAC地址，或是为文件加上IP地址，却从来没有为数据加上过域名，因此我们必须使用域名系统DNS，来将一个个名字映射到对应的IP地址

ARPANET时代，有一个文件hosts.txt，列出了当时网络上所
有的主机和它们对应的IP地址（当网络很小的时候，可以工
作得很好），这份文件如今依然存在于电脑的
“C:\Windows\System32\drivers\etc\hosts” 路径下。但是随着互联网发展，用一份文件映射所有IP地址和域名变得不现实，因此才产生了如今的域名系统

域名系统DNS

(Domain Name System)

DNS是分层次的，基于域的命名方案，且采用了分布式数据
库系统来实现

DNS系统

DNS首先将整个互联网分成250个顶级域，每个顶级域被分为多个子域，子域仍可以继续划分出更多子域，所有这些域最终将会形成一棵树，树上的叶子代表没有子域的域

顶级域由ICANN负责管理，顶级域分为两类：通用域（.com,.edu…）以及国家域（.jp,.cn,.nl…）

顶级域名由ICANN委任的注册机构负责运行

顶级域名

中国（.cn）二级域名

域名	含义	域名	含义	域名	含义
ac	研究机构	gd	广东	bj	北京
co	商业公司	gx	广西	tj	天津
or	非盈利性组织	sc	四川	eb	河北
net	提供网络服务的单位	gz	贵州	sx	山西
edu	教育和科研单位	yn	云南	nm	内蒙古
go	政府机构	xz	西藏	en	河南
ha	海南	sn	陕西	ln	辽宁
ah	安徽	gs	甘肃	jl	吉林
jx	江西	qh	青海	hl	黑龙江
sd	山东	nx	宁夏	sh	上海
fj	福建	xj	新疆	js	江苏
hn	湖南	hb	湖北	zj	浙江

(获得一个二级域名无需到ICANN申请)，只需要到运行顶级域名的注册机构去检查带申请名字是否可用，并且不是别人商标即可申请

域名（Domain Names）

每个域的名字是：

从它向上到根（未命名）的路径，各个部分间用圆点隔开

域名可以是绝对的，也可以是相对的，绝对域名总是以圆点
结束（如： eng.sun.com. ）
- 相对域名必须在一定的上下文环境中被解释出来才有意义，从而唯一地确定其真实的含义
- 绝对域名和相对域名都引用了域名树中一个特定的节点，以及它下面的所有节点
域名是大小写无关的（ case insensitive ）
各组成部分的名字最多有 63 个字符长，整个路径不超过 255个字符
没有规则限制同时在两个或多个顶级域名下的注册 (如：
sony.com and sony.nl)—这可能导致域名抢注
每个域自己控制它下面的域（子域）的划分
- 例如：日本的 ac.jp 和 co.jp 分别对应于 edu 和com
- 荷兰却不这样区分，它把所有的都放在nl之下
- 要创建一个新的域，创建者必须得到该新域的上级域的许可，一旦创建成功，该新域可以创建子域，而无需征得上级域的同意
域名遵循的是组织的边界而不是物理网络的边界

资源记录

每个域无论是单主机域还是顶级域，都有一组跟它相关联的资料记录，当一个解析器将域名传递给DNS时，DNS返回的是与这个资源相关联的资源记录，所以DNS的主要功能，是将域名映射到资源记录上去

资源记录的组成

域名（Domain name）：
- 指出这条记录适用于哪个域，通常每个域有多条记录，而数据库则保存了多个域的信息
- 域名字段是匹配查询条件的主要关键字
- 记录在数据库中的顺序是无关紧要的
生存期（Time to Live）：指示该条记录的稳定程度
- 极稳定的信息会被分配一个很大的值，如 86400 （一天时间的秒数）
- 非常不稳定的信息会被分配一个很小的值，如60 （1分钟）
类别（Class）：对于互联网信息，它总是 IN
类型（Type）：指出了这是什么类型的记录（A标识IPv4,AAAA表示IPv6…）
值（Value）：类型对应的值，可以是数字，可以是ASCII码等等

域名服务器

资源记录存储在资源服务器中，整个互联网需要多台而不是一台域名服务器，DNS名字空间被分割成不相交的区域（zones），每个区域包含域名树的一部分，也包含一台主域名服务器（ primary name server ）。

主域名服务器从自己硬盘的一个文件中读取信息，次域名服
务器（ secondary name servers ）分享这些信息

根域名服务器

最重要的域名服务器；存储所有顶级域名的名字和IP

无论是哪个本地域名服务器，无论何时，只要它无法回答一个查询请求，它都会向根域服务器求救 (for help)
全球有 13 根域服务器，它们的名字分别是a to m（前13 个字母）
全球还有多台根域名服务器的镜像，以便各个国家就近找到一个根域名服务器救急

电子邮件

电子邮件系统通常由两部分组成

用户代理(UA)：让用户能够阅读和发送邮件
- 本地程序，提供命令行或图形界面，让用户和电子邮件系统交互
消息传输代理 (MTA)：将消息从源端送到目标端
- 通常是系统守护进程，即运行在后台的进程，在系统中传递电子邮件，又被称为邮件服务器

电子邮件的体系结构

电子邮件体系结构

用户首先在UA编辑好邮件然后提交，接下来邮件会被提交到发方的邮件传输代理（MTA），接下来发方的邮件传输代理将会把邮件传输到收方的MTA上，最终邮件将被从收方的MTA传送到收方的用户代理

用户代理－UA

UA通常是一个程序，一般称为电子邮件阅读器，常见的UA有： Gmail,outlook,foxmail…

用户代理完成的功能

入境邮件的显示
归档：垃圾邮件、某重要人物的邮件
邮件处置：回复、转发、删除、保存……
自动响应
签名块
邮件列表（mailing-list）：本地、传输代理

电子邮件消息格式

ASCII 电子邮件信息通常采用 RFC 822

消息由一个基本的信封(RFC821)、一些头域、一个空行和消息体组成。
每个头域（逻辑地）由一行ASCII文本组成，包括域名、一个冒号，对于大多数头域来说，还包括一个值
RFC822是几十年前设计的，没有区分信封域和头域
虽然 RFC 5322作了修正，但是因为RFC822已经广泛使用，完全重新设计是不可能的
用户可以发明新的消息头以供自己私人使用，只要这些消息头以 X-开头

消息头

RFC 822

信头字段	目的
To	收信人地址
CC	抄送：另一个收信人地址
BCC	密送：收信人地址，但其它收信人看不到这个收信人的地址。
From	邮件作者
Sender	发信人
Received	沿线各转运代理增加的线路
Return path	回邮地址

RFC 5322新增

信头字段	目的
Date	发信日期
Reply-To	回邮地址
Subject	主题
Comments	备注
Keywords	关键字，用来进一步搜索邮件
In-Reply-To	被当前邮件回复的邮件的ID
References	几乎同In-Reply-To一样
Encrypted	加密邮件的加密类型

MIME 多用途互联网邮件扩展

(the Multipurpose Internet Mail Extensions)

RFC5322无法处理带有重音符的语言（如法语）、非拉丁字母（如俄语）、不带字母的语言（如汉语，日语）、完全不包含文本的消息（如视频）的邮件，为此提出了MIME来解决此问题

MIME的基本思想是继续使用 RFC822格式，但是在消息体中
增加了结构，且为非ASCII消息定义了编码规则
– 由于没有偏离 RFC822，MIME消息可以使用现有的程序和协议来发送
– 只有接收和发送的程序必须要改变

MIME增加的消息头

Header	Meaning
MIME-Version	标识MIME版本
Content－Description	描述邮件包含的内容
Content－ID	唯一标识符
Content-Transfer-Encoding	传输过程中编码方式
Content-Type	邮件内容的类型和格式（目前定义了七种类型：文本，图片，视频，音频，应用…每个类型还有一个或多个子类型）

简单邮件传输协议SMTP

（Simple Mail Transfer Protocol）

上文讲述了如何编写邮件，接下来进行的就是邮件的传输，邮件的传输通过简单邮件传输协议实现，这是一个简单的 ASCII 协议

源机与目标机（SMTP守护进程在监听）的25端口建立TCP连接
。如果消息不能被投递，则向消息的发送方返回一个错误报告（包含了不能投递消息的第一部分）

SMTP传输步骤

连接建立在端口 25
数据交换
- 客户机（作为客户）等待服务器（作为服务器）首先开始通话
- 服务器首先发送一行文本，给出它自己的标识，并且告诉客户机是否已准备好接收邮件
- 如果服务器没有准备好，则客户机释放连接，以后再重试
- 如果服务器愿意接收电子邮件，则客户机申明发信人和收信人
- 如果服务器确实存在这样的收信人，则服务器指示客户可以发送了
- 客户发送消息，服务器回发确认
连接释放

SMTP存在的问题

没有认证，导致容易接收垃圾邮件
传输的是ASCII消息而不是二进制数据，需要编码，效率低下
邮件是明文，涉及邮件安全问题

通过上述流程不难发现，保证邮件发送成功的前提是发送端与接收端成功建立TCP连接，这就需要接收端与发送端设备需要在发送时都保持开机状态，但这是不现实的，收方不可能一直在线，而如果收方不在线，发方就无法发送邮件

最后的投递

为解决上述问题，就需要在邮件服务提供商ISP的一台机器上运行一个消息传输代理（message transferagent）；这台机器可以一天24小时运行，随时都可以接收邮件

然后设计一个协议，允许用户在上线后和消息传输代理MTA联系，然后把邮件从ISP那里拷贝到用户，早期使用的协议是POP-3协议，即邮局协议3版本，改进版本为IMAP。协议的作用范围在接收端用户和代理服务器之间

POP3

当用户启动邮件阅读器的时候，POP3开始工作
用户呼叫ISP（除非已有一个连接），然后与MTA在110端口
建立TCP连接
一旦连接建立， POP3协议按顺序经历三种状态
- 授权（Authorization）处理用户登录的过程
- 事务（Trnsactions）用户收取电子邮件，并将邮件标记为删除
- 更新（Update）将标为删除的电子邮件删除

POP3协议不适合应用于移动端收发邮件，因为在移动端收发邮件会导致POP3将邮件标记为删除，无法在其他客户端查看，这个问题，在IMAP中得到了解决