媒体服务器

       IPTV中的媒体服务系统不同于网络文件服务系统。从功能实现上，流媒体网络服务系统和传统网络文件服务系统虽然在对数据对象的共享使用和追求最大化数据吞吐率方面有许多相似之处，但流媒体更为强调对高速稳定和连续的访问流支持，强调对同步的支持,从而确保媒体数据的按时到达。

       在IPTV系统中媒体服务器是一个沟通用户和节目提供者的桥梁，然而节目提供者并不直接与用户打交道，而是通过分配网络和服务器与用户建立联系。用户需求首先被送到服务器，由服务器的业务网关分析用户所要的服务，并与用户建立会话连接，然后服务器再从节目提供者上调取相应的节目内容,通过网络送给用户。因此，服务器应具有与网络的接口、连接控制功能、会话控制功能、分析和处理各种业务的能力以及在节目提供者和用户之间传送节目的能力。

       除此之外，媒体服务器还要完成节目的存储和回放控制。为满足众多用户的不同要求，媒体服务器要存储大量的节目，因而需要一个海量的存储系统。半导体存储器由于价格昂贵，一般作为高速缓存器；磁带由于性能稍差，只能用于资料性节目的存储；磁盘的容量大，价格和性能适中，一般作为在线存储系统的主体。随着光盘存储技术的快速发展，光盘正逐渐进入媒体服务器的应用。为了节省存储空间和传输带宽，一般情况下节目要经过数据压缩。服务器通过与终端的交互作用来控制节目的播放，包括各种类似视频录像机（VCR）的控制功能。
 

       IPTV这种多用户按需播放节目的业务对大型的视频存储系统提出了以下基本要求。

     （1）巨大的输出带宽：视频信号经过压缩后信息量仍然很大，视频服务器要向成千上万个用户同时提供节目，对存储系统的输出带宽提出了很高的要求；如果一个用户对服务器的随机动态访问被称为一个会话过程，那么服务器能够支持成千上万个同时进行而又相互独立的会话过程。

     （2）实时连续地传输节目：视音频信息属于连续媒体，所以对视音频序列进行检索在时间上有严格要求，必须及时地把数据传给用户，否则图像和声音的连续性就会遭到破坏。

     （3）能够存储至少几百小时的节目。

     （4）具有一套用户访问控制机制，结合系统资源的使用情况对用户的点播请求进行处理；采取一定的安全措施防止非法用户的访问。

       此外,先进的媒体服务器还要提供VCR的控制功能。磁盘存储器是存储系统的主体，而磁盘存储器有物理性能的局限性，如数据传输速率不高、搜索时间长等。这些因素增加了媒体服务器的设计难度。

       从功能上讲，流媒体服务器分为事务处理系统和码流检索与输出系统，如图3-5所示。

