应用层

应用层

网络应用是计算机网络存在的理由。在过去的几十年中，许多有影响力的网络应用被创造出来，如 20 世纪 80 年代出现的电子邮件、文件传输、远程访问、新闻组、文本聊天等基于文本的网络应用， 20 世纪 90 年代中期出现的万维网（ Web ）应用以及包括因特网电话、视频会议、视频点播、远程教育等在内的多媒体网络应用，还有 20 世纪末出现的具有联系人列表的即时讯息（如 MSN ， Yahoo Messengers ）和对等（ peer-to-peer ， P2P ）文件共享等新型网络应用。

       当构建一种新的网络应用时，首先需要决定应用的体系结构。应用的体系结构规定了在各种端系统上应如何组织应用程序。现代网络应用有 3 种主流的体系结构：客户 / 服务器体系结构， P2P 体系结构，以及客户 / 服务器和 P2P 混合的体系结构。

l         在客户 / 服务器体系结构中，有一个总是打开的主机称为服务器，它在固定的、众所周知的地址上为其它称为客户机的主机提供服务，客户机之间不直接通信。经典的网络应用，如电子邮件、文件传输、远程访问、万维网等，都采用了这种体系结构。

l         在纯 P2P 体系结构中，没有一个总是打开的服务器，任意一对主机（称为对等方 peer ）之间直接通信。对等文件共享采用了这种体系结构，任何主机都能向其它主机请求文件，也能向其它主机发送文件。每个主机的作用都像一台服务器，向它所在的共享文件社区贡献资源。在今天的因特网中， P2P 文件共享流量在所有流量中占了很大一部分。

l         混合体系结构同时使用客户 / 服务器结构和 P2P 结构，即时讯息采用了这种结构。在即时讯息中，两个聊天的用户之间通常是 P2P ，即这两个用户之间发送的消息不通过总是打开的中间服务器。然而，一个用户在开始他的即时讯息应用前必须在某个中心服务器上注册，当他要与联系人列表中的某个人聊天时，他的即时讯息客户机要与中心服务器联系，以找出可以聊天的在线联系人。

除了确定应用的体系结构外，每一种应用还应规定相应的应用层协议。应用层协议定义了运行在不同端系统上的应用程序如何进行通信，包括它们之间交换的报文类型、各种报文类型的语法、各个字段的语义、以及对各种报文的处理等。区分网络应用和应用层协议是很重要的，应用层协议只是网络应用的一部分。比如， Web 应用是一种客户 / 服务器应用，它允许客户机从 Web 服务器获取所需的文档。 Web 应用有好几个组成部分，包括文档格式标准、 Web 浏览器、 Web 服务器程序以及一个应用层协议 HTTP ， HTTP 定义了在浏览器程序和 Web 服务器程序间传输的报文格式和序列。可见， Web 的应用层协议 HTTP 只是 Web 应用的一个部分。

本章介绍的几个网络应用均为客户 / 服务器模式的应用。

 

1.       域名系统DNS

网络内部使用 IP 地址来引用主机、信箱及其它资源，但这种二进制形式的地址记忆起来很不方便，因此人们引入了便于记忆的 ASCII 名字。在各种网络应用中通常使用这种 ASCII 名字来引用资源，这就需要在资源的 ASCII 名字和它的 IP 地址之间建立起一种映射关系。

在小型系统里面可以使用一个配置文件来保存这种映射关系，但是在一个大规模的网络中，文件将变得非常庞大，一致性将很难维护，更糟糕的是重名很难避免， Internet 解决这一问题的方案是引入域名系统。

域名系统是一种分级结构的基于域的命名方案和实现这种命名方案的分布式数据库，它主要用于将主机名和 email 地址映射到 IP 地址，在其它方面也有用途。

 

(1) 域名空间

       如何使命名系统能够提供大量和可扩展的名字集合，并且不需要一个中心节点来进行管理呢？答案在于分散命名的机制，即将各个名字空间的管理权委托给不同的管理机构，使名字与地址之间的映射的责任分布在各处。

DNS 在概念上将 Internet 分成了 200 多个顶级域，每个顶级域都包括很多主机。每个顶级域又被进一步划分成若干个二级子域，每个二级子域还可以再分子域，依次类推。所有这些域可以组织到一棵树中，如图 7-1 所示。叶子节点代表没有子域的域，它既可以是一台主机，也可以代表一个拥有许多主机的公司。一个指定的域是指树中一个特定的节点以及该节点下所有的节点，这个域的域名是用从该域开始向上直到树根（为空）的标记序列来命名的，标记之间用圆点分隔。树中每个节点必须具有唯一的域名，在保证域名唯一的前提下，相同的标记可以用于不同的节点。需要注意的是，域名的任一后缀也是一个域。

顶级域分为两大类：通用域和国家域。通用域也称组织域，是按组织类型进行分级的。国家域是按国家或称地理划分进行分级的，每个国家对应一个国家域。许多国家仿照组织域的分类方法，在它们的国家域下面建立类似组织域的第二级子域。

 

(2) DNS 工作原理

       为了将一个主机名映射为一个 IP 地址，应用程序调用一个称为解析器的库例程。在 UNIX 系统上，这个库例程是 gethostbyname() 。解析器的输入参数为包含主机名的字符串，如果执行成功，解析器的返回值是对应于该名称的一个 IP 地址。

每一个解析器的内部都配置了本地 DNS 服务器的地址，当解析器被调用时，它将需要查询的信息封装成一个 DNS 请求报文，将报文封装到一个 UDP 包中发送给本地 DNS 服务器。本地 DNS 服务器查找本地数据库，如果在本地数据库中找到需要的信息，就将查询结果封装成一个 DNS 响应报文，然后将报文封装到另一个 UDP 包中，发回给解析器。解析器从 DNS 响应报文中取出查询结果，返回给调用者。 DNS 请求和响应报文所用的 UDP 端口均为 53 。

       如果在本地数据库中没有找到需要的信息，那查找过程就比较复杂了，本地 DNS 服务器必须向其它的 DNS 服务器查询。那么本地 DNS 服务器该向哪个 DNS 服务器发出请求呢？为解释这个问题，首先需要了解因特网中 DNS 服务器的组织方式。因特网中使用了大量的 DNS 服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台 DNS 服务器知道因特网上所有主机的映射信息，这些信息被分布在所有的 DNS 服务器上。因特网中有三种类型的 DNS 服务器，按照层次结构从上到下依次为根 DNS 服务器、顶级域服务器和权威 DNS 服务器。

l         根 DNS 服务器：根 DNS 服务器知道所有顶级域服务器的 IP 地址。因特网上有 13 个根 DNS 服务器（标号为 A 到 M ），其中大部分位于北美。

l         顶级域（ TLD ）服务器：每个顶级域至少有一个顶级域服务器，每个 TLD 服务器知道本域下所有二级子域的权威 DNS 服务器的 IP 地址。

l         权威 DNS 服务器：在因特网上具有公共可访问主机（如 Web 服务器和邮件服务器）的每个组织机构必须提供公共可访问的 DNS 记录，这些记录保存在组织机构的权威 DNS 服务器中。每个组织机构可以选择实现自己的权威服务器，也可以支付费用将这些 DNS 记录存储在某个服务提供商的权威服务器中。多数大学和大公司实现和维护它们自己的主权威服务器和辅助权威服务器。

