应用层

应用层

应用层概述

• 应用层是计算机网络体系结构的最顶层，是设计和建立计算机网络的最终目的，也是计算机网络中发展最快的部分。
• 早期基于文本的应用(电子邮件、远程登录、文件传输、新闻组)20世纪90年代将因特网带入千家万户的万维网www
• 当今流行的即时通信、P2P文件共享及各种音视频应用
• 计算设备的小型化和”无处不在”，宽带住宅接入和无线接
• 的日益普及和迅速发展，为未来更多
• 的新型应用提供了广阔的舞台。
• 在本章中，我们以一些经典的网络应用为例来学习有关网络应用的原理、协议和实现方面的知识。
• 万维网www
• 域名系统DNS
• 动态主机配置协议DHCP
• 电子邮件
• 文件传送协议FTP
• P2P文件共享
• 多媒体网络应用

客户/服务器(Client/Server, C/S)方式

• 客户和服务器是指通信中所涉及的两个应用进程。
• 客户/服务器方式所描述的是进程之间服务和被服务的关系。
• 客户是服务请求方，服务器是服务提供方。
• 服务器总是处于运行状态，并等待客户的服务请求。服务器具有固定端口号（例如HTTP服务器的默认端口号为80) ,而运行服务器的主机也具有固定的IP地址。
• C/S方式是因特网上传统的、同时也是最成熟的方式，很多我们熟悉的网络应用采用的都是C/S方式。包括万维网www、电子邮件、文件传输FTP等。
• 基于C/S方式的应用服务通常是服务集中型的，即应用服务集中在网络中比客户计算机少得多的服务器计算机上。
• 由于一台服务器计算机要为多个客户机提供服务，在C/S应用中，常会出现服务器计算机跟不上众多客户机请求的情况。
• 为此，在C/S应用中，常用计算机群集（或服务器场)构建一个强大的虚拟服务器。

对等(Peer-to-Peer, P2P)方式

• 在P2P方式中，没有固定的服务请求者和服务提供者，分布在网络边缘各端系统中的应用进程是对等的，被称为对等方。对等方相互之间直接通信，每个对等方既是服务的请求者，又是服务的提供者。
• 目前，在因特网上流行的P2P应用主要包括P2P文件共享、即时通信、P2P流媒体、分布式存储等。
• 基于P2P的应用是服务分散型的，因为服务不是集中在少数几个服务器计算机中，而是分散在大量对等计算机中，这些计算机并不为服务提供商所有，而是为个人控制的桌面计算机和笔记本电脑，它们通常位于住宅、校园和办公室中。
• P2P方式的最突出特性之一就是它的可扩展性。因为系统每增加一个对等方，不仅增加的是服务的请求者，同时也增加了服务的提供者，系统性能不会因规模的增大而降低。
• P2P方式具有成本上的优势，因为它通常不需要庞大的服务器设施和服务器带宽。为了降低成本，服务提供商对于将P2P方式用于应用的兴趣越来越大。

域名系统DNS (Domain Name System)

• 因特网采用层次树状结构的域名结构，域名的结构由若干个分量组成，各分量之间用”点”隔开，分别代表不同级别的域名。
• 每一级的域名都由英文字母和数字组成，不超过63个字符，不区分大小写字母。
• 级别最低的域名写在最左边，而级别最高的顶级域名写在最右边。
  
• 域名系统既不规定一个域名需要包含多少个下级域名，也不规定每一级的域名代表什么意思。
  
• cn： 是顶级域名，表示中国;
• edu： 是在其下注册的二级域名。表示教育机构;
• hnust： 是在edu下s注册的级域名。表示湖南科技大学;
• nic： 是由我校自行管理的四级域名，表示网络信息中心。

顶级域名TLD (Top Level Domain)分为以下三类:

• 国家顶级域名nTLD采用ISO 3166的规定。 如cn表示中国，us表示美国，uk表示英国、等等。
• 通用顶级域名gTLD最常见的通用顶级域名有七个 即: com(公司企业). net(网络服务机构)、org(非营利性组织)、int(国际组织)、edu(美国教育结构).gov(美国政府部门)、mil(美国军事部门)
• 反向域arpa 用于反向域名解析，即IP地址反向解析为域名

在国家顶级域名下注册的二级域名均由该国家自行确定。例如，顶级域名为jp的日本，将其教育和企业机构的二级域名定为ac和co，而不用edu和com.

我国(中国)则将二级域名划分为以下两类:

类别域名共七个:

1. ac(科研机构)、
2. com(工、商、金融等企业)、
3. edu(教育机构)
4. gov(政府部门)
5. net(提供网络服务的机构)
6. mil(军事机构）
7. org (非营利性组织)。

行政区域名

共34个，适用于我国的各省、自治区、直辖市。例如: bj为北京市、sh为上海市，js为江苏省，等等。

因特网的域名空间

这种按等级管理的命名方法便于维护名字的唯一性，并且也容易设计出一种高效的域名查询机制。需要注意的是，域名只是个逻辑概念并不代表计算机所在的物理地点。

域名服务器分类

域名和IP地址的映射关系必须保存在域名服务器中，供所有其他应用查询。显然不能将所有信息都储存在一台域名服务器中。
DNS使用分布在各地的域名服务器来实现域名到IP地址的转换。

域名服务器可以划分为以下四种不同的类型:

• 根域名服务器: 根域名服务器是最高层次的域名服务器。 每个根域名服务器都知道所有的顶级域名服务器的域名及其IP地址。因特网上共有13个不同IP地址的根域名服务器。尽管我们将这13个根域名服务器中的每一个都视为单个的服务器，但”每台服务器”实际上是由许多分布在世界各地的计算机构成的服务器群集。当本地域名服务器向根域名服务器发出查询请求时，路由器就把查询请求报文转发到离这个DNS客户最近的一个根域名服务器。这就加快了DNS的查询过程，同时也更合理地利用了因特网的资源。 根域名服务器通常并不直接对域名进行解析，而是返回该域名所属顶级域名的顶级域名服务器的IP地址。
• 顶级域名服务器:
  这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。 当收到DNS查询请求时就给出相应的回答（可能是最后的结果，也可能是下一级权限域名服务器的IP地址)。
• 权限域名服务器:
  这些域名服务器负责管理某个区的域名。每一个主机的域名都必须在某个权限域名服务器处注册登记。因此权限域名服务器知道其管辖的域名与IP地址的映射关系。另外，权限域名服务器还知道其下级域名服务器的地址。
• 本地域名服务器: 本地域名服务器不属于上述的域名服务器的等级结构。当一个主机发出DNS请求报文时，这个报文就首先被送往该主机的本地域名服务器。 本地域名服务器起着代理的作用，会将该报文转发到上述的域名服务器的等级结构中。每一个因特网服务提供者ISP，一个大学，甚至一个大学里的学院，都可以拥有一个本地域名服务器，它有时也称为默认域名服务器。本地域名服务器离用户较近，一般不超过几个路由器的距离，也有可能就在同一个局域网中。 *本地域名服务器的IP地址需要直接配置在需要域名解析的主机中。

域名解析的过程

• 递归查询
• 迭代查询

递归查询

迭代查询

由于递归查询对于被查询的域名服务器负担太大，通常采用以下模式:从请求主机到本地域名服务器的查询是递归查询，而其余的查询是迭代查询。

高速缓存

为了提高DNS的查询效率，并减轻根域名服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛地使用了高速缓存。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

• 由于域名到IP地址的映射关系并不是永久不变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并删除超过合理时间的项（例如，每个项目只存放两天)
• 不但在本地域名服务器中需要高速缓存，在用户主机中也很需要。许多用户主机在启动时从本地域名服务器下载域名和IP地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到域名时才向域名服务器查询。同理，主机也需要保持高速缓存中内容的正确性。
• DNS报文使用运输层的UDP协议进行封装，运输层端口号为53

电子邮件系统

• 电子邮件系统采用客户/服务器方式。
• 电子邮件系统的三个主要组成构件:用户代理（客户端软件），邮件服务器，以及电子邮件所需的协议。
• 用户代理是用户与电子邮件系统的接口，又称为电子邮件客户端软件。
• 邮件服务器是电子邮件系统的基础设施。因特网上所有的ISP都有邮件服务器，其功能是发送和接收邮件，同时还要负责维护用户的邮箱。
• 协议包括邮件发送协议（例如SMTP）和邮件读取协议（例如POP3，IMAP) 。

邮件发送流程

1. 发送方客户端使用SMTP协议发送发送邮件到 发送方邮件服务器
2. 发送方邮件服务器使用SMTP协议发送发送邮件到 接收方邮件服务器
3. 接收方客户端使用POP3协议从 接收方邮件服务器读取邮件

电子邮件的信息格式

电子邮件的信息格式并不是由SMTP定义的，而是在RFC 822中单独定义的。这个RFC文档已在2008年更新为RFC 5322。一个电子邮件有信封和内容两部分。而内容又由首部和主体两部分构成。