图3-5  服务器的功能结构

       事务处理系统处理服务器与用户终端之间的控制信令。数据库中存有节目的目录、节目的存储位置、服务器资源使用情况等信息。事务处理系统采取一定的访问控制算法接受或拒绝用户的点播请求，当用户的请求被接受时,事务处理系统向码流检索与输出系统发出相应的操作指令，由码流检索与输出系统完成具体的数据访问操作。事务处理系统还向业务管理系统提供原始信息，包括计费信息等。

       码流检索与输出系统按照一定的调度算法为每个获得服务的用户读取相应的节目，并通过网络接口传给用户。节目检索与输出系统可分为节目存储、码流交换和输出模块3个子系统。存储系统处理用户对磁盘数据的多重并发访问，以平稳的速度向用户提供码流，输出的码流经过码流交换系统输出到相应的输出模块,输出模块完成节目下行传输的协议转换。

       在目前的存储技术条件下，通过对连续媒体的数据存储格式和多用户磁盘访问调度算法进行精心的设计，可以在保证节目的连续性的同时，尽可能缩短磁头用于数据搜索的时间，磁盘的数据传输率得到充分的利用。但是，由于磁盘性能的局限性和其他一些因素，服务器在处理服务请求时不可避免地要引入一定的响应时延。（1）用户的请求在时间上和节目内容上有很大随机性；（2）从多用户磁盘访问调度的角度来讲，保持已获得服务的用户的节目连续性同为满足新用户请求而实时读取数据是矛盾的，优化磁头的移动路径以缩短数据搜索时间同减小点播请求响应时延是矛盾的。

         由于上面的原因，在流媒体服务器的设计上有时要主动降低在响应时延上的要求而换取其他性能指标的提高。如果多个用户以很短的时间间隔点播同一节目，那么延迟第一个用户点播的节目的播放，就可以采用批处理的方法给多个用户分配一条共享信道。这种批处理方法在很大程度上提高了服务器资源的利用率,从而提高了可同时服务的用户数。对流行的电影以一定的时间间隔用不同的频道同时播放来实现准视频点播，实际上就是采用批处理的方法降低了其对资源的需求。

       目前，多媒体存储系统设计研究的主要问题是寻找有效的连续媒体存储格式、多用户磁盘访问的调度算法、数据缓存方法和用户访问控制算法等，以求在硬件的费用（如缓存器的大小）、交互性功能（如VCR控制功能）、点播响应延迟时间（如启动节目播放的响应时间）和可同时提供的码流数等性能指标之间得到最佳的折中，而服务器性能的全面提高还有赖于存储技术取得巨大的进展。

      流媒体服务器是IPTV系统中的重要单元，其主要功能是：

     （1）大容量流媒体存储。典型的流媒体存储器应大于几百GB的空间，可存储几百部90分钟的影片，釆用多重单元互连可提供几倍影片容量。

     （2）节目检索和服务。服务器接收所有用户的信号以便对服务器进行控制，其控制处理能力要根据应用的不同进行设计：交互较少的影片点播，只需较少的控制处理能力；而对交互式较多的交互式学习、交互式购物及交互式视频游戏，就需要高性能的计算平台。

     （3）快速的传送通道。服务器有一个高速、宽带的下行通道与编码路由器相连，把服务数据（视频、音频及嵌入控制信号的数据）传送给各个用户。通过总线每秒传送10GB以上的数据。同时，服务器还接收来自用户请求终端的各种反向通路信号，每个用户要求的带宽较低，当然数据量和速率也取决于用户的多少。

     （4）提供对信源、音乐、交互式游戏和其他软件的随机即时访问。

     （5）提供顺序的、批量的对在线媒介（如数字化存储电影的磁带或磁盘）的访问。

     （6）将服务器中的资料分布到适当的存储设备上，以扩大观众数量。

     （7）提供扩展冗余，当某些部件发生故障时不必使网络停机即可使服务器恢复正常运行。
       另外，流媒体服务器必须能够存储供不同用户选择的大量节目资源，能够支持上千个用户，并能在任何时候同时向所有用户设备提供服务。流媒体服务器支持的观众交互性程度受到磁盘寻址时间和节目决定可能性的影响。在一般情况下，磁盘寻址时间应控制在10ms以内。此外，为了实现一定程度的可靠性，应设计出能满足系统目标所需数量的冗余。尽量采用模块化结构，是扩大配置范围、提高系统可靠性、降低生产成本、提高投资效益的有效方法。

      IPTV系统目前主要有3种基本的服务器结构：在通用主机上实现的视频服务器、用紧耦合多处理器实现的流媒体服务器和专门设计的多线程流媒体服务器。通用主机的方法是最容易实现的方案，但是费用较高，可靠性取决于主机系统。紧耦合多处理器方法能处理更多的并行节目，比主机方法便宜一些。因为它拥有更多的冗余，可靠性高于主机方案。专用的多线程流媒体服务器的设计目标就是针对多媒体服务应用的，它首先是一个数据传送系统，因而不需要大量的计算处理能力，所以釆用扩充的模块化结构，支持多个并行数字通道，每个数据通路都能支持多个流媒体线程。由于设计时留有大量冗余，所以它的可靠性比前两种有了较大的提高。

（1） 通用主机方法

通用主机系统采用计算机主机来实现流媒体服务器的功能，它是一个运行标准操作系统的通用系统。这种方法很容易在现有电子技术的基础上实现流媒体服务器功能，是目前小规模IPTV应用的主要方式。但由于流媒体服务器的主要功能是存储、选择、传送大量的数据，很少进行数据处理，而计算机主机系统的主要功能在于数据处理。因此，如果将主机作为流媒体服务器使用，既不利于发挥主机功能，又增加了IPTV系统的成本。此外，流媒体服务器的可靠性取决于计算机主机的可靠性，这既增加了流媒体服务器的检测指令，又增加了不必要的线路网络，因此，研究开发具有专门功能、结构简单的流媒体服务器是发展IPTV的首要任务。

（2） 紧耦合多处理机方法