假如某台主机 A 想知道主机 email.ustc.edu.cn 的 IP 地址，主机 A 向自己的本地 DNS 服务器发送一个 DNS 请求报文。如果 A 的本地 DNS 服务器不知道如何解析这个名字，它将报文转发给一个根服务器，每个本地 DNS 服务器必须配置至少一个根服务器的 IP 地址。这个根服务器注意到 cn 这个后缀，就向本地 DNS 服务器返回负责 cn 这个域的 TLD 服务器的 IP 地址列表。本地 DNS 服务器向这些 TLD 服务器之一发送一个 DNS 请求报文，收到请求的 TLD 服务器注意到 edu.cn 这个后缀，就用负责 edu 这个二级子域的权威服务器的 IP 地址进行响应。本地 DNS 服务器再向这个权威服务器发送 DNS 请求报文，这个权威服务器用负责 ustc.edu.cn 的权威服务器的 IP 地址进行响应。本地 DNS 服务器再向 ustc.edu.cn 的权威服务器发送请求，这个权威服务器用 email.ustc.edu.cn 的 IP 地址进行响应。至此，本地 DNS 服务器得到了主机名 email.ustc.edu.cn 的 IP 地址。

注意到在上面的例子中，为了获得一个主机名映射，共发送了 5 份 DNS 请求报文和 5 份 DNS 响应报文。实际上，为了减小时延和减少因特网上传输的 DNS 报文数量， DNS 广泛使用了缓存技术。 DNS 缓存的想法很简单，每当本地 DNS 服务器从某个 DNS 服务器收到一个 DNS 响应报文，它就缓存这个响应报文中的信息。这样，如果本地 DNS 服务器中缓存了一个 < 主机名， IP 地址 > 对，当另一个对相同主机名的查询到达该服务器时，它可以直接返回响应。由于主机名与 IP 地址之间的映射不是永久的，所以 DNS 服务器在一段时间后（通常设置为两天）将丢弃缓存的信息。本地 DNS 服务器也可以缓存 TLD 服务器的 IP 地址，从而允许本地 DNS 服务器绕过查询链中的根服务器，这种情况是经常发生的。

另一个需要说明的是，在具体实现时物理域名服务器的层次结构与域名的层次结构不完全一致。比如，一个公司可以将它的所有域名都放在一个服务器中，尽管这个公司实际上拥有多层的域结构；也可以将域名分放在几个服务器中，其中每个服务器可以负责一个层次或者多个层次的域。因此，虽然域的层次可能很多，但服务器的层次并不多，从而查询链不会太长。

 

(3) 资源记录

       每个域都有一组与之相关联的资源记录。对于一个主机来说，最常见的资源记录就是它的 IP 地址，但还有其它种类的资源记录。当一个解析器向 DNS 查询一个域名时，它得到的其实是和这个域名相关联的资源记录。因此可以说， DNS 的主要功能是将域名映射到资源记录上。

       一条资源记录就是一个五元组，它包括域名、生存期、信息类型（ class ）、资源记录类型（ type ）、值（ value ）五项。

n         域名表示该记录适用的域。通常一个数据库中包含许多域的信息，一个域又有许多资源记录，因此域名是用于查询的主关键字， DNS 会返回所有与域名相匹配的资源记录，而资源记录在数据库中的顺序并不重要。

n         生存期：表示资源记录的稳定性如何。可以给一个稳定的资源记录指定一个较大的值，如 86400 秒（一天），给一个易变的资源记录指定一个较小的值，如 60 秒。

n         信息类型：对于 Internet 信息，该项总为 IN ，其它类型信息很少见。

n         资源记录类型：最重要的类型列于图 7-2 中，包括授权开始 SOA （指明一个服务器实现的命名等级部分的多个字段）、主机 IP 地址（可有多个）、域邮件服务器（可有多个并列有优先级）、名字服务器（域的授权服务器名，父域服务器名）、域的别名、反向查找指针（从 IP 地址映射到域名）、主机信息（ CPU 及操作系统）及域的描述信息。

n         值：可以是一个数字、域名或 ASCII 串，其语义由记录类型决定。

一个可能的 DNS 数据库的部分信息如图 7-3 所示。

2.       文件传输

文件传输是因特网上最早出现且目前仍在频繁使用的网络应用之一，它将一个完整的文件从一个系统拷贝到另一个系统。在早期的因特网中，用于传输文件的数据报占了网络流量的近三分之一。直到 1995 年，万维网的信息流量才第一次超过了文件传输。

 

(1)    文件传输协议 FTP

因特网中最流行的文件传输服务使用 FTP （ File Transfer Protocol ）协议，它能在任意两台计算机之间传输文件的拷贝。虽然 FTP 协议明确规定了两台计算机上的 FTP 软件如何进行交互，但该标准并没有定义用户接口，因此不同的 FTP 实现所提供的用户接口可能不同。为维护产品之间的相似性，许多厂商采纳了最早在 BSD UNIX 系统中使用的 FTP 软件版本。 BSD FTP 接口含有 50 多条命令，令许多初学者感到无从下手。所幸的是，大多数用户仅需要几条命令就可以进行文件传输。另外，一些新开发的 FTP 应用程序为用户隐藏了 FTP 接口的许多细节，用户只要输入文件服务器的名字、本人帐号及口令等信息，拖动鼠标就可以方便地完成文件的上传和下传。

像其它网络应用一样， FTP 使用客户 / 服务器模式。用户运行一个本地 FTP 客户程序， FTP 客户程序负责解释用户输入的命令，与远程文件服务器建立 TCP 连接，并在 TCP 连接上完成与服务器的通信及数据传输等。 FTP 使用两条 TCP 连接完成文件传输，一条是控制连接，另一条是数据连接。平时 FTP 服务器总在端口 21 上等待客户的连接请求，当用户需要传输文件时， FTP 客户与 FTP 服务器的端口 21 建立一个控制连接，用来传送客户的命令和服务器的响应。当客户在控制连接上发出数据传输命令时，服务器在另一个端口上主动与客户建立一条数据连接，然后在数据连接上传输文件。当一个文件传输结束时，关闭数据连接。如果用户请求另一个文件的传输，则服务器和客户再建立一个数据连接，用于传输新的文件。虽然数据连接频繁地建立和释放，但控制连接在整个会话期间一直保持，直到客户与服务器通信结束为止。

上图是 FTP 的功能模块及两条连接的示意图。从图中可以看到，终端用户并不直接处理控制连接上的 FTP 命令和 FTP 响应， FTP 命令和响应的处理由两个协议解释器完成。用户接口为终端用户提供某种形式的输入界面，接收用户的命令，将其转换成标准的 FTP 命令，并将控制连接上的 FTP 响应转换成用户可阅读的形式显示出来。

使用分开的控制连接和数据连接有几个优点：（ 1 ）简化了协议的设计和实现，因为文件数据不会干扰 FTP 命令；（ 2 ）由于控制连接一直保持，它在文件传输过程中仍然可用，比如客户可以随时发出终止传输的命令；（ 3 ）数据连接的关闭可用于通知对方文件传输结束，允许动态创建文件（不需要告知对方传输文件的大小）。由于发送方用关闭连接来表示一个文件传输结束，所以数据连接总是由发送文件的一方主动关闭。

       需要注意的是，在建立数据连接时客户和服务器的角色是相反的，服务器扮演客户的角色，而客户扮演服务器的角色。建立一个数据连接的过程如下：

l         客户进程为数据连接选择一个本地的临时端口号，并在该临时端口上等待服务器的连接请求；

l         客户进程在控制连接上用 PORT 命令将临时端口号发送给服务器；

l         服务器收到端口号后，发送一个连接请求，同客户机的该端口建立一个数据连接，服务器用于数据连接的端口号总是 20 。

 

(2)    简单文件传输协议 TFTP

因特网还包含另一种文件传输服务，称为简单文件传输，其协议为 TFTP （ Trivial File Transfer Protocol ）。 TFTP 最初打算用于引导无盘系统（通常是工作站或 X 终端），因而 TFTP 使用 UDP 而不是 TCP 进行文件传输，以保持算法简单和短小。 TFTP 代码和它所需要的 UDP 、 IP 和设备驱动程序都能适合只读存储器（ ROM ），这一点对于引导无盘系统非常重要。