• SMTP协议只能传送ASCI码文本数据，不能传送可执行文件或其他的二进制对象。
• SMTP不能满足传送多媒体邮件(例如带有图片、音频或视频数据)的需要。并且许多其他非英语国家的文字。(例如中文、俄文、甚至带有重音符号的法文或德文)也无法用SMTP传送。
• 为解决SMTP传送非ASCII码文本的问题，提出了多用途因特网邮件扩展MIME (Multipurpose Internet Mail Extensions)。
• 实际上，MIME不仅仅用于SMTP,也用于后来的同样面向ASCII字符的HTTP。

邮件读取

常用的邮件读取协议有以下两个:

• 邮局协议POP (Post Office Protocol) ，POP3是其第三个版本， 是因特网正式标准。非常简单、功能有限的邮件读取协议。用户只能以下载并删除方式或下载并保留方式从邮件服务器下载邮件到用户方计算机。不允许用户在邮件服务器.上管理自己的邮件。(例如创建文件夹， 对邮件进行分类管理等)
• 因特网邮件访问协议IMAP (Internet Message Access Protocol)，IMAP4是其第四个版本，目前还只是因特网建议标准。功能比POP3强大的邮件读取协议。 用户在自己的计算机上就可以操控邮件服务器中的邮箱，就像在本地操控- -样,因此IMAP是-一个联协议。
• POP3和IMAP4都采用 基于TCP连接的客户/服务器方式。POP3使用熟知端口110, IMAP4使用熟
  知端口143。

基于万维网的电子邮件

• 口通过浏览器登录 (提供用户名和口令)邮件服务器万维网网站就可以撰写、收发、阅读和管理电子邮件。这种工作模式与IMAP很类似，不同的是用户计算机无需安装专门的用户代理程序,只需要使用通用的万维网浏览器。
• 邮件服务器网站通常都提供非常强大和方便的邮件管理功能， 用户可以在邮件服务器网站上管理和处理自己的邮件,而不需要将邮件下载到本地进行管理。

万维网WWW (World Wide Web)

万维网WWW (World Wide Web)并非某种特殊的计算机网络。它是- -个大规模的、联机式的信息储藏所,是运行在因特网.上的一个分布式应用。万维网利用网页之间的超链接将不同网站的网页链接成一张逻辑上的信息网。

为了方便地访问在世界范围的文档，万维网使用统-资源定位符URL来指明因特网上任何种类 “资源”的位置。

URL的一般形式由以下四个部分组成:

                            <协议>://<主机>:<端口>/<路径>
</路径></端口></主机></协议>

超文本传输协议HTTP

超文本传输协议HTTP(HyperText Transfer Protocol),HTTP定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档，以及万维网服务器怎样把万维网文档传送给浏览器。

• HTTP/1.0采用非持续连接方式。在该方式下，每次浏览器要请求-个文件都要与服务器建立TCP连接,当收到响应后就立即关闭连接。
• 每请求一个文档就要有两倍的RTT的开销。 若-一个网页 上有很多引用对象 (例如图片等)，那么请求每一个对象都需要花费2RTT的时间。
  
• HTTP/1.1采用持续连接方式。在该方式下，万维网服务器在发送响应后仍然保持这条连接，使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上引用的对象，而是只要这些文档都在同个服务器上就行。
• 为了进一步提高效率， HTTP/1.1 的持续连接还可以使用流水线方式工作，即 浏览器在收到HTTP的响应报文之前就能够连续发送多个请求报文。这样的一个接一个的请求报文到达服务器后， 服务器就发回一个接一个的响应报文。这样就节省了很多个RTT时间，使TCP连接中的空闲时间减少，提高了下载文档的效率。

HTTP的报文格式

HTTP是面向文本的，其报文中的每一一个字段都是一些ASCII码串， 并且每个字段的长度都是不确定的。

请求报文格式

GET /index.htm HTTP/1.1        请求行:指明方法GET, URL,HTTP版本
Host: www.hnust.cn             首部行的开始:指明服务器的域名
Connection: close              告诉服务器发送完请求的文档后就可释放连接
User-Agent: Mozilla/5.0        告诉服务器浏览器的类型及版本
Accept-Language: cn            告诉服务器用户希望优先得到中文版本的文档
                               报文的最后还有一个空行

响应报文格式

Cookie

使用Cookie在服务器上记录用户信息。

早期的万维网应用非常简单，仅仅是用户查看存放在不同服务器.上的各种静态的文档。因此HTTP被设计为
一种无状态的协议。这样可以简化服务器的设计。现在，用户可以通过万维网实现各种复杂的应用，如网.上购物、电子商务等。这些应用往往需要万维网服务器能够识别用户。
Cookie提供了-种机制使得万维网服务器能够”记住”用户，而无需用户主动提供用户标识信息。也就是说，Cookie是- 种对无状态的HTTP进行状态化的技术。

Original: https://www.cnblogs.com/xysgo/p/16199830.html
Author: 菜阿
Title: 应用层