按照流媒体服务器的功能要求，制作出数以千计的完成某项指令或专门功能的硬件单元，然后将相关的硬件单元组合成相应的专用系统。这些系统，有的用于创建静止图像，有的是数据库管理器，还有的是网络设备和其他动态多媒体信息的数据库。最后，将这些系统级联起来,构成一个紧耦合多处理机实现的流媒体服务器。这种服务器费用低、性能高、功能强，具有解决专项问题的特征，但节目选择受到一定的限制，用户库的大小必须在有限范围内，扩展性较差。

（3） 多线程流媒体服务器

专为流媒体服务而设计的多线程服务器是一个数据传送系统，它不需要大量的计算处理能力，所以釆用可扩充的模块结构，支持多个并行数字通道，每个数据通路都能支持多个流媒体线程。由于设计留有大量冗余,所以它的可靠性有了较大的提高。为提高编程有效性，在流媒体服务器中设计了专用的指令系统，又增加了专用的函数调用，使得访问IP网变得更加容易。流媒体服务器有一个灵巧的服务器母板，可以连接多个磁盘控制器，支持多达几十个磁盘驱动器和几百个线程的操作，它可通过标准的IP交换机互连到多路网络系统中。要扩充系统，只要增加更多的磁盘控制卡。服务器母板除连接IP打包器外还连接控制计算机。显然，只要增加系统的冗余可方便地改善系统的可靠性，其模块化结构也增加了系统的扩展性。

       为了支持对多客户的并发访问，此类服务器使用了多线程机制。线程是一个进程中的独立代码执行序列。传统的Unix进程只包含一个线程，占据进程的全部内存空间和其他资源。在提供多线程的系统中，每一个进程包含不止一个线程，这些线程共享进程的内存空间和其他资源，一个线程对内存写的内容，可以被进程中的其他线程直接访问，系统以线程为调度的单位。和使用多进程来支持并发任务相比，使用多线程占用更少的内存和其他系统资源；更易采用硬件的并行特性；占用处理器时间长的任务可以用单独的线程来完成，更易对客户产生响应；多个线程可以工作在异步模式，更好地利用处理器。由于多线程机制的诸多优点，因此选择多线程机制来构造流媒体服务器，如图3-6所示。

图3-6    多线程流媒体服务器框图

      如果希望提供能够真正交互控制的媒体流或是需要实时广播的媒体流，那么就需要一个流媒体服务器软件的支持。流媒体服务器的设计可以提供强壮和有效的手段来发送流媒体。作为HTTP的替代或补充，流媒体服务器釆用了实时流协议RTSP和MMS,这些协议更适合于作为流的音频和视频数据发送。

       为了提供持续高质量和可靠的流媒体服务，要求具备一个很好计划过的硬件服务器网络以及一个或多个高带宽的网络连接，所以，许多流媒体内容提供者发现将操作流媒体服务器的任务交给互联网服务提供商比自己运作流媒体服务器更加有效。通过了解流媒体服务器的工作原理，就可以计划所需的带宽需求并根据需求决定哪种服务器软件更合乎要求。理解流媒体网络组织的不同方式以优化可用的带宽和保证持续的高质量运转也是很重要的。

(1) 流媒体平台

       QuickTime,RealSystem和WindowsMedia的流媒体服务器几乎具备一样的功能。它们之间最大的不同在于它们运行的平台以及它们发送的流媒体格式不同。所有这3种软件都是成熟的、新的和具备完整功能的，而且这3种软件都被广泛使用。

        QuickTime和RealSystem都使用RTSP协议来发送流媒体文件，而WindowsMedia则使用它自己的协议MMS。这3种流媒体服务器都支持自己的文件格式，而这些格式可以在相应的媒体播放器中播放。流媒体服务器可以发送一些其他多媒体格式，例如.mp3、,wav、.avi等，虽然这些文件类型并不是最适合作为流发送。

① AppleQuickTime和Darwin流媒体服务器

       QuickTime流媒体服务器包含在MacOSXServer中并且只能运行于Mac的硬件上。QuickTime服务器支持QuickTime格式的流媒体文件。但是并不一定非要使用Mac服务器以支持QuickTime格式的流，因为Apple还提供了Darwin流媒体服务器。Darwin服务器和QuickTime流媒体服务器具有同样的性质并且在多种Unix平台和WindowsNT/2000上都可用。Apple还提供了Darwin平台的源代码，所以需要的话可以被移植到其他平台上。QuickTime和Darwin流媒体服务器都是免费的。其他一些服务器也支持Quick¬Time格式的流，包括RealNetworks的RealServer和SunStroEdgeMediaCentralStream¬ingServero