引导无盘系统通常需要一个网络连接和一小块 ROM ， ROM 中有支持 TFTP 、 UDP 和 IP 的代码。当这种设备启动后，它执行 ROM 中的代码，然后在网络上产生一个 TFTP 的广播请求。网络上配置的 TFTP 服务器通过发送文件来响应这一请求，这一文件包含可运行的二进制程序。设备接收到这一文件后，将它装载到内存中，然后开始执行该程序。

       在开始工作时， TFTP 客户与服务器交换信息，客户发送一个读请求或写请求给服务器；如果文件是允许读或写的，则客户与服务器之间采用停 - 等协议进行数据传输。以读一个文件为例， TFTP 客户向服务器发送一个读请求，说明要读的文件名和文件模式（ ASCII 文件还是二进制文件）。如果这个文件允许被该客户读取， TFTP 服务器发送一个块编号为 1 的数据分组， TFTP 客户收到后发送一个块编号为 1 的确认分组。 TFTP 服务器随后发送块编号为 2 的数据分组， TFTP 客户返回块编号为 2 的确认分组。重复这个过程，直至这个文件传送完。除最后一个数据分组可含有不足 512 字节的数据外，其它每个数据分组均含有 512 字节的数据。当 TFTP 客户收到一个不足 512 字节的数据分组时，就知道它收到了最后一个数据分组。

在写文件的情况下， TFTP 客户发送写请求，指明文件名和模式。如果这个文件能被该客户写， TFTP 服务器返回块编号为 0 的确认分组。该客户将文件的头 512 字节以块编号为 1 发送，服务器收到后返回块编号为 1 的确认。依次类推。

由于 TFTP 使用不可靠的 UDP 传输数据，分组可能出错或丢失。 TFTP 使用超时重传机制解决分组丢失问题。至于检测错误，和许多 UDP 应用程序一样， TFTP 报文中没有校验和，它假设 UDP 会检测数据错误并丢弃出错的包。

       TFTP 服务器使用 UDP 端口 69 。 TFTP 要求客户进程首先向服务器进程的 UDP 熟知端口（ 69 ）发送第一个报文（读请求或写请求），之后服务器进程向服务器主机申请一个尚未使用的端口，重新创建一个进程在该端口上与请求的客户进程交换数据，随后服务器进程回到 69 端口继续监听其它客户的请求。服务器中的 UDP 模块根据目的端口号区分不同的客户。

TFTP 报文不提供用户名和口令，这是因为 TFTP 被设计用于系统引导进程，它不可能提供用户名和口令。 TFTP 的这一特性（安全漏洞）被许多解密高手用于获取 UNIX 口令文件的拷贝，然后猜测用户口令。为防止这种类型的访问，目前大多数 TFTP 服务器提供了一个选项，限制只能访问特定目录下的文件（ UNIX 系统中通常是 /tftpboot ），这个目录中只包含无盘系统引导所需的文件。

 

 

3.       电子邮件

因特网电子邮件系统由三个主要部分组成：用户代理、消息传输代理和简单邮件传输协议（ Simple Mail Transfer Protocol ， SMTP ）。用户代理是一个本地程序，有时也称邮件阅读器，它为用户提供阅读邮件、编辑邮件、发送邮件及信箱管理等功能。消息传输代理是运行在邮件服务器后台的一个系统守候进程（ daemon ），负责为用户传递邮件及将收到的邮件放入用户的邮箱。在两个计算机之间传递邮件使用 SMTP 协议。

 

(1) 简单邮件传输协议（ SMTP ）

       在因特网中，为将邮件从一台主机（源）发送到另一台主机（目的），源主机首先和目的主机建立一个 TCP 连接，端口 25 固定用于邮件传输，然后双方运行 SMTP 协议传递信件。在端口 25 监听的服务进程称为 email 守候进程，它接收源主机的连接请求，将收到的邮件放入相应的信箱；如果邮件无法投递，它将返回一个错误报告。

SMTP 的工作过程很简单。客户机建立了与服务器的 TCP 连接后，等待服务器发送一个准备好消息，如果服务器未准备好，客户机释放连接。当收到服务器的准备好报文后，客户机向服务器通报信件的发送方和接收方；如果接收方信箱在服务器上，服务器就会通知客户机继续；于是客户机将信件发给服务器，服务器回应。如果还有信件需要发送，重复以上过程，直到信件发完。然后，服务器交换发送方和接收方的身份，以使邮件能反向流动。当两个方向上的信件均交换完后，释放连接。过程如图 7-14 所示。

 

(2) 两阶段交付

       SMTP 方案暗示着服务器必须在任何时候做好接受电子邮件的准备。一旦用户输入邮件，客户就试图将其发送出去。如果服务器运行在具有永久互联网连接的计算机上，是能够做到这一点的，但对于并非一直连接到互联网的计算机（如拨号上网的计算机），就无法做到这一点了。

       解决这个问题的方法是使用一个两阶段的交付过程。第一阶段，在具有永久 Internet 连接的计算机上为每个用户分配一个邮箱，这台计算机运行一个常规 SMTP 服务器，一直准备着接收电子邮件。第二阶段，用户与邮件服务器建立一个连接，运行一个从永久邮箱检索邮件的协议，这个协议把邮件传输到用户使用的计算机，在这台计算机上、阅读邮件。

       有两个协议可允许远程用户从永久邮箱检索邮件，一个是邮局协议 POP ，另一个是 Internet 邮件访问协议 IMAP 。

 

(3) 邮局协议 POP3

       把邮件从永久邮箱传输到本地计算机的最流行的协议是邮局协议版本 3 ，即 POP3 。用户激活一个 POP3 客户，该客户与带有永久邮箱的计算机的端口 110 建立一个 TCP 连接；连接建立后，用户发送用户名和口令以鉴别该会话；一旦接受了鉴别，用户就可以发送命令，收集邮件同时将邮件标记为删除；当客户发出退出命令时，服务器删除所有标记的邮件，回应客户，并释放连接。过程如图 7-16 所示。

       尽管 POP3 协议支持将邮件下载到客户机，同时在服务器上也保留备份，但是大多数邮件软件都是简单地下载邮件，然后将邮箱清空。

       带有永久邮箱的计算机必须运行两个服务器， SMTP 服务器接受发送给一个用户的邮件，并把传入的每个邮件添加到该用户的永久邮箱中， POP3 服务器允许用户从邮箱中提取邮件并将其删除。为了确保操作正确，这两个服务器必须协调对邮箱的使用，如果邮件通过 SMTP 到达的同时用户通过 POP3 提取邮件，邮箱必须能够保持有效状态。

 

(4) Internet 邮件访问协议 IMAP

       由于 POP3 总是一次性把邮箱中的所有内容都传到本地机器上，这对于那些经常使用多台计算机却只有一个邮箱帐号的用户来说很不方便，因为他们的邮件会散布到多台机器上，而这些机器可能并不是他们自己的。

与 POP3 不同， IMAP 允许用户将所有邮件无限期地保留在服务器中，在线地阅读邮件，并允许用户动态地在服务器上创建、删除和管理多个信箱，将阅读过的信件放到相应的信箱中保存。另一个和 POP3 不同的地方是， IMAP 除了为用户接收邮件以外，还可以为用户发送邮件。 IMAP 服务器在端口 143 上监听。

 

(5) 多用途因特网邮件扩展协议 MIME

       邮件格式最早在 RFC 822 中规定。 RFC 822 规定了信头中可以使用的域，包括收信人、发信人、信件经过的路径等与消息传输有关的域，还有回信地址、信件编号、关键字、信件主题等供用户代理及收信人使用的域。在电子邮件发展的初期，所有信件都是用英文写的，编码方式都是 ASCII 码，且信件的格式也都是纯文本格式，因此 RFC 822 的信体不需要什么结构。发信程序和收信程序可以直接对信体进行发送和接收，而不需要进行任何代码转换。

