服务器dns服务器

应用层网络应用是计算机网络存在的理由.
在过去的几十年中,许多有影响力的网络应用被创造出来,如20世纪80年代出现的电子邮件、文件传输、远程访问、新闻组、文本聊天等基于文本的网络应用,20世纪90年代中期出现的万维网(Web)应用以及包括因特网电话、视频会议、视频点播、远程教育等在内的多媒体网络应用,还有20世纪末出现的具有联系人列表的即时讯息(如MSN,YahooMessengers)和对等(peer-to-peer,P2P)文件共享等新型网络应用.
当构建一种新的网络应用时,首先需要决定应用的体系结构.
应用的体系结构规定了在各种端系统上应如何组织应用程序.
现代网络应用有3种主流的体系结构:客户/服务器体系结构,P2P体系结构,以及客户/服务器和P2P混合的体系结构.

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

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

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

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

本章介绍的几个网络应用均为客户/服务器模式的应用.
域名系统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服务器.

根DNS服务器:根DNS服务器知道所有顶级域服务器的IP地址.
因特网上有13个根DNS服务器(标号为A到M),其中大部分位于北美.

顶级域(TLD)服务器:每个顶级域至少有一个顶级域服务器,每个TLD服务器知道本域下所有二级子域的权威DNS服务器的IP地址.

权威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地址之间的映射不是永久的,所以DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息.
本地DNS服务器也可以缓存TLD服务器的IP地址,从而允许本地DNS服务器绕过查询链中的根服务器,这种情况是经常发生的.

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

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

一条资源记录就是一个五元组,它包括域名、生存期、信息类型(class)、资源记录类型(type)、值(value)五项.

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

生存期:表示资源记录的稳定性如何.
可以给一个稳定的资源记录指定一个较大的值,如86400秒(一天),给一个易变的资源记录指定一个较小的值,如60秒.

信息类型:对于Internet信息,该项总为IN,其它类型信息很少见.
资源记录类型:最重要的类型列于图7-2中,包括授权开始SOA(指明一个服务器实现的命名等级部分的多个字段)、主机IP地址(可有多个)、域邮件服务器(可有多个并列有优先级)、名字服务器(域的授权服务器名,父域服务器名)、域的别名、反向查找指针(从IP地址映射到域名)、主机信息(CPU及操作系统)及域的描述信息.

值:可以是一个数字、域名或ASCII串,其语义由记录类型决定.
一个可能的DNS数据库的部分信息如图7-3所示.
文件传输文件传输是因特网上最早出现且目前仍在频繁使用的网络应用之一,它将一个完整的文件从一个系统拷贝到另一个系统.
在早期的因特网中,用于传输文件的数据报占了网络流量的近三分之一.
直到1995年,万维网的信息流量才第一次超过了文件传输.

文件传输协议FTP因特网中最流行的文件传输服务使用FTP(FileTransferProtocol)协议,它能在任意两台计算机之间传输文件的拷贝.
虽然FTP协议明确规定了两台计算机上的FTP软件如何进行交互,但该标准并没有定义用户接口,因此不同的FTP实现所提供的用户接口可能不同.
为维护产品之间的相似性,许多厂商采纳了最早在BSDUNIX系统中使用的FTP软件版本.
BSDFTP接口含有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)数据连接的关闭可用于通知对方文件传输结束,允许动态创建文件(不需要告知对方传输文件的大小).
由于发送方用关闭连接来表示一个文件传输结束,所以数据连接总是由发送文件的一方主动关闭.

需要注意的是,在建立数据连接时客户和服务器的角色是相反的,服务器扮演客户的角色,而客户扮演服务器的角色.
建立一个数据连接的过程如下:客户进程为数据连接选择一个本地的临时端口号,并在该临时端口上等待服务器的连接请求;客户进程在控制连接上用PORT命令将临时端口号发送给服务器;服务器收到端口号后,发送一个连接请求,同客户机的该端口建立一个数据连接,服务器用于数据连接的端口号总是20.

简单文件传输协议TFTP因特网还包含另一种文件传输服务,称为简单文件传输,其协议为TFTP(TrivialFileTransferProtocol).
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),这个目录中只包含无盘系统引导所需的文件.