② RealNetworksRealServer

       RealServer在Unix和WindowsNT/2000下都可用。除了RealNetwork的流格式，RealServer还支持MP3和 QuickTime文件作为流发送。

       RealServer有4个版本：Basic、Plus、Professional和Intranet。RealServer是3种主要流媒体服务器中唯一一个收费的。虽然它的Basic版本是免费的但是同时只能支持25个流，并且缺少一些高级功能。

③ WindowsMediaServices

      Windows Media Services(WMS)只能运行于基于Windows的服务器上。Windows2000Server和Advanced Server免费附加了WMSO

       WMS使用自己的MMS协议支持高级流格式(AdvancedStreamingFormat,ASF)文件。ASF文件可以有一些其他的文件扩展名，例如.wma和.wmv等。虽然WindowsMediaPlayer可以播放很多的音频和视频格式，但ASF格式是WMS支持的唯一的流格式。

       3个最主要的流媒体服务器都可以支持实时和按需发送，并且都提供了一些高级功能，例如高速缓存、多播和自动选择连接带宽以及许多其他有用的性质。不同方案之间的竞争持续提高了各自系统的质量和功能。对于许多流媒体提供者来说，操作系统是个决定因素。如果使用的是Unix,那么应该选择RealServer或是Darwin,因为WMS不能在Unix上运行。如果使用的是WindowsServer,那么由于WMS和操作系统结合得非常紧密并且包含于操作系统中不需付费，这些因素应该是选择WMS的有力理由。如果使用MACOS±的互联网服务，那么QuickTimeStreamingServer是唯—的选择。

       需要记住的是，决定选用的服务器规定了所支持的流媒体文件类型。除了服务器软件提供的额外功能外，还应该考虑所提供的音频和视频质量。如果需要除了音频和视频外其他的数据类型，服务器是否支持、对于第三方工具格式的支持以及所选用的平台的市场份额都是需要考虑的因素。如果选择运行多于一种流媒体服务器，每一个服务器都应该有一台独立的机器，或者最好有一集群机器。如果使用服务器集群，每一个流媒体服务器都应该有一个单独的集群和一个负载平衡设备。

       尽管最大的3个服务器占有了主要的市场份额，许多其他的流媒体服务器也是可用的。其中一些提供了特殊的功能而使它们对于一些媒体提供者来说很有吸引力。

      Nullsoft的SHOUTcast可以支持MP3文件，可以是实时或是随选方式。SHOUTcast服务器不单能运行于Windows上，还能运行于一些Unix上。SHOUTcast的一个很有吸引力的特性是，它是一个免费产品。SHOUTcast支持Winamp,Audion.XMMS,LiquidAudio媒体播放器，支持Windows Media格式的流或是它们自己拥有的格式。LiquidAu-dio也可以通过使用Liquid Audio插件在RealServer上作为流发送并在RealPlayer上播放。它还为媒体提供者提供了一些打包的解决方案，包括完整的DRM。

       SunStorEdge Media Central Streaming Server是运行于Sun的基于Unix的Solaris操作系统上的流媒体服务器并且支持QuickTime流格式。

       不管使用的是哪种流媒体服务器，关于安装和维护服务器的基本内容都相同。但是由于许多东西都和流媒体有关，因此带宽是应该首先考虑的最重要事项。

       容量和可靠性是决定任何计算机网络价值的两个关键因素。容量决定了可以支持多少个同时访问的观众；可靠性决定了系统可以无故障地工作多长时间。显然，获得多大的容量和可靠性取决于系统的预算。一个较少预算的广播节目提供者只能将流媒体服务运行在较低配置的服务器上，并使用较窄的线路带宽连接到IP网。因此，这种系统并不能支持非常多的并发流，而且系统会经常变得不能访问。

       如果要提供较大规模的媒体流并保证用户在任何时候请求都能得到较高质量的媒体流，就需要较多的服务器。每个流媒体内容提供商都会对其所部署的网络进行仔细的设计，此网络通常是由多个使用高带宽连接连到互联网的强大服务器组成。每个服务器都会被分配一个特定的任务，网络设计的目标是避免任何可能造成服务中止的问题。

       拥有一个由多个服务器组成的网络不仅保证持续发送高质量的流，还可以带来容量增大的其他好处。例如，也许用户需要以不同格式提供的媒体流。这就要求运行两个或更多的流媒体服务器，并且每一个都有自己的服务器集群。

       人们普遍认为保证系统可靠性的主要方式之一就是增加冗余。冗余的概念很简单，就是通过加倍组件保证比较高的可靠性。如果一个组件发生错误，另外的组件可以代替，而两个组件同时发送错误的概率要小得多。实际上，冗余意味着不只在网络中包含两个或多个副本，还有当某个组件发生错误时将任务发送到备用单元上。

       为了建立一个真正的容错网络，必须将冗余结合进链条中的每一个环节。不仅是服务器还有网络硬件（路由器、交换机、网卡）、互联网连接、交流电源，甚至整个数据中心也要被复制。对于实时广播来说,需要有冗余编码器。RealServer和WMS都支持在实时广播中如果一个编码器发送错误则自动切换到备用编码器上。在实时情况下，还要有备用的麦克风、视频摄像头等设备。

       使用冗余通常是十分有效的。例如，在两个地方使用两个完全相同的节目库可以带来以下两个好处：一是观众可以得到更高质量的媒体流，因为数据通过了比较短的传输距离；另一个好处是可以得到更高的容错性，因为即使一个数据中心整个不能服务了，另一个还可以继续提供服务。

       为了从服务器冗余设置中受益，必须有办法能够将访问任务从一个服务器转到另一个服务器。这个过程应该是动态的、自动的和对用户透明的。为达此目的，可以使用服务器集群来实现一个动态分配访问任务的系统。集群的意思是将多台服务器以某种方式连接起来，使所有的服务器可以被当作一台计算机一样控制。服务器集群有很多优点，但是对于流媒体网络来说最重要的就是负载平衡和容错性能。

       负载平衡就是在多台服务器中自动地为每台服务器分配基本平均的负载。例如，一个站点运行于4台服务器组成的集群上，并且正在支持40个并发流的用户负载。负载平衡会动态地分配每台服务器的容量，所以每台服务器都会分配到10个流的负载，而不是由一台机器支持40个流。上述功能可保持每台服务器都工作在其最大容量上限以下，从而减少了网络拥塞和软件崩溃的机会。

       容错指的是一个网络在有硬件或软件错误发生的情况下可以持续工作的能力。使用服务器集群在建立容错系统方面也有很大的帮助，因为如果集群中的一台服务器发生了错误，系统可以自动地将负载转移到其他服务器上。例如，如果如前面所说的一个4台服务器的集群中的一台发生了错误，操作系统会很快地重新将流分配到其他3台服务器上。这种能力叫做失效保护。

       可以有若干种方式将负载平衡和失效保护结合到网络中。其中一个方法称作DNS联名解析。域名服务器可以将文字的域名解析为数字的IP地址(如168.215.86.100),通过使用DNS联名解析可以将一个域名映射到几个不同的IP地址上，每一个IP地址都和一个单独的服务器对应。DNS服务器在服务器中大致平均地分配负载。

       另一个实现负载平衡和失效保护的方法是通过硬件负载平衡器。基于硬件的负载平衡是和平台无关的，而且可能比基于操作系统的解决方案要便宜，因为不需要使用负载平衡服务器。目前的网络操作系统均提供完整的负载平衡和容错特性。通过操作系统实现这些功能不要求特殊的硬件，但是要求一台独立的计算机作为负载平衡服务器。

       在Windows2000Server环境中，网络负载平衡(NetworkLoadBalancing,NLB)能够将TCP/IP客户端连接到32个服务器中分配,Microsoft集群服务(MSCS)提供了失效保护功能。在Unix系统中，每一个Unix提供商都提供了自己的服务器集群和负载平衡产品。对于Linux来说,BackhandProject提供了一套免费的服务器集群工具。

       本小节前面部分描述了通过解决可能发生的几种问题来提高网络容量和可靠性的不同方法。在实际应用中，解决这些问题经常会意味着要在网络中增加更多的服务器。在一个大型网络中，每个服务器都完成一个单一的特殊任务，每个主要的软件程序都运行于自己的服务器或服务器集群上。一个大规模的流媒体发送系统需要很多服务器，这些服务器一起