随着网络规模的扩大和通信业务类型的增多，越来越多的用户要求电子邮件不仅能传输英文，也能传输其它语系的文字，甚至能传输多媒体信息。当信体是非 ASCII 文本形式的数据时，为了保证这些数据在现有系统中得以可靠传输，发送前通常必须将它们转换成某种适合传输的代码形式，接收时再进行相应的解码。另外，非 ASCII 文本形式的信体大多是具有一定数据结构的信息块，必须调用相应的信件浏览器才能进行显示，因此在用户端需要运行特殊的发信程序和收信程序。因此，人们对 RFC 822 进行了扩展，提出了多用途因特网邮件扩展协议（ Multipurpose Internet Mail Extensions ， MIME ）。 MIME 对 RFC 822 所作的扩充是，允许信体具有一定的数据结构，规定了非 ASCII 文本信息在传输时的统一编码形式，并在信头中扩充了一些域，用以指明信体的数据类型和传输编码形式，从而引导收信程序正确地接收和显示信件。

       MIME 在信头中扩充的最重要的两个域是：信体传输编码形式和信体数据类型。 MIME 定义了五种传输编码形式：基本的 ASCII 编码集，扩展的 ASCII 编码集，二进制编码，基 64 编码（ base64 encoding ）， quoted-printable 编码。在基 64 编码中，每 24 比特数据被分成 4 个 6 比特的单元，每个单元编码成一个合法的 ASCII 字符，其对应关系为： 0 ～ 25 编码成‘ A ’～‘ Z ’， 26 ～ 51 编码成‘ a ’～‘ z ’， 52 ～ 61 编码成‘ 0 ’ ～‘ 9 ’ ， 62 和 63 分别编码成‘＋’和‘／’，‘＝＝’和‘＝’分别表示最后一组只有 8 比特和 16 比特，回车和换行忽略。使用这种编码方式可以正确传输二进制文件。 Quoted-printable 编码适用于消息中绝大部分都是 ASCII 字符的场合。每个 ASCII 字符仍用 7 比特表示，大于 127 的字符编码成一个等号再跟上该字符的十六进制值。

       RFC 1521 定义了七种数据类型，有些类型还定义了子类型。比如，文本（ text ）类型分为无格式文本（ text/plain ）和带有简单格式的文本（ text/richtext ），图像类型分为静态 GIF 图像（ image/gif ）和 JPEG 图像（ image/jpeg ），还有音频类型、视频类型、消息类型（信体中包含另一个报文）、多成分类型（信体中包含多种数据类型）和应用类型（需要外部处理且不属于其它任何一种类型）。

 

4.       万维网

从用户的角度来看， Web 是由数量巨大且遍布全球的文档组成的，这些文档称为 Web 页（或简称页）。每个页除了含有基本的信息之外，还可以含有指向其它页的链接，这样的页就称为超文本（ hypertext ）页或超媒体（ hypermedia ）页。超文本和超媒体的不同在于文档内容，超文本文档只包含文本信息，而超媒体文档还包含其它媒体信息，如图标、图形、数字照片、音频、视频等。

页需要用称为浏览器的程序阅读，浏览器负责取回指定的页，并按照指定的格式显示在屏幕上。图 7-18 是一个 Web 页的例子，页中指向其它页的文本串称为超级链接（ hyperlink ），通常用下划线、加亮、闪烁、突出的颜色等进行强调。其实除了文本串以外，页中的其它元素，如图标、照片、地图等，都可以有指向其它页的超级链接。当用户点击超级链接时，浏览器就会取回该链接指向的页，并显示给用户。 Web 的基本工作模型如图 7-19 所示。

 

(1) 客户方

当用户点击了一个超级链接后，浏览器如何找到所需的页呢？每个 Web 页使用统一资源定位器（ URL ）进行命名，如 [url]http://www.itu.org/home/index.html[/url] 。 URL 由三部分组成：用于访问页的协议名称（如 http ）、页所在机器的域名（如 [url]www.itu.org[/url] ）和包含页的文件（如 /home/index.html ）。当用户点击了以上的超级链接后，浏览器按以下步骤工作：

n         浏览器确定 URL （从页及点击位置获取）；

n         请求 DNS 解析域名 [url]www.itu.org[/url] ；

n         DNS 返回 IP 地址 156.106.192.32 ；

n         浏览器与 156.106.192.32 的端口 80 建立一个 TCP 连接；

n         浏览器发送一个请求，要求取文件 /home/index.html ；

n         [url]www.itu.org[/url] 服务器发送文件 /home/index.html ；

n         释放 TCP 连接；

n         浏览器显示文件 /home/index.html 的所有文本内容；

n         浏览器取回该文件中的所有图像并显示（一次取一个图像显示）。

为了使得浏览器能够正确解释和显示每一个 Web 页， Web 页必须使用称为 HTML （超文本标记语言）的标准语言书写。但并不是每一个页都是 HTML 格式的，如一个页可以包含 PDF 格式的文档、 GIF 格式的图标、 JPEG 格式的照片、 MP3 格式的歌曲、 MPEG 格式的视频等，浏览器如何来显示这些页呢？当服务器返回一个页的时候，同时要返回关于这个页的一些额外信息，特别是页的 MIME 类型。当页的 MIME 类型不是浏览器本身所支持的类型时，浏览器查找自己的 MIME 类型表，该表将每个 MIME 类型关联到一个阅读器上，浏览器调用相应的阅读器进行显示。这些阅读器可以是和浏览器运行在同一个程序空间的插件程序，也可以是一个独立的助手程序。浏览器也可以显示本地文件，但本地文件没有 MIME 类型，浏览器是通过文件的扩展名来得知文件类型的。

 

(2) 服务器方

       Web 服务器的典型工作过程如下：

n         服务器在端口 80 监听，与请求的客户建立 TCP 连接，接收服务请求；

n         确定请求的 Web 页（名字扩展）；

n         （若需要）认证客户；

n         （若需要）对客户进行访问控制；

n         （若需要）对请求的页进行访问控制；

n         检查请求的页是否在高速缓存中；

n         若不在高速缓存中，从本地磁盘读取文件；

n         确定要包含在响应中的 MIME 类型；

n         其它处理；

n         将文件返回给客户，并进行日志记录；

n         释放连接。

服务器的设计主要着眼于如何提高服务的响应速度，以及如何服务于更多的客户。常用的技术包括将经常访问的文件保存在高速缓存中，服务器设计为多线程的且使用多个磁盘，建立 server farm 等。

 

(3) 状态信息和 cookie

       Web 本质上是无状态的，浏览器向服务器发送一个文件请求，服务器将请求的文件返回，此后服务器上不保留有关客户的任何信息。当 Web 只用于获取公开可访问的文档时，这种工作模式是非常合适的。但随着 Web 涉足其它领域，有些服务需要在确认了用户的身份后才能提供，这就需要将用户信息保存起来。如有些软件需要用户注册后才能使用，当用户注册后，用户信息必须被保存下来，当用户下次请求服务时，这些信息就被用来判断用户是否是注册用户，从而决定如何向用户提供服务。

在两次调用之间程序保存的信息称为状态信息，保存状态信息的方法依赖于这些信息需要被保存的时间和信息的大小。服务器可以将少量信息传递给浏览器，浏览器将这些状态信息存储在磁盘上，然后在后续请求中将这些信息返回给服务器。如果服务器需要存储大量的信息，服务器必须将这些信息保存在本地磁盘上。

传递给浏览器的状态信息称为 cookie ，它被保存在浏览器的 cookie 目录下。 cookie 是一个小文件，最多包括 5 个字段（如图 7-25 ），包括产生 cookie 的 Web 站点名称、适用的路径（在服务器的哪部分文件树上要使用这个 cookie ），内容、有效期和安全性要求。当浏览器要向某个 Web 服务器发送请求时，先检查 cookie 目录，看看是否有从那个服务器发来的 cookie ，如果有就把发来的所有 cookie 都包含在请求消息中，发送给服务器。由于 cookie 很小，大多数服务器软件不会在 cookie 中存储实际数据，两次调用之间需要保存的信息实际上是存放在服务器本地磁盘的文件中，而 cookie 被用作这些信息的索引。

 

