第17章多媒体网络应用及交换技术 水水水冰本水水水水客水水客水水冰水客水水水水水*本水水水水水水水本水水水水客水水客水水*求客水水水水水冰本水水水水水水冰客水水**水水客水冰水*水 17.1多媒体网络应用 17.1.1应用举例 17.1.2应用分类 17.1.3应用开发面临的问题 17.1.4改善服务质量 17.1.5多媒体网络应用的争论 17.2因特网上存取声音和电视的方 法 17.2.1通过Web浏览器把声音/电视 从Web服务器传送给媒体播放器 17.2.2直接把声音/电视从Web服务 器传送给媒体播放器 17.2.3直接把声音/电视从多媒体流 放服务器传送给媒体播放器 17.2.4媒体播放器的主要功能 17.3网络上的信息交换技术 17.3.1概述 7.3.2线路交换 17.3.3信息包交换 17.3.4消息交换与信息包交换 17.3.5面向连接服务与无连接服务 7.3.6网络分类 练习与思考题 参考文献和站点 因特网上已经开发了很多应用,归纳起来大致可分成两类,一类是以文本为主的数据通 信,包括文件传输、电子邮件、远程登录、网络新闻和Web等,另一类是以声音和电视图像 为主的通信。通常把任何一种声音通信和图像通信的网络应用称为多媒体网络应用 ( multimedia networking application)。网络上的多媒体通信应用和数据通信应用有比较 大的差别,多媒体应用要求在客户端播放声音和图像时要流畅,声音和图像要同步,因此对 网络的时延和带宽要求很高。而数据通信应用则把可靠性放在第一位,对网络的时延和带宽 的要求不那么苛刻。 多媒体网络技术( multimedia networking)是目前网络应用开发的最热门的技术 从本章开始到17章将围绕多媒体网络应用的话题来介绍,第14章介绍多媒体网络应用和信息 交换技术的基本概念,第15章将介绍 Internet与TCP/IP的基础知识,第16章将介绍网际多目 标广播( IP Multicast),第17章将介绍多媒体通信系统技术 17.1多媒体网络应用 17.1.1应用举例 下面是因特网上现在已经存在并且是很重要的几类应用 (1)现场声音和电视广播或者预录制内容的广播:这种应用类似于普通的无线电广播和 电视广播,不同的是在因特网上广播,用户可以接收世界上任何一个角落里发出的声音和电 视广播。这种广播可使用单目标广播( unicast)传输,也可使用更有效的多目标广播
第17章 多媒体网络应用及交换技术 *************************************************************************** 17.1 多媒体网络应用 17.1.1 应用举例 17.1.2 应用分类 17.1.3 应用开发面临的问题 17.1.4 改善服务质量 17.1.5 多媒体网络应用的争论 17.2 因特网上存取声音和电视的方 法 17.2.1 通过Web浏览器把声音/电视 从Web服务器传送给媒体播放器 17.2.2 直接把声音/电视从Web服务 器传送给媒体播放器 17.2.3 直接把声音/电视从多媒体流 放服务器传送给媒体播放器 17.2.4 媒体播放器的主要功能 17.3 网络上的信息交换技术 17.3.1 概述 17.3.2 线路交换 17.3.3 信息包交换 17.3.4 消息交换与信息包交换 17.3.5 面向连接服务与无连接服务 17.3.6 网络分类 练习与思考题 参考文献和站点 *************************************************************************** 因特网上已经开发了很多应用，归纳起来大致可分成两类，一类是以文本为主的数据通 信，包括文件传输、电子邮件、远程登录、网络新闻和Web等，另一类是以声音和电视图像 为主的通信。通常把任何一种声音通信和图像通信的网络应用称为多媒体网络应用 (multimedia networking application)。网络上的多媒体通信应用和数据通信应用有比较 大的差别，多媒体应用要求在客户端播放声音和图像时要流畅，声音和图像要同步，因此对 网络的时延和带宽要求很高。而数据通信应用则把可靠性放在第一位，对网络的时延和带宽 的要求不那么苛刻。 多媒体网络技术(multimedia networking)是目前网络应用开发的最热门的技术之一。 从本章开始到17章将围绕多媒体网络应用的话题来介绍，第14章介绍多媒体网络应用和信息 交换技术的基本概念，第15章将介绍Internet与TCP/IP的基础知识，第16章将介绍网际多目 标广播(IP Multicast)，第17章将介绍多媒体通信系统技术。 17.1 多媒体网络应用 17.1.1 应用举例 下面是因特网上现在已经存在并且是很重要的几类应用： (1) 现场声音和电视广播或者预录制内容的广播：这种应用类似于普通的无线电广播和 电视广播，不同的是在因特网上广播，用户可以接收世界上任何一个角落里发出的声音和电 视广播。这种广播可使用单目标广播(unicast)传输，也可使用更有效的多目标广播
第17章多媒体网络应用及交换技 ( multicast)传输。现在市场上有许多因特网广播产品,包括 RealNetworks公司的广播软 件—广播器( broadcasters)[3] (2)声音点播( audio on demand):在这一类应用中,客户请求传送经过压缩并存放在 服务机上的声音文件,这些文件可以包含任何类型的声音内容。例如,教授的讲课、摇滚乐、 交响乐、著名的无线电广播档案文件和历史档案记录。客户在任何时间和任何地方都可以从 声音点播服务器中读声音文件。使用因特网点播软件时,在用户启动播放器几秒钟之后就开 始播放,一边播放一边从服务机上接收文件,而不是在整个文件下载之后开始播放。边接收 文件边播放的特性叫做流放( streaming)。许多这样的产品也为用户提供交互功能。例如, 暂停/重新开始播放,跳转等功能。现在已经有许多因特网声音点播产品,包括 Realnetworks 公司的 RealPlayer和 Vocaltec公司的 Internet wave[4] (3)影视点播( video on demand),也称交互电视( Interactive Television):这种应 用与声音点播应用完全类似。存放在服务机上的压缩的影视文件可以是教授的讲课、整部电 影、预先录制的电视片、(文献)纪录片、历史事件档案片、卡通片和音乐电视片等等。存储 和播放影视文件比声音文件需要大得多的存储空间和传输带宽。现在,已经有很多因特网影 视点播产品,包括 Realnetworks公司的产品[5]。 (4)因特网电话( Internet telephony):这种应用是人们在因特网上进行通话,就像人 们在传统的线路交换电话网络上相互通信一样,可以近距离通信,也可以长途通信,而费用 却非常低 (5)分组实时电视会议( group real- time video conferencing):这类多媒体应用产品 与因特网电话类似,但可允许许多人参加。在会议期间,你可为你所想看到的人打开一个窗 口。现在也己经有许多在因特网上召开分组实时电视会议的产品,包括 Cornell University 开发的CU- SeeMe电视会议产品,图17-01是电视会议的一个画面
第17章 多媒体网络应用及交换技术 2 (multicast)传输。现在市场上有许多因特网广播产品，包括RealNetworks公司的广播软 件——广播器(broadcasters)[3]。 (2) 声音点播(audio on demand)：在这一类应用中，客户请求传送经过压缩并存放在 服务机上的声音文件，这些文件可以包含任何类型的声音内容。例如，教授的讲课、摇滚乐、 交响乐、著名的无线电广播档案文件和历史档案记录。客户在任何时间和任何地方都可以从 声音点播服务器中读声音文件。使用因特网点播软件时，在用户启动播放器几秒钟之后就开 始播放，一边播放一边从服务机上接收文件，而不是在整个文件下载之后开始播放。边接收 文件边播放的特性叫做流放(streaming)。许多这样的产品也为用户提供交互功能。例如， 暂停/重新开始播放，跳转等功能。现在已经有许多因特网声音点播产品，包括RealNetworks 公司的RealPlayer和Vocaltec公司的Internet Wave[4]。 (3) 影视点播(video on demand)，也称交互电视(Interactive Television)：这种应 用与声音点播应用完全类似。存放在服务机上的压缩的影视文件可以是教授的讲课、整部电 影、预先录制的电视片、(文献)纪录片、历史事件档案片、卡通片和音乐电视片等等。存储 和播放影视文件比声音文件需要大得多的存储空间和传输带宽。现在，已经有很多因特网影 视点播产品，包括RealNetworks公司的产品[5]。 (4) 因特网电话(Internet telephony)：这种应用是人们在因特网上进行通话，就像人 们在传统的线路交换电话网络上相互通信一样，可以近距离通信，也可以长途通信，而费用 却非常低。 (5) 分组实时电视会议(group real-time video conferencing)：这类多媒体应用产品 与因特网电话类似，但可允许许多人参加。在会议期间，你可为你所想看到的人打开一个窗 口。现在也已经有许多在因特网上召开分组实时电视会议的产品，包括Cornell University 开发的CU-SeeMe电视会议产品，图17-01是电视会议的一个画面
第17章多媒体网络应用及交换技 □ Thecate Nyo回 Antarctica 空面订圆圈 147f ■167你 8 Kbp KUR- nterneTu西 三 Antarctica≡ ature here ts -l0 國圈画 空面圈 回 HIU_LaEE O cybersmith2旦 TE GlobalSchHous 171f 图17-01实时电视会议CU- SeeMe的画面 17.1.2应用分类 如果按照用户使用时的交互的频繁程度来划分,多媒体网络应用可分成3类 1.现场交互应用( live interactive applications):因特网电话和实时电视会议是频 繁交互的应用例子。在这种应用场合下,与会者在任何时候都可能说话或者移动。从与会者 说话或者移动的动作到达接收端的时延应该小于几百毫秒才能为用户接受。人的听觉系统对 延迟小于150毫秒的声音感觉不到有时延,在150毫秒~400毫秒之间的时延可以接受,时延 超过400毫秒的会话就令人甚感别扭 2.交互应用( interactive applications):声音点播、影视点播是交互应用的例子 在这种应用场合下,用户仅仅是要求服务器开始传输文件、暂停、从头开始播放或者是跳转 而已。从用户发出请求播放到在客户机上开始播放之间的时延大约在1~5秒钟就可以接受 对信息包时延和抖动的要求不像因特网电话和实时会议那样高。 3.非实时交互应用(non- interactive applications):现场声音广播和电视广播或者 预录内容的广播是非实时交互应用的例子。在这些应用场合下,发送端连续发出声音和电视 数据,而用户只是简单地调用播放器播放,如同普通的无线电广播或者电视广播。从源端发 出声音或者电视信号到接收端播放之间的时延在10秒或者更多一些都可以接受。对信号的抖 动要求也可以比交互应用的要求低 17.1.3应用开发面临的问题 因特网为所有应用提供两种类型的服务:①可靠的面向连接服务( reliable connection- oriented service):使用TCP( Transfer Control Protocol)协议提供的服务属 于可靠服务,可靠的TCP服务保证把信息包传送到对方,对信息包的时延要求并不高。②不
第17章 多媒体网络应用及交换技术 3 图17-01 实时电视会议CU-SeeMe的画面 17.1.2 应用分类 如果按照用户使用时的交互的频繁程度来划分，多媒体网络应用可分成3类： 1. 现场交互应用(live interactive applications)：因特网电话和实时电视会议是频 繁交互的应用例子。在这种应用场合下，与会者在任何时候都可能说话或者移动。从与会者 说话或者移动的动作到达接收端的时延应该小于几百毫秒才能为用户接受。人的听觉系统对 延迟小于150毫秒的声音感觉不到有时延，在150毫秒～400毫秒之间的时延可以接受，时延 超过400毫秒的会话就令人甚感别扭。 2. 交互应用(interactive applications)：声音点播、影视点播是交互应用的例子。 在这种应用场合下，用户仅仅是要求服务器开始传输文件、暂停、从头开始播放或者是跳转 而已。从用户发出请求播放到在客户机上开始播放之间的时延大约在1～5秒钟就可以接受。 对信息包时延和抖动的要求不像因特网电话和实时会议那样高。 3. 非实时交互应用(non-interactive applications)：现场声音广播和电视广播或者 预录内容的广播是非实时交互应用的例子。在这些应用场合下，发送端连续发出声音和电视 数据，而用户只是简单地调用播放器播放，如同普通的无线电广播或者电视广播。从源端发 出声音或者电视信号到接收端播放之间的时延在10秒或者更多一些都可以接受。对信号的抖 动要求也可以比交互应用的要求低。 17.1.3 应用开发面临的问题 因 特 网为 所有 应用 提供 两种 类 型的 服务 ：① 可靠 的面 向连 接 服务 (reliable connection-oriented service)：使用TCP(Transfer Control Protocol)协议提供的服务属 于可靠服务，可靠的TCP服务保证把信息包传送到对方，对信息包的时延要求并不高。②不
第17章多媒体网络应用及交换技 可靠的无连接服务( unreliable connectionless service):使用 UDP User Datagram Protocol)协议提供的服务属于不可靠服务,不可靠的UDP服务不作任何担保,既不保证传送 过程中不丢信息包,也不保证时延满足应用要求。此外,因特网现在提供的服务对所有信息 包的传送都是平等的,像对时延要求很高的声音信息包和电视信息包在路由器的队列中都没 有任何的优先权,在因特网上任何人都要排队等待。 由于对信息包的时延和时延的大小缺乏任何保证,因此开发任何一种成功的多媒体网络 应用都是非常困难的。时至今日,因特网上的多媒体应用取得了重大的成就,但还只是有限 度的成功。例如,虽然只有几秒种时延的交互式声音点播在因特网上已是老生常谈的事情, 但它是工作在因特网上,在越大洋过大海的拥挤的链路上传输时,声音的时延和丢失往往就 令人难于接受。即使在大陆区里,由于在高峰期出现的拥挤,使声音的质量大大下降 直至现在,成功的因特网电话和实时电视会议产品比成功的声音点播和影视点播产品 少,因为它们对信息包的时延和抖动要求非常苛刻。实时声音和电视产品可在带宽足够宽的 因特网上工作得很好,信息包的时延和抖动都非常小,但当一遇到拥挤链路时,声音和图像 的质量就恶化到不能接受的地步 归纳起来,目前多媒体网络应用要集中解决个问题是:①提高网络带宽,②减少时延 ( delay),③减少抖动( JItter)。 17.1.4改善服务质量 目前我们不得不忍受因特网的这种可靠性服务:无论你的信息包多么重要,也无论你的 信息包多么有价值,它们都必须要参加排队和等待才能得到服务。在这种条件的限制下,人 们已经作出了种种努力来改进设计以提高多媒体网络应用的质量。例如,使用UDP协议而不 使用TCP:在接收端增加延迟播放时间(例如100毫秒或者更多)来减少网络引入的延迟抖动 这可在发送端给信息包打上时间标记,接收端就可以知道信息包什么时候应该播放:我们还 可给信息包添加错误校正码以减少传输过程中丢失的信息包所造成的质量下降 17.1.5多媒体网络应用的争论 现在有许许多多的有关因特网应该如何发展的争论,而且有时争论得很激烈,争论的焦 点是如何更好地安排对时间要求非常苛刻的多媒体的交通。 一个极端是某些研究人员主张对最佳服务和底层的因特网协议不作任何改变,用扩大链 路带宽的办法来解决:反对这种观点的研究人员认为,加大带宽费用太大,扩大的带宽也会 很快被对带宽贪得无厌的多媒体应用吃掉。例如,高清晰度影视点播就是一个例子 另一个极端是某些研究人员主张应该对因特网做基本变更,为各种应用保留端一端的带 宽。例如,某些研究人员觉得,如果用户想从主机A给主机B打因特网电话,就应该给由A到B 路途上的每个链路明确保留带宽。采用这种方法解决多媒体的交通问题须要做一些比较大的 变更: )须要开发保留带宽协议。 (2)须要修改路由器队列中行程安排的策略才能实现带宽的保留。采用这种方案之后 信息包在传送过程中不再平等对待,而是付钱越多的信息包,带宽保留的越多 (3)须要给网络一个交通说明,这样网络就必须要维持每种应用的交通。 (4)网络必须要有一种手段以确定是否有足够的带宽来支持新的带宽保留请求。把上述 这些变更组合在一起时,就需要有新的和复杂的软件来支持 在这两个极端之间,某些研究人员不主张对因特网作比较多的更改,而是在网沿(edge of network),即在用户和ISP之间的接口上添加简单的定价和监视措施,根据用户冲浪使用 的速率和时间来收费。例如,用户使用28.8kb/s速率去冲浪是一种价格,使用10Mb/s速率 去冲浪又是一种价格,这种定价方案对距离是不敏感的。这些研究人员认为,通过简单地增
第17章 多媒体网络应用及交换技术 4 可靠的无连接服务( unreliable connectionless service) ：使用UDP(User Datagram Protocol)协议提供的服务属于不可靠服务，不可靠的UDP服务不作任何担保，既不保证传送 过程中不丢信息包，也不保证时延满足应用要求。此外，因特网现在提供的服务对所有信息 包的传送都是平等的，像对时延要求很高的声音信息包和电视信息包在路由器的队列中都没 有任何的优先权，在因特网上任何人都要排队等待。 由于对信息包的时延和时延的大小缺乏任何保证，因此开发任何一种成功的多媒体网络 应用都是非常困难的。时至今日，因特网上的多媒体应用取得了重大的成就，但还只是有限 度的成功。例如，虽然只有几秒种时延的交互式声音点播在因特网上已是老生常谈的事情， 但它是工作在因特网上，在越大洋过大海的拥挤的链路上传输时，声音的时延和丢失往往就 令人难于接受。即使在大陆区里，由于在高峰期出现的拥挤，使声音的质量大大下降。 直至现在，成功的因特网电话和实时电视会议产品比成功的声音点播和影视点播产品 少，因为它们对信息包的时延和抖动要求非常苛刻。实时声音和电视产品可在带宽足够宽的 因特网上工作得很好，信息包的时延和抖动都非常小，但当一遇到拥挤链路时，声音和图像 的质量就恶化到不能接受的地步。 归纳起来，目前多媒体网络应用要集中解决个问题是：①提高网络带宽，②减少时延 (delay)，③减少抖动(jitter)。 17.1.4 改善服务质量 目前我们不得不忍受因特网的这种可靠性服务：无论你的信息包多么重要，也无论你的 信息包多么有价值，它们都必须要参加排队和等待才能得到服务。在这种条件的限制下，人 们已经作出了种种努力来改进设计以提高多媒体网络应用的质量。例如，使用UDP协议而不 使用TCP；在接收端增加延迟播放时间(例如100毫秒或者更多)来减少网络引入的延迟抖动， 这可在发送端给信息包打上时间标记，接收端就可以知道信息包什么时候应该播放；我们还 可给信息包添加错误校正码以减少传输过程中丢失的信息包所造成的质量下降。 17.1.5 多媒体网络应用的争论 现在有许许多多的有关因特网应该如何发展的争论，而且有时争论得很激烈，争论的焦 点是如何更好地安排对时间要求非常苛刻的多媒体的交通。 一个极端是某些研究人员主张对最佳服务和底层的因特网协议不作任何改变，用扩大链 路带宽的办法来解决；反对这种观点的研究人员认为，加大带宽费用太大，扩大的带宽也会 很快被对带宽贪得无厌的多媒体应用吃掉。例如，高清晰度影视点播就是一个例子。 另一个极端是某些研究人员主张应该对因特网做基本变更，为各种应用保留端－端的带 宽。例如，某些研究人员觉得，如果用户想从主机A给主机B打因特网电话，就应该给由A到B 路途上的每个链路明确保留带宽。采用这种方法解决多媒体的交通问题须要做一些比较大的 变更： (1) 须要开发保留带宽协议。 (2) 须要修改路由器队列中行程安排的策略才能实现带宽的保留。采用这种方案之后， 信息包在传送过程中不再平等对待，而是付钱越多的信息包，带宽保留的越多。 (3) 须要给网络一个交通说明，这样网络就必须要维持每种应用的交通。 (4) 网络必须要有一种手段以确定是否有足够的带宽来支持新的带宽保留请求。把上述 这些变更组合在一起时，就需要有新的和复杂的软件来支持。 在这两个极端之间，某些研究人员不主张对因特网作比较多的更改，而是在网沿(edge of network)，即在用户和ISP之间的接口上添加简单的定价和监视措施，根据用户冲浪使用 的速率和时间来收费。例如，用户使用28.8 kb/s速率去冲浪是一种价格，使用10 Mb/s速率 去冲浪又是一种价格，这种定价方案对距离是不敏感的。这些研究人员认为，通过简单地增
第17章多媒体网络应用及交换技术 加价格,当网络出现明显拥挤时多媒体网络应用的服务质量有可能得到保证。 17.2因特网上存取声音和电视的方法 经过压缩的声音或者电视文件可以放在Web服务器上,或者放在声音/电视流放服务器 ( streaming server)上。对于前一种情况,由Web服务器通过HTP协议把文件传送给客户 对于后一种情况,由流放服务器通过非HTTP协议把文件传送给客户。 由于声音点播和影视点播应用还没有完全直接集成到现在的Web浏览器中,就需要一个 单独的应用程序——帮助器( helper),通常叫做媒体播放器( media player)来播放声音和影 视。典型的媒体播放器要执行妤几个功能,包括解压缩、消除抖动、错误纠正和用户播放等 功能。现在可以使用像插件这种技术把媒体播放器的用户接口放在Web客户机的用户界面上, 浏览器在当前web页面上保留屏幕空间,并且由媒体播放器来管理。目前,客户机可使用几 种方法来读取声音和影视文件,下面介绍其中的三种 17.2.1通过Web浏览器把声音/电视从Web服务器传送给媒体播放器 对客户机读取多媒体的最简方法是把声音/电视文件放到HTTP服务器上,然后通过浏览 器把文件传送给媒体播放器,见图17-02,过程如下 (1)Web浏览器与Web服务器建立TCP连接,然后提交HTP请求消息请求传送声音/电视文 件 (2)Web服务器给Web浏览器发送响应消息和请求的声音/电视文件 (3)Web浏览器检査HTTP响应消息中的内容的类型,调用相应的媒体播放器,然后把声 音/电视文件或者是指向文件的指针递送给媒体播放器。 (4)媒体播放器播放声音/电视文件 这种方法虽然简单,但存在比较大的时延问题因为媒体播放器必须通过第三者——Web 浏览器才能从Web服务器上得到声音/电视文件,而且浏览器需要把整个文件从Web服务器下 载到浏览器之后才把它传送给媒体播放器。这样做的结果是,即使对中等大小的文件,在这 传输过程中引入的播放时延也是很难接受的。由此想到的改进方法是去掉中间环节,设法让 媒体播放器与Web服务器直接建立链接 HTTP请求响应 浏览器 服务器 声音/电视文件 媒体 播放器 图17-02通过Web浏览器把声音/电视从Web服务器传送给媒体播放器 17.22直接把声音/电视从Web服务器传送给媒体播放器 为把声音/电视文件直接传输给媒体播放器,须要在Web服务器和媒体播放器之间建立直 接的TCP连接( TCP connection),见图17-03,这可通过下面的方法来实现 (1)用户点击超级链接以请求传送声音/电视文件 (2)这个超级链接不直接指向声音/电视文件,而是指向一个播放说明文件 ( presentation description file),这个文件包含有实际的声音/电视文件的 地址(URL)。播放说明文件被封装在HTP响应消息中。 (3)Web浏览器接收到HTTP响应消息之后就检查响应消息中的内容的类型,调用相应的
第17章 多媒体网络应用及交换技术 5 加价格，当网络出现明显拥挤时多媒体网络应用的服务质量有可能得到保证。 17.2 因特网上存取声音和电视的方法 经过压缩的声音或者电视文件可以放在Web服务器上，或者放在声音/电视流放服务器 (streaming server)上。对于前一种情况，由Web服务器通过HTTP协议把文件传送给客户。 对于后一种情况，由流放服务器通过非HTTP协议把文件传送给客户。 由于声音点播和影视点播应用还没有完全直接集成到现在的Web浏览器中，就需要一个 单独的应用程序——帮助器(helper)，通常叫做媒体播放器(media player)来播放声音和影 视。典型的媒体播放器要执行好几个功能，包括解压缩、消除抖动、错误纠正和用户播放等 功能。现在可以使用像插件这种技术把媒体播放器的用户接口放在Web客户机的用户界面上， 浏览器在当前Web页面上保留屏幕空间，并且由媒体播放器来管理。目前，客户机可使用几 种方法来读取声音和影视文件，下面介绍其中的三种。 17.2.1 通过Web浏览器把声音/电视从Web服务器传送给媒体播放器 对客户机读取多媒体的最简方法是把声音/电视文件放到HTTP服务器上，然后通过浏览 器把文件传送给媒体播放器，见图17-02，过程如下： (1) Web浏览器与Web服务器建立TCP连接，然后提交HTTP请求消息请求传送声音/电视文 件。 (2) Web服务器给Web浏览器发送响应消息和请求的声音/电视文件。 (3) Web浏览器检查HTTP响应消息中的内容的类型，调用相应的媒体播放器，然后把声 音/电视文件或者是指向文件的指针递送给媒体播放器。 (4) 媒体播放器播放声音/电视文件。 这种方法虽然简单，但存在比较大的时延问题。因为媒体播放器必须通过第三者——Web 浏览器才能从Web服务器上得到声音/电视文件，而且浏览器需要把整个文件从Web服务器下 载到浏览器之后才把它传送给媒体播放器。这样做的结果是，即使对中等大小的文件，在这 传输过程中引入的播放时延也是很难接受的。由此想到的改进方法是去掉中间环节，设法让 媒体播放器与Web服务器直接建立链接， Web 浏览器 媒体 播放器 Web 服务器 HTTP请求/响应 声音/电视文件 图17-02 通过Web浏览器把声音/电视从Web服务器传送给媒体播放器 17.2.2 直接把声音/电视从Web服务器传送给媒体播放器 为把声音/电视文件直接传输给媒体播放器，须要在Web服务器和媒体播放器之间建立直 接的TCP连接(TCP connection)，见图17-03，这可通过下面的方法来实现： (1) 用户点击超级链接以请求传送声音/电视文件。 (2) 这个超级 链接不 直接指 向声音/ 电视文 件，而是 指向一 个播放 说明文件 (presentation description file)，这个文件包含有实际的声音/电视文件的 地址(URL)。播放说明文件被封装在HTTP响应消息中。 (3) Web浏览器接收到HTTP响应消息之后就检查响应消息中的内容的类型，调用相应的