组成了数据中心，或称为节目库。节目库提供的服务功能主要有：

       • 可靠的电源。数据中心必须拥有稳压器以保证不受电力干扰的恒定电压的电源，还要有不间断电源（UPS）,以提供在失去主电源时使用电池作为备用以及遇到长时间断电时使用备用发电机。

       •  强大的空调设备。计算机在低温条件下可以更好和更持久地工作。

       •  物理安全措施。坚固的门锁和严格的访问控制可以保证避免重要设备被盗和对数据的未授权访问。

       •  网络安全。网络管理员必须加强周期性的安全备份工作。

       •  24/7监控。虽然可以在远程完成大部分的网络管理工作，但有一个管理员还是较谨慎的做法。

       •  高带宽网络连接。流媒体数据中心必须有很高容量的冗余互联网连接能力。

       •  病毒保护。病毒可以在网络中快速传播，不管多少个冗余服务器也可以使整个系统关闭，所以需要保证防毒软件是最新更新的并且定期进行病毒扫描。

       • 定期数据备份。需要将有价值的数据在永久性存储设备（如磁带或DVD-ROM）中备份，并将这些备份存放在安全的地方。不同的数据需要使用不同的备份方案。

       • 灾难抵抗能力。为避免洪水和地震的影响，大多数的数据中心建立在坚固的建筑中并远离洪泛区。

       在多个地域拥有分布式节目库可以带来很多好处，包括带宽效率和容错性。流媒体的高带宽需求意味着地域上比较接近的客戸端和服务器端是一个重要因素。而且拥有冗余的节目库可以减少灾难和互联网中枢瘫痪、大面积停电、地震等地区性事件带来的损失。

        一个媒体流的传输距离越远，丢包或是陷入某段网络拥塞的机会也就越大。如果可以将媒体流从比较靠近用户的地点发送出去，那么就可能得到较好的效果。

        边缘服务器得名于它可以被想象为接近互联网的边缘，也即尽可能地接近最终用户。在此情形下，当一个用户请求一个媒体流时，它不是从某个单一的数据中心中发送而是从最靠近这个用户的某个边缘服务器中发送出去。为达成此目的，可以将内容的副本存储于多个边缘服务器中，或是将数据存储于一个中央数据中心但是通过独立于公众互联网的一个特殊的超高带宽网络发送到边缘服务器。一些内容发送网络甚至使用高带宽的通信卫星连接将流发送到世界各地的边缘服务器中。

       前面讨论了充分利用有限带宽和增加网络可靠性的方法。使用边缘服务器可以带来两方面的好处,从流媒体服务器到客户端的较短的网络路径意味着遇到网络故障或带宽瓶颈的机会可能较少；另一个好处是可以节省互联网带宽。当然带宽节省的代价是要在边缘服务器上复制数据，但在目前的技术条件下磁盘存储空间比互联网带宽要便宜得多。

       带宽是流媒体服务的核心问题，这主要基于两个原因：一个原因是互联网上的数字音频和视频文件比绝大多数计算机文件都要大，对它们的发送需要大量的带宽；二是为了持续保持一定的媒体流质量，在媒体流从服务器到用户终端流经的网络路径都需确保有足够的带宽。然而，系统通常无法控制用户到互联网的接入带宽，也即不管传输网络状况多么好，如果用户接入网的连接状况不佳，一样无法达到质量需求。系统可以提供不同比特率的媒体流以适应更广泛的用户需求。许多IPTV系统通过提供两种或多种比特率的媒体流以适应多种类型互联网接入的用户。目前的流媒体服务器一般通过检测用户的带宽并自动发送适当速率的媒体流来满足用户需求。

       RealSystem和Windows Media Technologies都能将多个以不同比特率编码的流融合到单一的文件中。这一功能使得编码和管理数据都变得相对简单了，因为可以使用单一文件提供给不同连接速率的观众。QuickTime虽然不支持一个文件中的多个流，但是提供了通过引用在多个文件中选择适当媒体流的发送功能。

       对任何一个网络服务系统来说，如何规划带宽需求从来都是一个十分重要的问题。在创建一个流媒体发送系统时则更加重要，因为流媒体发送系统的带宽不足会引起服务质量的严重下降。在IPTV系统中所需的带宽将是由同时发生的媒体流的数量和每个媒体流的带宽需求两个因素决定的，即