(4) Web 文档类型

       Web 文档按照文档内容产生的时间可以划分为三个较宽的范畴：

n         静态文档：静态文档以文件方式保存在 Web 服务器上，由文档的作者决定文档的内容。由于文档的内容不会改变，所以对静态文档的请求会产生相同的响应。

n         动态文档：动态文档不是预先存在的，它是在浏览器请求文档时由 Web 服务器创建的。当请求到达时， Web 服务器运行一个应用程序创建动态文档，服务器将应用程序的输出作为响应。因为针对每个请求均会创建一个新的文档，所以每个请求产生的动态文档是不同的。

n         主动（ active ）文档：主动文档不是完全由服务器指定，主动文档由一个计算机程序组成，该程序知道如何进行计算并显示结果。当游览器请求一个主动文档时，服务器返回一个必须在浏览器本地运行的程序的拷贝。当程序运行时，主动文档程序可以与用户进行交互，并不断地改变显示。因此，主动文档的内容不是固定不变的。

静态文档的优点是简单、可靠和高性能，缺点是缺少灵活性。当信息改变时文档必须被修改，而且需要手工修改，因此静态文档适用于那些不需要经常修改的信息。动态文档的优点是能够报告当前信息，例如，动态文档可用于报告当前股票价格、天气状况等。当浏览器请求这些信息时，服务器会运行一个应用程序来访问所需的信息并创建文档，然后将文档发送给浏览器。但动态文档一旦被发送到浏览器后，其信息也不会再改变了，因此当用户浏览股票价格时，这些信息可能已经过时了。所以，动态文档不适用于那些变化非常快的信息。主动文档与动态文档相比，主要优点在于可以持续不断地更新信息。主动文档可以直接访问信息源并能不断更新显示，因此用于显示股票价格的主动文档可以不断返回股票信息并改变显示，无需用户的任何操作。主动文档的主要缺点来自于创建和运行这种文档所带来的额外开销以及不安全因素的引入。

总而言之，静态文档中的信息只有在作者修改文档时才会改变，动态文档的信息在服务器接到对该文档的请求时被改变，而主动文档显示的信息在文档被载入浏览器中之后仍可以改变。

 

(5) HTML 、 XML 和 XHTML

       静态文档使用 HTML 语言书写。 HTML 是一种标记语言，用于描述文档的显示格式。 HTML 并不指定详细的文档格式，它允许文档含有显示所需的大纲性的信息，而让浏览器来决定具体的显示细节。因此，同一个 HTML 文档在两个浏览器上的显示可能是不同的。

       HTML 中的格式命令称为标签（ tag ），使用时标签成对出现，包含在一对标签中的文档内容，其显示格式就由该标签指定，常见的标签列于表 7-27 中。

当需要在 Web 页中嵌入图像时，图像数据文件必须存储在一个独立的地方，然后在文档中包含指向该文件的指针。当浏览器遇到这样一个指针时，会到指针所指的地方获得图像的拷贝，然后将图像插入到被显示的文档中。 HTML 使用 <IMG> 标签来指出获取图像文件的地方及图像在文档中的显示位置等信息，如： <IMG SRC="[url]http://www.widget.com/images[/url] /logo.gif" ALIGN=middle ALT="AWI Logo"> ，其中 SRC 给出图像数据文件的 URL ， ALIGN 表示显示位置， ALT 是当图像不能显示时代替图像的文字。

当需要在文档中包含超级链接时，使用标签 <A> ，如： <A HREF="http://www.nasa.gov"> NASA's home page </A> ，显示时包含在标签之间的文字会被加上下划线（ NASA's home page ），而点击它则会显示 NASA 的主页。也可以为图像设置超级链接，如： <A HREF="http://www.nasa.gov"> <IMG SRC="shuttle.gif" ALT="NASA"> </A> ，当点击飞船（ shuttle ）图像（或替代的 NASA 字符串）时会显示 NASA 的主页。

       在许多应用中用户不仅需要下载信息，也需要向服务器输入信息，如进行注册、网上购物、回答问卷调查、输入查询关键字等，这就需要信息逆向流动。 HTML 使用表单来收集用户的输入信息，表单中包含一些需要用户提供信息的条目，每个条目都有一个唯一的名字，当用户点击提交按钮时，浏览器将所有条目及条目的值汇总，发送给服务器。

       HTML 的缺点是将文档的内容与格式绑在了一起，这使得要从文档中提取信息或者改变信息的输出格式变得非常困难。为此提出了两种新的语言，扩展的标记语言 XML 和扩展的样式语言 XSL 。 XML 以一种结构化的方式描述内容，而 XSL 则描述独立于内容的显示格式，这使得数据的收集、处理与输出更加灵活方便。

       HTML 和 XML 都是针对运行在 PC 机上的浏览器设计的，随着无线手持设备（如 PDA ）的普及，人们可能会想用这些设备来浏览网页，但这些设备的内存和处理器速度都很有限，无法运行现在这些复杂的浏览器。可扩展的超文本标记语言 XHTML 是一种更规范的语言，可简化浏览器的处理。

 

(6) CGI 和服务器端脚本技术

       当服务器收到浏览器发过来的表单数据时，它需要将数据交给一个程序去处理，该程序可能会去查询数据库，然后生成一个定制的 HTML 文档返回给浏览器，比如让用户进行确认。 HTML 表单的处理过程如图 7-33 所示。

       处理表单和其它交互式 Web 页（动态文档）的传统方法是公共网关接口 CGI 。 CGI 是一个标准的接口，它允许 Web 服务器与一个能够处理动态文档的后台程序或脚本进行交互。 CGI 规定了服务器与后台程序交互的通用规则，但允许程序员选择大多数细节。例如， CGI 允许程序员选择编程语言，并且允许不同的动态文档使用不的语言。因此，对于需要大量数学计算的文档，程序员可以使用传统的 FORTRAN 、 C 或 C++ 语言，而对于需要处理文本格式的文档，可以使用 Perl 、 TCL 或 UNIX Shell 脚本语言。在实际应用中， CGI 程序的输出并不局限于 HTML ， CGI 标准允许 CGI 应用产生任意文档类型，如文本或数字图片。为区分各种不同的文档类型， CGI 标准允许 CGI 程序在输出中放置一个头部，头部中含有描述文档类型的文本。

       每个 CGI 程序被赋予一个 URL ，位于 cgi-bin 目录下。表单的 ACTION 参数中指出了处理表单数据的 CGI 程序的 URL ，当表单数据被提交后， Web 服务器调用相应的 CGI 程序进行处理，并接收 CGI 程序的输出。 CGI 程序输出后，服务器要检查输出的头部，因此 CGI 程序可以通过头部与服务器进行通信，比如指出生成的文档类型，也可以指出文档放在另一个不同的 URL 处。服务器取得 CGI 生成的文档，返回给浏览器。

       CGI 技术的主要缺点在于它的模式，每次请求 CGI 程序，均会产生一个完整的 HTML 页，即使每次产生的 HTML 文件内容只有几行不同。在实际应用的一些例子中，大部分网页的内容均是相同的，如一个含有股票交易信息的网页，只有动态插入的公司名称和当前的股票价格是不同的，其余部分如网页头和页面的格式信息都是相同的。

       针对只需要改变网页中一小部分内容的情况，已经有了不同于 CGI 技术的其它动态网页技术。这些技术不需要运行产生网页的单独程序，它们与服务器软件紧密集成在一起，修改网页的工作由在服务器中内置的解释器完成。在服务器中存储的网页称为模板，它包含传统的 HTML 和脚本信息，对于 HTML 信息解释器不做任何改变，对于脚本信息解释器用解释脚本的结果代替。为使解释器能够高速运行，模板的脚本信息使用特殊的语法。存在以下几种服务器端脚本技术：