电子邮件因特网电子邮件系统由三个主要部分组成:用户代理、消息传输代理和简单邮件传输协议(SimpleMailTransferProtocol,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邮件格式最早在RFC822中规定.
RFC822规定了信头中可以使用的域,包括收信人、发信人、信件经过的路径等与消息传输有关的域,还有回信地址、信件编号、关键字、信件主题等供用户代理及收信人使用的域.
在电子邮件发展的初期,所有信件都是用英文写的,编码方式都是ASCII码,且信件的格式也都是纯文本格式,因此RFC822的信体不需要什么结构.
发信程序和收信程序可以直接对信体进行发送和接收,而不需要进行任何代码转换.

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

MIME在信头中扩充的最重要的两个域是:信体传输编码形式和信体数据类型.
MIME定义了五种传输编码形式:基本的ASCII编码集,扩展的ASCII编码集,二进制编码,基64编码(base64encoding),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的字符编码成一个等号再跟上该字符的十六进制值.

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

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

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

(1)客户方当用户点击了一个超级链接后,浏览器如何找到所需的页呢每个Web页使用统一资源定位器(URL)进行命名,如http://www.
itu.
org/home/index.
html.
URL由三部分组成:用于访问页的协议名称(如http)、页所在机器的域名(如www.
itu.
org)和包含页的文件(如/home/index.
html).
当用户点击了以上的超级链接后,浏览器按以下步骤工作:浏览器确定URL(从页及点击位置获取);请求DNS解析域名www.
itu.
org;DNS返回IP地址156.
106.
192.
32;浏览器与156.
106.
192.
32的端口80建立一个TCP连接;浏览器发送一个请求,要求取文件/home/index.
html;www.
itu.
org服务器发送文件/home/index.
html;释放TCP连接;浏览器显示文件/home/index.
html的所有文本内容;浏览器取回该文件中的所有图像并显示(一次取一个图像显示).
为了使得浏览器能够正确解释和显示每一个Web页,Web页必须使用称为HTML(超文本标记语言)的标准语言书写.
但并不是每一个页都是HTML格式的,如一个页可以包含PDF格式的文档、GIF格式的图标、JPEG格式的照片、MP3格式的歌曲、MPEG格式的视频等,浏览器如何来显示这些页呢当服务器返回一个页的时候,同时要返回关于这个页的一些额外信息,特别是页的MIME类型.
当页的MIME类型不是浏览器本身所支持的类型时,浏览器查找自己的MIME类型表,该表将每个MIME类型关联到一个阅读器上,浏览器调用相应的阅读器进行显示.
这些阅读器可以是和浏览器运行在同一个程序空间的插件程序,也可以是一个独立的助手程序.
浏览器也可以显示本地文件,但本地文件没有MIME类型,浏览器是通过文件的扩展名来得知文件类型的.

(2)服务器方Web服务器的典型工作过程如下:服务器在端口80监听,与请求的客户建立TCP连接,接收服务请求;确定请求的Web页(名字扩展);(若需要)认证客户;(若需要)对客户进行访问控制;(若需要)对请求的页进行访问控制;检查请求的页是否在高速缓存中;若不在高速缓存中,从本地磁盘读取文件;确定要包含在响应中的MIME类型;其它处理;将文件返回给客户,并进行日志记录;释放连接.
服务器的设计主要着眼于如何提高服务的响应速度,以及如何服务于更多的客户.
常用的技术包括将经常访问的文件保存在高速缓存中,服务器设计为多线程的且使用多个磁盘,建立serverfarm等.
(3)状态信息和cookieWeb本质上是无状态的,浏览器向服务器发送一个文件请求,服务器将请求的文件返回,此后服务器上不保留有关客户的任何信息.
当Web只用于获取公开可访问的文档时,这种工作模式是非常合适的.
但随着Web涉足其它领域,有些服务需要在确认了用户的身份后才能提供,这就需要将用户信息保存起来.
如有些软件需要用户注册后才能使用,当用户注册后,用户信息必须被保存下来,当用户下次请求服务时,这些信息就被用来判断用户是否是注册用户,从而决定如何向用户提供服务.

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

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

(4)Web文档类型Web文档按照文档内容产生的时间可以划分为三个较宽的范畴:静态文档:静态文档以文件方式保存在Web服务器上,由文档的作者决定文档的内容.
由于文档的内容不会改变,所以对静态文档的请求会产生相同的响应.

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

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

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

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

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

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

当需要在Web页中嵌入图像时,图像数据文件必须存储在一个独立的地方,然后在文档中包含指向该文件的指针.
当浏览器遇到这样一个指针时,会到指针所指的地方获得图像的拷贝,然后将图像插入到被显示的文档中.
HTML使用标签来指出获取图像文件的地方及图像在文档中的显示位置等信息,如:,其中SRC给出图像数据文件的URL,ALIGN表示显示位置,ALT是当图像不能显示时代替图像的文字.

当需要在文档中包含超级链接时,使用标签,如:NASA'shomepage,显示时包含在标签之间的文字会被加上下划线(NASA'shomepage),而点击它则会显示NASA的主页.
也可以为图像设置超级链接,如:,当点击飞船(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或UNIXShell脚本语言.
在实际应用中,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信息解释器不做任何改变,对于脚本信息解释器用解释脚本的结果代替.
为使解释器能够高速运行,模板的脚本信息使用特殊的语法.
存在以下几种服务器端脚本技术:ASP(ActiveServerPages):微软公司创建的一种动态网页技术,脚本信息用VB编写,脚本解释器与微软公司的Internet信息服务器(InternetInformatonServer,IIS)紧密集成.
JSP(JavaServerPages):一种独立于平台的动态网页技术,网页中嵌入的脚本代码是用Java语言编写的.

PHP(PerlHelperPages):一种使用Perl语言的动态网页技术,速度比ASP和JSP快,但嵌入的代码难以阅读.

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

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

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

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

微软公司的解决方案是ActiveXcontrols,这些是编译成机器语言的程序,并在硬件上执行,因此它比JavaApplet运行更快且更灵活.
当InternetExplorer在Web页中遇到一个ActiveXcontrol时,它从服务器上下载,检验其标识,然后执行.
(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头来确定保存时间,即若一个页是在距今(T时间前更新的,那么这个页可以在缓存中存放(T时间.
尽管这个启发式在实际工作中运行得很好,但它确实会经常返回过时的页.
另一种方法是使用条件请求,代理将客户请求的页的URL及缓存中该页的最后修改时间放入If-Modified-Since请求头中发送给服务器,若服务器发现该页自请求头中给出的时间以后未曾修改过,就发回一个简短的NotModified消息,告诉代理可以使用缓存中的页,否则返回新的页.
尽管该方法总是需要一个请求消息和一个响应消息,但是当缓存中的页仍然有效时响应消息是非常短的.
这两种方法也可以结合起来使用,在取回页之后的(T时间内,如果有客户请求该页,代理直接从缓存中取出来交给客户,在此时间之后,代理使用If-Modified-Since消息检查页的有效性,(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内容服务器去取,并放到自己的缓存中.

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

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

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

在流式存储音/视频应用中,压缩的音频或视频文件已经预先存储在服务器上,用户下载这些文件进行播放.
在这里需要注意的是,客户机通常从服务器接收文件几秒后就开始播放,这意味着当客户机从文件的一个位置开始播放音/视频时,还在从服务器中接收文件的后续部分.
这个技术称为流(streaming),它避免了在开始播放之前必须下载整个文件(这可能引起较长的延时).
一旦多媒体内容开始播放,它就应该根据最初记录的时序进行,这就对数据的传输时延提出了严格的限制,因为客户机必须从服务器中及时接收数据.
由于多媒体的内容已经预先录制并存储在服务器上,因此一个用户可以暂停、倒退、快进或者检索多媒体内容.
从一个客户机提出这种请求到该动作在客户机中表现出来,这期间可接受的响应时间应该为1~10秒.
目前已有很多流式多媒体产品,如RealPlayer、WindowsMedia和QuickTime等.
流式实况音/视频应用类似于传统的电台广播和电视,只是它通过因特网来传输,这类应用允许用户接收来自世界任何角落的实况广播和电视传输.
它和流式存储多媒体应用一样要求连续播放,但由于流式实况音/视频不是已存储的数据,客户机不能实现快进.
从用户请求一个实况播放到播放开始可以容忍的时延最多为几十秒.
与流式存储多媒体应用通常是点对点传输不同,实况广播类的应用经常有很多客户机接收同样的音/视频节目,因此使用IP多播技术能够有效地向多个接收方分发多媒体数据.

实时交互音/视频应用允许人们使用音/视频进行实时通信,这类应用包括因特网电话、视频会议等.
这类应用对端到端延时的要求最高.
用户可以在任何时刻说话或者移动,多个交谈者之间可以交互谈话,从一个用户说话或者移动到某个动作到在接收主机上呈现的时延应该小于几百毫秒.
对于语音,小于150毫秒的延时不会被听者觉察,150~400毫秒的时延能够接受,当时延超过400毫秒时,即使不会使对话变得完全无法理解,也会对语音对话造成损害.
目前较著名的因特网电话包括Skype、MSNMessenger、YahooMessenger等,可用的实时视频会议产品包括微软的NetMeeting等.
因特网广播的实现虽然从理论上说因特网广播(InternetRadio)宜采用IP多播实现,但在实际的实现中却是每个客户与电台建立一条单独的TCP连接,然后在TCP连接上传输音频数据.

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

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

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

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

实时交互式音/视频应用的实现在实时交互式音/视频应用中,需要有一个会话控制协议,负责在会话的双方之间建立、管理和终止呼叫连接.
比如,会话开始时允许呼叫者通知被叫者它要开始一个呼叫并协商媒体编码类型,在呼叫持续阶段允许增加新的媒体流、改变编码、邀请新的参与者、呼叫转移和呼叫保持等,最后允许参与者结束呼叫.
SIP(SessionInitiationProtocol)和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的标识(bob@193.
64.
210.
89)、Alice的IP地址、Alice准备接收音频文件的端口(38060)、可接受的音频编码格式(AVP0)、音频文件的传输协议(RTP)等.
Bob发送一个同意报文(类似于HTTP响应)到Alice的5060端口,响应报文包括他的IP地址、可接受的音频编码格式(AVP3)、准备接收音频文件的端口(48753)、音频文件的分组化方法(RTP)等.
Alice向Bob发送确认报文后,双方就可以开始交谈了.
Bob向Alice发送的音频文件是AVP0编码格式的,而Alice向Bob发送的音频文件是AVP3编码格式的.
在这个例子中,如果Bob没有AVP0编码器,则Bob可以发送一个不可接受的响应,并在报文中列出他能够支持的所有编码格式;然后Alice从中选择一种编码格式,并发送另一个INVITE报文,以此通知已选择的编码格式.
Bob也可以发送某个拒绝代码(如busy、gone、forbidden等)来直接拒绝该呼叫.