总的流带宽需求=同时用户数量X每个流的平均带宽

        当然在实际系统中情况要复杂得多，在计算带宽需求时还要考虑其他一些因素。

(1) 以不同速率连接不同的用户

       如前所述-IPTV系统可以通过提供不同比特率的媒体流为使用不同接入网连接速率的用户提供服务。但用户是否可以在不同比特率的媒体流之间加以选择，以及服务器是否能够自动支持这个功能，是系统设计者在计划带宽需求时必须认真考虑的问题。

       例如，一个为入门级互联网用户提供服务的站点可能会有很大份额的低带宽用户，而一个主要为高级用户服务的站点则有很大份额的高带宽连接用户。如果考虑上述的问题，修改后的计划带宽需求计算公式如下：

       总的流媒体带宽需求=带宽1用户数X带宽1+带宽2用户数X带宽2+...+

                                          带宽N用户数量X带宽N

(2) 带宽规划时的考虑因素

       众所周知，互联网站点是受突发访问量影响很大的。在某段时间被杂志或电视广泛提及的热门事件、一个新闻事件引起用户对于某个站点主题的突然兴趣，都可能引起一个站点用户访问量的突然增加。

       如果一个站点的构造不能适应突然变高的访问量，那么这些突发访问可能会引起这个站点在访问量增大时变得不能访问。IPTV这种典型的流媒体站点也会被上述的访问量剧增所影响。而在实时广播的情况下还需要考虑另一个因素，即一些节目可能比其他节目更加吸引观众。一般的广播节目都有个主要时段问题，在该时间段内的观众数量要比平均数量多得多。对于广播电台来说，这些时段可能是早晨和下午人们开车上下班的路上时间。对于电视节目来说，主要时段是傍晚人们在晚饭时或睡觉前看电视的时段。

        对于互联网广播提供者，主要时段的带宽容量同样是一个重要问题。一个互联网广播的特殊因素是没有地域上的限制，一个时区的主要时段可能是另一个时区的沉寂期。一些互联网广播内容提供者都或多或少地将目标放在某个特定地域的市场上，但有些则不是这样。所以这样的广播提供者都必须根据他们特殊的地理位置衡量这个因素。

       当要求对带宽做预测时通常必须使用峰值利用率。然而，这样设计的结果必然导致一定数量的资源在大部分时间处于闲置状态。出于服务质量和负载平衡上的考虑，带宽规划