n         ASP （ Active Server Pages ）：微软公司创建的一种动态网页技术，脚本信息用 VB 编写，脚本解释器与微软公司的 Internet 信息服务器（ Internet Informaton Server ， IIS ）紧密集成。

n         JSP （ Java Server Pages ）：一种独立于平台的动态网页技术，网页中嵌入的脚本代码是用 Java 语言编写的。

n         PHP （ Perl Helper Pages ）：一种使用 Perl 语言的动态网页技术，速度比 ASP 和 JSP 快，但嵌入的代码难以阅读。

n         ColdFusion ：一种在网页中嵌入 SQL 数据库查询的动态网页技术，当服务器处理这种页时，解释器向数据库系统发送 SQL 查询，并将结果转换为 HTML ，置于查询语句的位置。

 

(7) Java 、 JavaScript 和 ActiveX controls

       主动文档是一个程序，它从服务器下载并在浏览器中运行，它能与用户动态交互，并能主动地从服务器获取最新信息，因而可以为用户提供不断更新的信息。

       Java 是由 Sun 微系统公司开发用于创建并运行主动文档的一种技术，它使用术语 Applet 描述主动文档程序。运行 Java 的游览器含有两个解释器，一个 HTML 解释器和一个用于解释 Applet 的 Java 解释器。在浏览器下载并运行 Applet 之前， Java Applet 必须被编译成字节码并存储在 Web 服务器上。调用 Applet 的方法有两种，一种是用户向支持 Java 的浏览器提供一个 Applet 的 URL ，当浏览器与 URL 中指定的服务器联系时，服务器通知浏览器该文档是一个 Applet 。另一种方法是在 HTML 文档中包含一个指向 Applet 的标记 <applet> ，当浏览器遇到这一标记时，与服务器联系获得该 Applet 的一个拷贝，下载到本地执行。 Applet 可以与浏览器中的 HTTP 客户和 HTML 解释器进行交互， Applet 使用浏览器的 HTTP 客户检索文档，使用浏览器的 HTML 解释器显示网页信息。

       JavaScript 是一种脚本语言，提供有与用户交互的 JavaScript 函数，脚本直接嵌入 HTML 页中，由浏览器解释执行。 JavaScript 的优点是简单并易于使用，不需要独立的编译器，缺点是代码空间比较大，解释执行的速度较慢。

       微软公司的解决方案是 ActiveX controls ，这些是编译成机器语言的程序，并在硬件上执行，因此它比 Java Applet 运行更快且更灵活。当 Internet Explorer 在 Web 页中遇到一个 ActiveX control 时，它从服务器上下载，检验其标识，然后执行。

 

(8) 超文本传输协议 HTTP

       浏览器与 Web 服务器之间通信所用的协议是超文本传输协议 HTTP ，它规定了客户方与服务器方通信所使用的命令及响应。 HTTP 通常运行在 TCP 连接之上，当浏览器和服务器的端口 80 建立了 TCP 连接之后，就向服务器发送 HTTP 请求，服务器返回响应。 HTTP 请求是自包含的，服务器不保留以前的请求或会话的历史记录。

       HTTP 的早期版本（ 1.0 ）为每个数据传输使用新的 TCP 连接，即客户建立 TCP 连接，发送一个 HTTP 请求，服务器返回一个响应，然后关闭连接。早期的 Web 页大多只包含纯文本信息，这种方法是比较合适的，但后来的 Web 页包含了越来越多的图标、图像等，建立一个 TCP 连接只为传输一个图标，这样的开销就太大了。因此，当版本 1.1 出现时，它以一种根本的方式改变了基本 HTTP 模式。它不是为每个传输使用 TCP 连接，而是把持久连接用作默认方式，即一旦客户建立了和特定服务器的 TCP 连接，客户就让该连接在多个请求和响应过程中一直存在，当客户或服务器准备关闭连接时就通知另一端，然后关闭连接。还可以用流水线技术进一步优化使用持久连接的浏览器，可令浏览器逐个连续地发送请求而不必等待响应。在必须为某个页面取得多幅图像的情况下，流水线技术特别有用，它使得底层互联网具有较高的吞吐量，并且应用具有较快的响应速度。使用持久连接的缺点是要标识通过连接发送的每一数据项的开头和结尾， HTTP 通常使用的方法是先发送数据项的长度，然后再发送数据项。

除了能从 Web 服务器上下载文件以外， HTTP 还可以有其它操作，内置的 HTTP 操作列于表 7-41 中。

HTTP 使用消息进行交互。它借用了电子邮件的基本格式，每个 HTTP 消息包含一个头部、一个空行和要发送的数据项。头部中的每一行包含关键字、冒号和信息，常见的 HTTP 头列于表 7-43 中。 HTTP 允许浏览器和服务器通过消息头部交换元信息，如数据项使用的编码方法及语言、数据项长度、网页类型、最后修改时间、 cookie 等。

除了描述数据项的详细信息以外， HTTP 还允许浏览器和服务器通过头部协商各种能力，如可接受的网页类型、字符集、编码方法、语言等。有两种类型的协商：服务器驱动和代理驱动（即浏览器驱动）。服务器驱动是从浏览器发出请求开始的，请求指定首选列表以及要求的数据项的 URL ；服务器从可用的表示法中选出符合浏览器首选要求的一项，如果有多项符合条件，则服务器进行“最好的猜测”。在代理驱动协商方法中，浏览器首先向服务器发送请求，询问可用的内容，服务器返回可能的内容列表；浏览器选择其中一个可能项，发送第二个请求获得该数据项。

HTTP 还允许发送方有条件地请求，即当浏览器发送请求时，可以在头部说明在哪种条件下应该响应请求，如果不符合条件，服务器不返回请求的数据项。条件请求通过避免不必要的传输，可使浏览器优化检索过程。

 

(9) Web 性能优化

       随着 Web 应用的普及，互联网络流量激增，网络经常处于超载状态，网络响应速度变慢。针对这种情况，人们提出了几种改善 Web 传输效率的技术，目的是尽量避免不必要的传输，减少网络负载，从而加快响应速度。

 

Web 缓存

第一种方法是 Web 缓存，即将请求到的网页放到缓存中，以备过后还要使用。通常的做法是用一个称为代理的进程来维护这个缓存，浏览器被配置为向代理而不是真正的服务器请求网页。当缓存中有所请求的页时，代理直接将页返回，否则先从服务器取回，添加到缓存中，然后返回给请求页的客户。

       在这里涉及到两个重要的问题，一是谁来做缓存，二是一个页可以缓存多长时间。在实际的使用中，每一台 PC 机通常都会运行一个本地代理，缓存自己请求过的页，以便在需要时快速找到自己访问过的页。在一个公司的局域网上，通常有一台专门的机器作为代理，该代理可被所有的机器访问。许多 ISP 也运行代理，以便为它的客户提供更快速的服务。通常所有这些代理都是一起工作的，因此请求首先被发送到本地代理，如果本地缓存中没有，本地代理会向局域网代理查询，如果局域网代理也没有，局域网代理会向 ISP 代理查询，若 ISP 代理也没有，它必须向更高层的代理请求（如果有的话）或者向真正的服务器查询。每个代理都将获得的页添加到自己的缓存中，然后再返回给请求者。这种方法称为分级缓存，一种可能的实现示于图 7-45 中。

       确定一个页需要缓存多长时间是比较困难的，因为这和页的内容以及生成时间等各种因素都有关系。事实上，所有高速缓存方案中的主要问题都是和时限有关，一方面，保留高速缓存的副本时间太长会使副本变得陈旧，另一方面，如果保留副本的时间不够长效率就会降低。因此，方案的选择既要考虑到用户对过时信息的忍受程度，也要考虑到系统为此付出的开销。

