# 应用层概述
- 应用层是计算机网络体系结构的最顶层,是设计和建立计算机网络的最终目的,也是计算机网络中发展
最快的部分。- 早期基于文本的应用(电子邮件、远程登录、文件传输、新闻组)
- 20 世纪 90 年代将因特网带入千家万户的万维网 WWW
- 当今流行的即时通信、P2P 文件共享及各种音视频应用
- 计算设备的小型化和 “无处不在”,宽带住宅接入和无线接入的日益普及和迅速发展,为未来更多的新型应用提供了广阔的舞台
# 客户 / 服务器方式和对等方式
- 网络应用程序运行在处于网络边缘的不同的端系统上,通过彼此间的通信来共同完成某项任务。
- 开发一种新的网络应用,首先要考虑的问题就是网络应用程序在各种端系统上的组织方式和它们之间的关系。目前流行的主要有以下两种:
- 客户 / 服务器(Client/Server,C/S)方式
- 对等(Peer-to-Peer,P2P)方式
# 客户 / 服务器(Client/Server,C/S)方式
- 客户 / 服务器(Client/Server,C/S)方式
- 客户和服务器是指通信中所涉及的两个应用进程。
- 客户 / 服务器方式所描述的是进程之间服务和被服务的关系。
- 客户是服务请求方,服务器是服务提供方。
- 服务器总是处于运行状态,并等待客户的服务请求
- C/S 方式是因特网上传统的、同时也是最成熟的方式,很多我们熟悉的网络应用采用的都是 C/S 方式。包括万维网 WWW、电子邮件、文件传输 FTP 等。
- 基于 C/S 方式的应用服务通常是服务集中型的,即应用服务集中在网络中比客户计算机少得多的服务器计算机上。
- 由于一台服务器计算机要为多个客户机提供服务,在 C/S 应用中,常会出现服务器计算机跟不上众多客户机请求的情况。
- 为此,在 C/S 应用中,常用计算机群集(或服务器场)构建一个强大的虚拟服务器。
服务器具有固定端口号(例如 HTTP 服务器的默认端口号为 80),而运行服务器的主机也具有固定的 IP 地址。
# 对等(Peer-to-Peer,P2P)方式
- 对等(Peer-to-Peer,P2P)方式
- 在 P2P 方式中,没有固定的服务请求者和服务提供者,分布在网络边缘各端系统中的应用进程是对等的,被称为对等方。对等方相互之间直接通信,每个对等方既是服务的请求者,又是服务的提供者。
- 目前,在因特网上流行的 P2P 应用主要包括 P2P 文件共享、即时通信、P2P 流媒体、分布式存储等。
- 基于 P2P 的应用是服务分散型的,因为服务不是集中在少数几个服务器计算机中,而是分散在大量对等计算机中,这些计算机并不为服务提供商所有,而是为个人控制的桌面计算机和笔记本电脑,它们通常位于住宅、校园和办公室中。
- P2P 方式的最突出特性之一就是它的可扩展性。因为系统每增加一个对等方,不仅增加的是服务的请求者,同时也增加了服务的提供者,系统性能不会因规模的增大而降低。
- P2P 方式具有成本上的优势,因为它通常不需要庞大的服务器设置和服务器带宽。为了降低成本,服务提供商对于将 P2P 方式用于应用的兴趣越来越大。
# 动态主机配置协议
# 动态主机配置协议 DHCP 的作用
- 只需为 DHCP 服务器配置 IP 地址范围,子网掩码,默认网关,DNS 服务器等信息即可自动为设备配置 IP 地址
- 动态主机配置协议 DHCP 可为计算机自动配置网络参数,使得计算机 “即插即联网”(Plug-and-Play Networking)。DHCP 目前是因特网草案标准 [RFC 2131,RFC 2132]
# 动态主机配置协议 DHCP 的基本工作过程
- DHCP 客户广播发送 DHCP 发现报文,此时没有 IP, 源 IP 为 0.0.0.0, 目的 IP 是广播;发现报文内部复杂,封装有事务 ID 和 DHCP 客户端的 MAC 地址
- 非 DHCP 服务器没有 DHCP 服务器进程,无法接受报文。收到后丢弃; 对于特殊地址的报文不发送 ICMP 差错报告报文
- DHCP 服务器始终运行进程,做出响应;查询自己的数据库,检测是否有该 MAC 地址的配置信息;若无则使用默认信息封装
- DHCP 提供报文目的 IP 依然是广播 (此时客户端依然没有获得 IP), 网络中的 DHCP 服务器没有监听 68 端口进程,丢弃;客户接受报文,根据 DHCP 提供报文中的事务 ID 来判断是否是自己的报文 (与之前发送的发现报文事务 ID 相等)
- DHCP 提供报文中还封装有事务 ID, 配置信息:IP 地址,子网掩码,地址租期,默认网关,DNS 服务器等;DHCP 服务器使用 ARP 确保所选 IP 地址未被网络中的其他主机占用
- DHCP 客户若收到多个提供报文,从中选择一个,一般先到的
- DHCP 客户端发送 DHCP 回应给服务器,先征得服务器同意才去使用给的 IP; 此时源 IP 依然还是 0.0.0.0 (还没开始用), 目的 IP 依然还是广播 (不用给每个服务器单独说自己要不要用对方)
- 请求报文中封装有事务 ID,DHCP 客户端的 MAC 地址,接受租约中的 IP 地址,提供次租约的 DHCP 服务器端的 IP 地址等
- 若接受,服务器给客户发送 DHCP 确认报文,源 IP 是服务器 IP, 目的 IP 依然为广播 (还是没有用上给的 IP)
- 收到确认报文之后客户端使用 ARP 检测分到的 IP 是否已被占用
- 若占用,给 DHCP 服务器发送 DHCP DECLINE 报文撤销租约,重新发送发现报文
- 没占用就可以直接用了
- 租期过了一半,DHCP 客户端会发送 DHCP 请求报文请求更新租用期,源 IP 是自己申请的,目的 IP 是服务器
- 服务器若同意,发回确认报文
- 若不同意则发否认报文,客户端立即弃用并重新广播发现报文
- 未响应则在租用期过了 87.5% 后再次发送
- 还是未响应,到期自动停用这个 IP
- DHCP 客户可以随时终止使用 IP, 发送 DHCP RELEASE 释放报文即可
# DHCP 中继代理
- 处在一个路由器下的子网,若子网或路由器下没有 DHCP 服务器,广播报文时无法获取 IP
- 只能路由器配置 DHCP 服务器的 IP 地址并使之成为 DHCP 中继代理
- 路由器收到广播的 DHCP 发现报文后,单播转发给 DHCP 服务器
# 域名系统
# 域名系统的作用
- 为因特网的规模很大,这样的域名服务器肯定会因为超负荷而无法正常工作,而且一旦域名服务器出现故障,整个因特网就会瘫痪。
- 早在 1983 年,因特网就开始采用层次结构的命名树作为主机的名字(即域名),并使用分布式的域名系统 DNS。
- DNS 使大多数域名都在本地解析,仅少量解析需要在因特网上通信,因此系统效率很高。
- 由于 DNS 是分布式系统,即使单个计算机出了故障,也不会妨碍整个系统的正常运行
# 因特网的域名结构
- 因特网采用层次树状结构的域名结构。
- 域名的结构由若干个分量组成,各分量之间用 “点” 隔开,分别代表不同级别的域名。
- … . 三级域名。二级域名。顶级域名
- 每一级的域名都由英文字母和数字组成,不超过 63 个字符,不区分大小写字母。
- 级别最低的域名写在最左边,而级别最高的顶级域名写在最右边。
- 完整的域名不超过 255 个字符。
- 域名系统既不规定一个域名需要包含多少个下级域名,也不规定每一级的域名代表什么意思。
- 各级域名由其上一级的域名管理机构管理,而最高的顶级域名则由因特网名称与数字地址分配机构 ICANN 进行管理。
- 顶级域名(Top Level Domain,TLD)分为以下三类:
- 国家顶级域名 nTLD 采用 ISO 3166 的规定。如 cn 表示中国,us 表示美国,uk 表示英国、等等。
- 通用顶级域名 gTLD 最常见的通用顶级域名有七个,即:com(公司企业)、net(网络服务机构)、org(非营利性组织)、int(国际组织)、edu(美国教育机构)、gov(美国政府部门)、mil(美国军事部门)。
- 反向域 arpa 用于反向域名解析,即 IP 地址反向解析为域名。
- 在国家顶级域名下注册的二级域名均由该国家自行确定。例如,顶级域名为 jp 的日本,将其教育和企业机构的二级域名定为 ac 和 co,而不用 edu 和 com。
- 我国则将二级域名划分为以下两类:
- 类别域名 共七个:ac(科研机构)、com(工、商、金融等企业)、edu(教育机构)、gov(政府部门)、net(提供网络服务的机构)、mil(军事机构)和 org(非营利性组织)。
- 行政区域名 共 34 个,适用于我国的各省、自治区、直辖市。例如:bj 为北京市、sh 为上海市、js 为江苏省,等等。
# 因特网上的域名服务器
- 域名和 IP 地址的映射关系必须保存在域名服务器中,供所有其他应用查询。显然不能将所有信息都储存在一台域名服务器中。DNS 使用分布在各地的域名服务器来实现域名到 IP 地址的转换。
- 根域名服务器
- 根域名服务器是最高层次的域名服务器。
- 每个根域名服务器都知道所有的顶级域名服务器的域名及其 IP 地址。
- 尽管我们将这 13 个根域名服务器中的每一个都视为单个的服务器,但 “每台服务器” 实际上是由许多分布在世界各地的计算机构成的服务器群集。
- 当本地域名服务器向根域名服务器发出查询请求时,路由器就把查询请求报文转发到离这个 DNS 客户最近的一个根域名服务器。
- 这就加快了 DNS 的查询过程,同时也更合理地利用了因特网的资源。根域名服务器通常并不直接对域名进行解析,而是返回该域名所属顶级域名的顶级域名服务器的 IP 地址。
- 顶级域名服务器
- 顶级域名服务器负责管理在该顶级域名服务器注册的所有二级域名。
- 当收到 DNS 查询请求时就给出相应的回答,可能是最后的结果,也可能是下一级权限域名服务器的 IP 地址
- 权限域名服务器
- 权限域名服务器负责管理某个区的域名。
- 每一个主机的域名都必须在某个权限域名服务器处注册登记。因此权限域名服务器知道其管辖的域名与 IP 地址的映射关系。
- 另外,权限域名服务器还知道其下级域名服务器的地址。
- 本地域名服务器
- 本地域名服务器不属于上述的域名服务器的等级结构。
- 当一个主机发出 DNS 请求报文时,这个报文就首先被送往该主机的本地域名服务器。
- 本地域名服务器起着代理的作用,会将该报文转发到上述的域名服务器的等级结构中。
- 每一个因特网服务提供者 ISP,一个大学,甚至一个大学里的学院,都可以拥有一个本地域名服务器,它有时也称为默认域名服务器。
- 本地域名服务器离用户较近,一般不超过几个路由器的距离,也有可能就在同一个局域网中。本地域名服务器的 IP 地址需要直接配置在需要域名解析的主机中。
# 因特网的域名解析过程
递归查询与迭代查询
DNS 查询均为 UDP, 显然下面图中只需要 8 个 UDP 报文 (无丢失)
- 为了提高 DNS 的查询效率,并减轻根域名服务器的负荷和减少因特网上的 DNS 查询报文数量,在域名服务器中广泛地使用了高速缓存。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录
- 由于域名到 IP 地址的映射关系并不是永久不变,为保持高速缓存中的内容正确,域名服务器应为每项内容设置计时器并删除超过合理时间的项(例如,每个项目只存放两天)
- 不但在本地域名服务器中需要高速缓存,在用户主机中也很需要。许多用户主机在启动时从本地域名服务器下载域名和 IP 地址的全部数据库,维护存放自己最近使用的域名的高速缓存,并且只在从缓存中找不到域名时才向域名服务器查询。同理,主机也需要保持高速缓存中内容的正确性。
-
如果本地域名服务器无缓存,当采用递归方法解析另一网络某主机域名时,用户主机、本地域名服务器发送的域名请求消息数分别为
-
假设所有域名服务器均采用迭代查询方式进行域名解析,当 H4 访问规范域名为 www.abc.xyz.com 的网站时,域名服务器 201.1.1.1 在完成该域名解析过程中,可能发出 DNS 查询的最少和最多次数分别是
# 文件传输协议
- 将某台计算机中的文件通过网络传送到可能相距很远的另一台计算机中,是一项基本的网络应用,即文
件传送。 - 文件传送协议(File Transfer Protocol,FTP)是因特网上使用得最广泛的文件传送协议。
- FTP 提供交互式的访问,允许客户指明文件的类型与格式(如指明是否使用 ASCII 码),并允许文件具有存取权限(如访问文件的用户必须经过授权,并输入有效的口令)。
- FTP 屏蔽了各计算机系统的细节,因而适合于在异构网络中任意计算机之间传送文件。
- 在因特网发展的早期阶段,用 FTP 传送文件约占整个因特网的通信量的三分之一,而由电子邮件和域名系统所产生的通信量还要小于 FTP 所产生的通信量。只是到了 1995 年,万维网 WWW 的通信量才首次超过了 FTP。
# 文件传送协议 FTP 的作用
- FTP 的常见用途是在计算机之间传输文件,尤其是用于批量传输文件。
- FTP 的另一个常见用途是让网站设计者将构成网站内容的大量文件批量上传到他们的 Web 服务器。
# 文件传送协议 FTP 的基本工作原理
- 主动模式(建立数据通道时,FTP 服务器主动连接 FTP 客户)
- 有数据传送时,FTP 客户通过命令通道告知 FTP 服务器来与自己的另一个临时端口号建立 TCP 连接,以建立数据通道。
- 控制连接在整个会话期间一直保持打开,用于传送 FTP 相关控制命令。
- 数据连接用于文件传输,在每次文件传输时才建立,传输结束就关闭。
-
FTP 客户和服务器间传递 FTP 命令时,使用的连接是
-
下列关于 FTP 协议的叙述中,错误的是
# 电子邮件
# 电子邮件的作用
- 电子邮件 E-mail 是因特网上最早流行的一种应用,并且仍然是当今因特网上最重要、最实用的应用之一。
- 传统的电话通信属于实时通信,存在以下两个缺点:
- 电话通信的主叫和被叫双方必须同时在场;
- 一些不是十分紧迫的电话也常常不必要地打断人们的工作或休息。
- 而电子邮件与邮政系统的寄信相似。
- 发件人将邮件发送到自己使用的邮件服务器;
- 发件人的邮件服务器将收到的邮件按其目的地址转发到收件人邮件服务器中的收件人邮箱;
- 收件人在方便的时候访问收件人邮件服务器中自己的邮箱,获取收到的电子邮件。
- 电子邮件使用方便、传递迅速而且费用低廉。它不仅可以传送文字信息,而且还可附上声音和图像。
# 电子邮件系统的组成
- 电子邮件系统采用客户 / 服务器方式。
- 电子邮件系统的三个主要组成构件:用户代理,邮件服务器,以及电子邮件所需的协议。
- 用户代理是用户与电子邮件系统的接口,又称为电子邮件客户端软件。
- 邮件服务器是电子邮件系统的基础设施。因特网上所有的因特网服务提供者 ISP 都有邮件服务器,其功能是发送和接收邮件,同时还要负责维护用户的邮箱。
- 协议包括邮件发送协议(例如 SMTP)和邮件读取协议(例如 POP3,IMAP)。
# 简单邮件传送协议 SMTP 的基本工作过程
# 电子邮件的信息格式
- 电子邮件的信息格式并不是由 SMTP 定义的,而是在 [RFC 822] 中单独定义的。这个 RFC 文档已在 2008 年更新为 [RFC 5322]。一个电子邮件有信封和内容两部分。而内容又由首部和主体两部分构成。
首部包含:
- FROM 必填,但一般自动填入
- TO 必填,一个或多个收件人的电子邮件地址
- Cc 非必填,一个或多个抄送人邮件地址
- Subject: 必填,邮件主题 (王道书写的是可选关键字,存疑)
# 多用途因特网邮件扩展
- SMTP 协议只能传送 ASCII 码文本数据,不能传送可执行文件或其他的二进制对象。
- SMTP 不能满足传送多媒体邮件(例如带有图片、音频或视频数据)的需要。并且许多其他非英语国家的文字(例如中文、俄文、甚至带有重音符号的法文或德文)也无法用 SMTP 传送。
- 为解决 SMTP 传送非 ASCII 码文本的问题,提出了多用途因特网邮件扩展 (Multipurpose Internet Mail Extensions,MIME)。
- 增加了 5 个新的邮件首部字段,这些字段提供了有关邮件主体的信息,包括 MIME 版本,内容描述,内容标识,传送编码,内容类型。
- 定义了许多邮件内容的格式,对多媒体电子邮件的表示方法进行了标准化。
- 定义了传送编码,可对任何内容格式进行转换,而不会被邮件系统改变。
- 实际上,MIME 不仅仅用于 SMTP,也用于后来的同样面向 ASCII 字符的 HTTP。
- 发送方将非 ASCII 码通过 MIME 转换为 ASCII 码交给 SMTP, 接收方再通过 MIME 解码
# 常用的邮件读取协议
# 基于万维网的电子邮件
- 通过浏览器登录(提供用户名和口令)邮件服务器万维网网站就可以撰写、收发、阅读和管理电子邮件。这种工作模式与 IMAP 很类似,不同的是用户计算机无需安装专门的用户代理程序,只需要使用通用的万维网浏览器。
- 邮件服务器网站通常都提供非常强大和方便的邮件管理功能,用户可以在邮件服务器网站上管理和处理自己的邮件,而不需要将邮件下载到本地进行管理。
-
若用户 1 与用户 2 之间发送和接收电子邮件的过程中,用户 1-> 用户 1 的邮件服务器,用户 1 邮件服务器 -> 用户 2 邮件服务器,用户 2 邮件服务器 -> 用户 2 分别使用的应用层协议可以是
-
下列关于 SMTP 协议的叙述中,正确的是
-
无需转换即可由 SMTP 协议直接传输的内容是
# 万维网
# 万维网概述
- 万维网(World Wide Web,WWW)并非某种特殊的计算机网络。它是一个大规模的、联机式的信息储藏所,是运行在因特网上的一个分布式应用。
- 万维网利用网页之间的超链接将不同网站的网页链接成一张逻辑上的信息网。
- 万维网是欧洲粒子物理实验室的 Tim Berners-Lee 最初于 1989 年 3 月提出的。
- 1993 年 2 月,第一个图形界面的浏览器 Mosaic
- 1995 年著名的 Netscape Navigator 浏览器上市
- 浏览器最重要的部分是渲染引擎,也就是浏览器内核。负责对网页内容进行解析和显示。
- 不同的浏览器内核对网页内容的解析也有不同,因此同一网页在不同内核的浏览器里的显示效果可能不同;
- 网页编写者需要在不同内核的浏览器中测试网页显示效果。
Chrome | Firefox | Safari | Opera |
---|---|---|---|
Blink | Gecko | WebKit | Blink |
- 用户主机通过互联网向服务器发送请求报文,浏览器发回响应报文
# 统一资源定位符
- 为了方便地访问在世界范围的文档,万维网使用统一资源定位符 URL 来指明因特网上任何种类 “资源” 的位置。
- URL 的一般形式由以下四个部分组成:
< 协 议 > : / / < 主 机 > : < 端 口 > / < 路 径 >
# 万维网文档
- 超文本标记语言 (HyperText Markup Language,HTML) 使用多种 “标签” 来描述网页的结构和内容
- 层叠样式表 (Cascading Style Sheets,CSS) 从审美的角度来描述网页的样式
- JavaScript 一种脚本语言控制网页的行为
# 超文本传输协议
-
HTTP 定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档,以及万维网服务器怎样把万维网文档传送给浏览器。
- HTTP/1.0 采用非持续连接方式。在该方式下,每次浏览器要请求一个文件都要与服务器建立 TCP 连接,当收到响应后就立即关闭连接。
- 每请求一个文档就要有两倍的 RTT 的开销。若一个网页上有很多引用对象(例如图片等),那么请求每一个对象都需要花费 2RTT 的时间。
- 为了减小时延,浏览器通常会建立多个并行的 TCP 连接同时请求多个对象。但是,这会大量占用万维网服务器的资源,特别是万维网服务器往往要同时服务于大量客户的请求,这会使其负担很重。
-
HTTP/1.1 采用持续连接方式。在该方式下,万维网服务器在发送响应后仍然保持这条连接,使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的 HTTP 请求报文和响应报文。这并不局限于传送同一个页面上引用的对象,而是只要这些文档都在同一个服务器上就行。
- 为了进一步提高效率,HTTP/1.1 的持续连接还可以使用流水线方式工作,即浏览器在收到 HTTP 的响应报文之前就能够连续发送多个请求报文。这样的一个接一个的请求报文到达服务器后,服务器就发回一个接一个的响应报文。这样就节省了很多个 RTT 时间,使 TCP 连接中的空闲时间减少,提高了下载文档的效率。
- 为了进一步提高效率,HTTP/1.1 的持续连接还可以使用流水线方式工作,即浏览器在收到 HTTP 的响应报文之前就能够连续发送多个请求报文。这样的一个接一个的请求报文到达服务器后,服务器就发回一个接一个的响应报文。这样就节省了很多个 RTT 时间,使 TCP 连接中的空闲时间减少,提高了下载文档的效率。
-
HTTP 的报文格式
HTTP 是面向文本的,其报文中的每一个字段都是一些 ASCII 码串,并且每个字段的长度都是不确定的。
方法 | 描述 |
---|---|
GET | 请求 URL 标志的文档 |
HEAD | 请求 URL 标志的文档的首部 |
POST | 向服务器发送数据 |
PUT | 在指明的 URL 下存储一个文档 |
DELETE | 删除 URL 标志的文档 |
CONNECT | 用于代理服务器 |
OPTIONS | 请求一些选项信息 |
TRACE | 用来进行环回测试 |
PATCH | 对 PUT 方法的补充,用来对已知资源进行局部更新 |
# 使用 Cookie 在服务器上记录信息
- 早期的万维网应用非常简单,仅仅是用户查看存放在不同服务器上的各种静态的文档。因此 HTTP 被设计为一种无状态的协议。这样可以简化服务器的设计。
- 现在,用户可以通过万维网进行各种复杂的应用,如网上购物、电子商务等。这些应用往往需要万维网服务器能够识别用户。
- Cookie 提供了一种机制使得万维网服务器能够 “记住” 用户,而无需用户主动提供用户标识信息。也就是说,Cookie 是一种对无状态的 HTTP 进行状态化的技术。
# 万维网缓存与代理服务器
- 在万维网中还可以使用缓存机制以提高万维网的效率。
- 万维网缓存又称为 Web 缓存(Web Cache),可位于客户机,也可位于中间系统上,位于中间系统上的 Web 缓存又称为代理服务器(Proxy Server)。
- Web 缓存把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时,若发现这个请求与暂时存放的请求相同,就返回暂存的响应,而不需要按 URL 的地址再次去因特网访问该资源。
若未更改,服务器发送 304 Not Modified
-
某浏览器发出的 HTTP 请求报文如下下列叙述中,错误的是( )。
请求报文 1
2
3
4GET /index.html
Host: www.test.edu.cn
Connection: Close
Cookie: 123456告诉服务器发送完请求的文档后就可释放连接,即非持续连接;若是持续连接方式,取值应为 keep-alive,而不是 Close
-
假设 HTTP1.1 协议以持续的非流水线方式工作,一次请求 - 响应的时间为 RTT,rfc.html 页面引用了 2 个 JPEG 小图像,则浏览器从开始建立 TCP 连接到收到全部内容为止,需要多少个 RTT?
# 常见应用层协议小结
应用程序 | FTP 数据连接 | FTP 控制连接 | TELNET | SMTP | DNS | TFTP | HTTP | POP3 | SNMP |
---|---|---|---|---|---|---|---|---|---|
使用协议 | TCP | TCP | TCP | TCP | UDP | UDP | TCP | TCP | UDP |
熟知端口号 | 20 | 21 | 23 | 25 | 53 | 69 | 80 | 110 | 161 |