必须坚持以下3个原则：

        • 保持节目制作者和网络管理员之间的协调，保证管理员明确地知道哪些特定的节目会造成访问量突增；

        • 密切监视使用模式并建立一个准确的模型，描述访问量在每天不同的时刻或是每周不同日期是如何变化的；

        • 安装智能的负载平衡和访问量控制系统。

       没有任何网络能以它们数据传输容量理论值的百分之百来传输数据。实际上，实际流量应被限制于理论最大传输率的70%〜80%,这是由TCP/IP协议的实际实现方式决定的。除了这个实际的限制，还可能希望为其他的任务分配额外的带宽，例如文件传输、备份过程等。一般地，可以在流使用量比较低时运行管理任务，所以只要有另外的10%就足够了。总体上说，对于实际网络带宽容量，比较好的计算公式如下：

实际网络容量=理论最大带宽X70%

       互联网的使用在飞速增长，所以定时地衡量和分析网络流量很重要。即使如此，流量在制定的周期内也可能有一个很显著的增长，尤其是服务提供者在大力拓展业务时期。为了避免高使用率引起的服务质量降低，一般在预测用户数据量时要使用比较高的流量数值。

       前面通过采用正向设计，讨论了如何根据用户数量和媒体流速率来计算系统所需的带宽。但在现实系统中往往需要在系统已经设计好的情况下来计算可用的带宽和能够支持的用户数。因为系统设计人员可能已经有了一个要遵循的固定预算，因此只能提供一个固定的网络最大带宽。为了计算一个给定带宽情况下可以支持流的数量，可使用下面的计算公式：

 最大并发流数量=实际网络容量/每个流的平均比特率

       例如，如果有一个100Mbit/s的以太网络，希望知道可以支持多少个200kbit/s的流，则计算公式如下：