解决这个问题有两种方法，第一种方法是使用一个启发式来猜测每个页要保存多长时间，常用的一个启发式是根据 Last-Modified 头来确定保存时间，即若一个页是在距今 D T 时间前更新的，那么这个页可以在缓存中存放 D T 时间。尽管这个启发式在实际工作中运行得很好，但它确实会经常返回过时的页。另一种方法是使用条件请求，代理将客户请求的页的 URL 及缓存中该页的最后修改时间放入 If-Modified-Since 请求头中发送给服务器，若服务器发现该页自请求头中给出的时间以后未曾修改过，就发回一个简短的 Not Modified 消息，告诉代理可以使用缓存中的页，否则返回新的页。尽管该方法总是需要一个请求消息和一个响应消息，但是当缓存中的页仍然有效时响应消息是非常短的。这两种方法也可以结合起来使用，在取回页之后的 D T 时间内，如果有客户请求该页，代理直接从缓存中取出来交给客户，在此时间之后，代理使用 If-Modified-Since 消息检查页的有效性， D T 的选择通常总是根据页最后一次修改至今（取页时）经过的时间，并使用某种启发式方法。

       包含动态内容的页不应该被缓存，为此定义了一种通用的机制，允许服务器指示网页返回途中经过的每一个代理，再次使用该页前必须检查其有效性。这个机制也可用于任何可能变化非常快的网页。

       改善性能的另一个方法是积极缓存，当代理从服务器取得一个页后，它可以检查一下该页上是否有指向其它页的链接，如果有就向相关的服务器发送请求预取这些页，放在缓存中以备今后需要。这种方法能够减小后继请求的访问时间，但它也会消耗许多带宽取来许多可能根本不会用的页。

      

服务器复制

       Web 缓存是为改善 Web 性能而在客户端采用的技术，也有服务器端的技术，最常见的技术是服务器在多个相距较远的位置上复制它们的内容，这种技术称为镜像。一些访问量很大的站点，如 IEEE 的站点，通常会在世界各地设置一些镜像站点，以便用户可以从最近的站点获得服务。

       镜像站点一般是静态的，首先由网站管理层决定在哪些地方设置镜像站点，然后在这些地方放置一个服务器，将原始服务器上的部分或全部内容拷贝到镜像服务器上，站点的选择通常会保持数月或数年。但有时一些突发事件会使得一个原本默默无闻的网站突然之间变成全世界点击的焦点，巨大的流量很快使得 Web 服务器崩溃。因此，服务器应该有一种动态创建镜像的能力，即当服务器检测到流量剧烈增加时，自动在一些预先设置好的位置上创建自己的镜像，维护内容的一致性，直到该事件的影响过去后再自动关闭这些镜像。

 

内容投递网络 CDN

       因特网上有许多为用户提供内容服务的内容提供商，他们建有自己的信息网站，提供音乐、视频、新闻等各种服务。内容提供商通常借助内容投递网络（ CDN ）来为自己发送信息， CDN 会和数量众多的 ISP 签订协议，以允许在 ISP 的网络上放置自己远程可控的服务器。大型的 CDN 在全球各地可能拥有上万台服务器。

       如何将客户的请求重定向到离他最近的 CDN 服务器呢？以下是一种可能的方法。当内容提供商将自己的网站地址告诉 CDN 时， CDN 对每一个网页进行预处理，将网页中的所有 URL 替换为指向 CDN 服务器的 URL ，修改后的网页仍然存回到内容提供商的 Web 服务器上。这种修改基于这样的假设，即内容提供商的服务器中存放的网页大都很小，只包含 HTML 文本，但其中的链接通常指向很大的文件，如图像、音频、视频等。这些包含文本的网页（通常是一些内容选择菜单）仍然放在内容提供商的服务器上，并按正常方式访问，而图像、音频、视频等内容放到了 CDN 的服务器上。

       当用户输入内容提供商的网址时，取回被 CDN 修改后的网页，当用户点击其中的链接时，用户的请求会被重定向到 CDN 服务器上。 CDN 服务器并不包含任何内容，它只是一个伪 HTTP 服务器，它检查文件名和服务器名以确定请求的是哪个内容提供商的哪一个网页，它也检查输入请求的 IP 地址并查找数据库，确定用户大概在什么位置。有了这些信息后，它就可以决定使用哪一个 CDN 内容服务器为用户服务最合适，当然这个决定是很困难的，因为地理位置上最近的服务器不一定在网络拓扑结构上也是最近的，而网络拓扑上最近的服务器可能当前非常繁忙。当做出了这样的决定后，服务器会向客户返回一个带有 Location 头的响应消息，给出距用户最近的 CDN 内容服务器上文件的 URL ，这样客户的请求就被重定向到了距用户最近的 CDN 内容服务器。这些过程可见图 7-47 所示的例子。

       通常，伪 HTTP 服务器会将客户的请求重定向到距客户最近的 CDN 代理， CDN 代理拥有一个很大的缓存，里面预先下载了最重要的内容，当缓存中没有所要求的内容时， CDN 代理再从真正的 CDN 内容服务器去取，并放到自己的缓存中。

 

5.       多媒体应用

       从字面上说，多媒体就是两种或两种以上的媒体。按照这个意义，同时包含了文字和图形的书就可称为是多媒体读物。但文字和图形混排早在“多媒体”这个术语问世前就已经存在了，显然它不是通常意义上所说的多媒体技术。文字和图形称为是时间独立的（或称离散的）媒体，因为它们不包含任何时间因素。音乐和电影是时间依赖的（或称连续的）媒体，它们包含的信息必须随着时间的流动才能显现出来。我们通常所说的多媒体应用至少必须包含一种连续的媒体，而连续媒体通常就是指音频或视频。

最近几年，通过因特网发送和接收音 / 视频的网络应用呈现出爆炸式增长的趋势，如网上音乐中心、 IP 电话、视频点播、视频会议、交互式游戏、虚拟世界、远程医疗、远程教育等等。这些应用的服务需求明显不同于我们前面介绍的弹性应用（如电子邮件、万维网、文件传输等）。对于弹性应用来说，最重要的是数据完整，延时当然是越小越好，但长延时也是可以忍受的。相反，许多多媒体应用是高度时延敏感的，但它们却能容忍少量的丢包，因为偶尔的丢包只会在音 / 视频回放时出现一些干扰，而这些干扰常常可以被部分或全部隐藏。

 

(1)    多媒体应用的分类

       多媒体应用可以被分成三种类型：流式存储音 / 视频，流式实况音 / 视频，实时交互音 / 视频。我们在此不讨论下载播放应用，例如在回放一部电影前，先通过文件传输将电影下载到本地磁盘中，然后进行回放。这类应用属于没有任何特殊时延要求的弹性应用。

       在流式存储音 / 视频应用中，压缩的音频或视频文件已经预先存储在服务器上，用户下载这些文件进行播放。在这里需要注意的是，客户机通常从服务器接收文件几秒后就开始播放，这意味着当客户机从文件的一个位置开始播放音 / 视频时，还在从服务器中接收文件的后续部分。这个技术称为流（ streaming ），它避免了在开始播放之前必须下载整个文件（这可能引起较长的延时）。一旦多媒体内容开始播放，它就应该根据最初记录的时序进行，这就对数据的传输时延提出了严格的限制，因为客户机必须从服务器中及时接收数据。由于多媒体的内容已经预先录制并存储在服务器上，因此一个用户可以暂停、倒退、快进或者检索多媒体内容。从一个客户机提出这种请求到该动作在客户机中表现出来，这期间可接受的响应时间应该为 1~10 秒。目前已有很多流式多媒体产品，如 RealPlayer 、 Windows Media 和 QuickTime 等。

       流式实况音 / 视频应用类似于传统的电台广播和电视，只是它通过因特网来传输，这类应用允许用户接收来自世界任何角落的实况广播和电视传输。它和流式存储多媒体应用一样要求连续播放，但由于流式实况音 / 视频不是已存储的数据，客户机不能实现快进。从用户请求一个实况播放到播放开始可以容忍的时延最多为几十秒。与流式存储多媒体应用通常是点对点传输不同，实况广播类的应用经常有很多客户机接收同样的音 / 视频节目，因此使用 IP 多播技术能够有效地向多个接收方分发多媒体数据。

       实时交互音 / 视频应用允许人们使用音 / 视频进行实时通信，这类应用包括因特网电话、视频会议等。这类应用对端到端延时的要求最高。用户可以在任何时刻说话或者移动，多个交谈者之间可以交互谈话，从一个用户说话或者移动到某个动作到在接收主机上呈现的时延应该小于几百毫秒。对于语音，小于 150 毫秒的延时不会被听者觉察， 150~400 毫秒的时延能够接受，当时延超过 400 毫秒时，即使不会使对话变得完全无法理解，也会对语音对话造成损害。目前较著名的因特网电话包括 Skype 、 MSN Messenger 、 Yahoo Messenger 等，可用的实时视频会议产品包括微软的 NetMeeting 等。

 

(2)    因特网广播的实现

       虽然从理论上说因特网广播（ Internet Radio ）宜采用 IP 多播实现，但在实际的实现中却是每个客户与电台建立一条单独的 TCP 连接，然后在 TCP 连接上传输音频数据。

       在因特网广播中采用 TCP 单播而不是更好的 RTP 多播，主要有三个方面的原因：（ 1 ）许多 ISP 不支持多播；（ 2 ） TCP 已被广泛应用并被所有的软件包支持， RTP 却是陌生得多；（ 3 ）许多用户在工作时收听因特网广播，但大多数系统管理员在配置系统的防火墙时仅允许某些熟知端口的 TCP 包和 UDP 包通过（如 SMTP 、 DNS 、 HTTP 报文），其它所有数据包均会被过滤掉（包括携带 RTP 报文的 UDP 包）。因此，因特网广播穿过防火墙的唯一办法是让提供电台广播服务的服务器看起来像一个 HTTP 服务器，用户与服务器建立 TCP 连接，并在其上运行 HTTP 协议。

 

(3)    流式音 / 视频应用的实现

       在流式存储音 / 视频应用中，客户机请求存储在服务器上的音 / 视频文件。这些服务器可能是普通的 Web 服务器，也可能是为音 / 视频流应用定制的特殊流式服务器。收到客户机的请求后，服务器通过将文件发送到一个套接字来将音 / 视频文件发送给客户机， TCP 和 UDP 的套接字在实际中都有使用。在向网络发送音 / 视频文件之前，文件被分段，这些报文段通常用适合音 / 视频流的特殊头部进行封装，实时传输协议（ Real-time Transfer Protocol ， RTP ）是封装这种报文段的一个公共域标准。当请求的音 / 视频文件到达之后，客户机通常在几秒之内开始播放这个文件。大多数现有的产品也为用户提供交互功能，例如暂停 / 继续、快进和快退等。这种交互性也要求有一个客户 / 服务器协议，实时流协议（ Real-Time Streaming Protocol ， RTSP ）就是为用户提供交互性的一个公共域协议。音 / 视频流需要一个称为媒体播放器的应用程序来播放。

       当音 / 视频文件存储在 Web 服务器上时，音 / 视频流的实现通常采用下图的结构。当用户点击音 / 视频文件的超级链接时，该超级链接没有直接指向音 / 视频文件，而是指向一个元文件，这个元文件包括了实际音 / 视频文件的 URL 。 Web 服务器将元文件封装在 HTTP 响应报文中发送给用户的 Web 浏览器，响应头中的 Content-type 行指示特定的音 / 视频应用。浏览器分析响应头中的 Content-type 行，调用相关的媒体播放器，并将元文件传递给媒体播放器。媒体播放器与 Web 服务器建立 TCP 连接，在该连接上发送一个请求该音 / 视频文件的 HTTP 请求报文。音 / 视频文件通过 HTTP 响应报文发送给媒体播放器，媒体播放器以流的形式进行播放。

在上面的结构中，媒体播放器和服务器通过 HTTP 通信，因而也通过 TCP 通信。通常 HTTP 被认为不足以使用户和服务器进行满意地交互，特别是 HTTP 不易让用户（通过媒体播放器）向服务器发送暂停 / 继续、快进和时间跳跃命令，因而许多销售流式音 / 视频产品的公司不推荐这种体系结构。为了绕开 HTTP 和 / 或 TCP ，音 / 视频文件通常存储在流式服务器（ streaming server ）上，并直接向媒体播放器发送。这种体系结构需要两台服务器，如下图所示。一台服务器是 Web 服务器，用于 Web 页服务（包括元文件）；另一台服务器是流式服务器，用于音 / 视频文件服务。这两台服务器能够运行在同一个端系统内或者两个不同的端系统中。 Web 浏览器仍然使用 HTTP 从 Web 服务器获得元文件，然后调用相应的媒体播放器，将元文件传递给媒体播放器。媒体播放器和流式服务器通过自己的协议进行交互，如使用 RTP 传输音 / 视频数据，使用 RTSP 进行交互控制等。 RTSP 规范允许 RTSP 报文通过 TCP 或 UDP 发送，使用的端口为 544 。

 

(4)    实时交互式音 / 视频应用的实现

       在实时交互式音 / 视频应用中，需要有一个会话控制协议，负责在会话的双方之间建立、管理和终止呼叫连接。比如，会话开始时允许呼叫者通知被叫者它要开始一个呼叫并协商媒体编码类型，在呼叫持续阶段允许增加新的媒体流、改变编码、邀请新的参与者、呼叫转移和呼叫保持等，最后允许参与者结束呼叫。 SIP （ Session Initiation Protocol ）和 H.323 就是这样的两个协议，其中 SIP 来源于 IETF ，而 H.323 来源于国际电信联盟 ITU 。

       在上图的例子中，假设 Alice 和 Bob 的 PC 机都安装了基于 SIP 的软件， Alice 知道 Bob 的 PC 机的 IP 地址，并想向 Bob 发起呼叫。当 Alice 向 Bob 发送一个 INVITE 报文（类似于 HTTP 请求报文）时， SIP 会话开始。 INVITE 报文通过 UDP （也可以通过 TCP ）发送给 Bob 的 5060 端口（ SIP 的熟知端口），该报文包括 Bob 的标识（ [email protected] ）、 Alice 的 IP 地址、 Alice 准备接收音频文件的端口（ 38060 ）、可接受的音频编码格式（ AVP 0 ）、音频文件的传输协议（ RTP ）等。 Bob 发送一个同意报文（类似于 HTTP 响应）到 Alice 的 5060 端口，响应报文包括他的 IP 地址、可接受的音频编码格式（ AVP 3 ）、准备接收音频文件的端口（ 48753 ）、音频文件的分组化方法（ RTP ）等。 Alice 向 Bob 发送确认报文后，双方就可以开始交谈了。 Bob 向 Alice 发送的音频文件是 AVP 0 编码格式的，而 Alice 向 Bob 发送的音频文件是 AVP 3 编码格式的。在这个例子中，如果 Bob 没有 AVP 0 编码器，则 Bob 可以发送一个不可接受的响应，并在报文中列出他能够支持的所有编码格式；然后 Alice 从中选择一种编码格式，并发送另一个 INVITE 报文，以此通知已选择的编码格式。 Bob 也可以发送某个拒绝代码（如 busy 、 gone 、 forbidden 等）来直接拒绝该呼叫。