并发流数量=100000000X70%/200000=350

       当计算网络能够支持的最大流数量时，必须考虑3个因素：服务器的容量、实际内部网络的容量、实际与IP网的连接速率。当为一个网络做规划的时候，必须对这3个因素进行平衡。例如，使用一个能支持9000个并发流的服务器，而IP网的连接速率只能支持10。个并发流，显然这是一个不合理的选择。

       计算实际内部网络的容量，以及与IP网的连接速率两个因素较为简单，而预测一个特定服务器能够支持多少个媒体流则相对比较困难，因为这取决于很多因素,包括操作系统、处理器速度和内存容量。得到比较可信数据的唯一方法就是在一个实际服务器上进行试验。

        通过比较不同网络连接类型的带宽容量数据可以发现，对于多数的IPTV系统来说，服务器一般不会成为瓶颈。大多数的流媒体数据中心使用千兆以太网和多个高带宽IP网连接。如果希望保证每个用户都能持续地获得高质量的流，应限制服务器允许的并发流的数量。RealServer和WMS都允许指定一个最大的流数量或是最大的带宽数量。用户在达到限制后的连接将接收到一个消息，通知其服务器已经到了人数上限。在计算出系统可以比较宽裕地支持的并发流数量后，就可以设定一个比较合适的限量。

       在流媒体领域的最大的限制就是带宽的不足。可以随时通过限定媒体的质量或是限制访问数量来保持带宽充足，但这并不是最好的解决方案。通过几个其他途径可以在可用带宽中挤进尽可能多的流而不用牺牲质量，其中两个最重要的技术就是多播和缓存。

       缓存对于大多数计算机用户来说都是一个比较熟悉的概念，因为它被应用于计算机的很多技术上。对于任何的内容发送系统，一些内容总是会比其内容更加频繁地被请求发送。如果可以将其存储于一个用户可以更快地获得它们的特殊位置，那么就可以显著地减少平均访问时间。网络浏览器就提供了一个关于缓存的熟悉例子：每当用户请求一个网页时，一个副本就被存储于用户的本地计算机上，这样如果用户再次请求同一个网页时，它就可以比从互联网上下载更快地从本地计算机上得到。

       因为磁盘空间比网络带宽要便宜得多，可以通过简单地将内容在多个地方复制就可增加带宽效率。将用户请求转发到有一个特定节目副本的临近服务器上比将所有的请求都发送到单一的中央服务器上要有更高的效率。但是真正的缓存效率可以更高。只是复制最经常被访问的内容而不需要将所有的内容复制。通过一个缓存规划，用户第一次访问一个文件时，它被从中央服务器发送并将一个副本存储于本地网络中。当在同一个本地网络的用户请求同一个文件时，这个文件的副本就会从本地缓存中发送。

       可以采用下面几种方式来使用缓存技术。使用硬件缓存设备或是在服务器上建立基于软件的缓存是其中一个。RealNetworks提供了一个称为RealSystemProxy的软件统计并管理客户端对于流媒体的请求。RealSystemProxy可以在本地磁盘中将实时广播内容和随选流内容分离。即使流是服务器发送到的，这个系统也可以为每个请求和中央服务器通信以鉴别用户并检查更新的内容。

        防火墙是通过在内部网络和互联网之间监测连接状态从而保护内部网络信息的硬件或软件。只有使用被允许的传输协议和允许的端口的数据才可以通过防火墙。

        流媒体服务器依靠用户数据报协议UDP、实时传输协议RTP或实时流协议RTSP以高效地实现其功能，但防火墙一般都阻止了这些类型的请求。所以，无论客户端或服务器端的防火墙都将妨碍流媒体数据的传输，使它质量变低或使它根本不能被发送接收。不幸的是，防火墙问题十分复杂。它以好几种方式进行工作，每个不同的流媒体服务器包以不同的方式被处理。其中两种可能出现的防火墙情形如下。

       (1) 客户端在防火墙后。可以通过两种方式解决这个问题:将防火墙设置为可以允许RTP和RTST协议通过；如果不能如此配置，那么使用HTTP流或在80端口上打开传输控制协议TCP。

       (2) 流媒体服务器在防火墙后。该问题的解决依赖于正在使用的流媒体服务器种类。

QuickTime提供两种可能的方法解决防火墙问题：

(1) 客户端通过QuickTime设置的控制面板制定一种代理服务器(SOCKS,RTSF或HTTP)和端口号，设置QuickTime使用一个代理服务器。

(2) 流媒体服务器管理员可以配置服务器使用HTTP协议在80端口上提供流。

在可用的流媒体协议中，HTTP是效率最低的，所以不管用的是什么服务器，在决定使用HTTP流前应该先尝试其他可能的解决方法。

       RealServer不能从防火墙后发送流媒体内容。可以通过在防火墙后的内部互联网络向内部网络的其他用户提供流内容，但是如果想将流发送到互联网上，就不能将RealServer置于防火墙后。对于许多机构来说这似乎是一个两难问题，因为内部网络必须受到防火墙的保护，而RealServer又必须和内部网络连接。

       解决方法是设立一个子网屏蔽防火墙(Screened-SubnetFirewall)0这种防火墙创建一个外围网络，形象地被称为非军事区DMZ(DemilitarizedZone)o虽然DMZ在内部网外，但是还是被防火墙保护。内部网络和互联网都可以访问DMZ中的机器，但数据并不是直接通过DMZ传输。RealServer被放置于DMZ中，使用比内网中计算机较松的安全设置。

       WindowsMedia-般通过UDP/IP协议在多个端口上提供流，但是这么做对于许多防火墙是有问题的。WMS可以通过在1755端口上使用TCP/IP协议或是在80端口上使用HTTP协议解决这些问题。一个WMS流媒体服务器可以放在防火墙后面，但条件是端口必须以特定的方式加以配置。