分类: WINDOWS
2007-03-01 13:24:50
摘要 本书讨论了实施 Microsoft Windows Media Technologies(Windows 媒体技术) 的最佳实践。它涵盖的主题包括协议、编码器配置和技术、服务器配置和调整、启用多播分发以及日志记录。 本页内容
引言Microsoft Windows Media Technologies 是作为 Microsoft Windows 2000 操作系统的一部分进行分发的。它允许您创建、分发和播放流媒体文件。对于 IT 专业人员来说,了解如何对 Windows 2000 Professional 和 Windows 2000 Server 进行配置以优化性能、以及可以如何通过网络分发文件是非常重要的。 下面的图 1 显示了用于传输流媒体的组件:
图 1:Windows Media Technologies 传输组件 本书将讨论与编码、服务以及通过网络传输媒体有关的组件。它包括以下信息:
本书假定您了解 WMT 以及网络传输协议的基本知识。 Microsoft Media Service 协议Windows Media Technologies 使用称为 Microsoft Media Server(MMS)的应用程序层协议,通过 Internet 和 Intranet 发送活动流格式(Active Streaming Format,ASF)的文件。指向流 ASF 文件的 URL 将 MMS 作为它的协议包括进去,如下面的示例所示: mms://servername/filename.asf MMS 协议按照下列顺序自动查找流媒体的最佳传输协议:
UDP 协议是一个无连接的传输层协议,对于实时的媒体,这个协议是最理想的,因为它并不保证交付。虽然这听起来像是一个缺点而不是优点,但它是一个特别适合流媒体的特征。与诸如文件或电子邮件这样的数据不同(它们必须完整交付而不管传输的时间有多长),流媒体的价值在于受时间限制。如果视频帧丢失,它就没有价值,因为它将不在正确的时间帧内到达。再次传输它会浪费带宽。指定仅将 UDP 用作传输协议是可能的。要这样做,您可以使用下面的语法: mmsu://servername/filename.asf UDP 的缺点是它可能无法穿过公司的防火墙。要了解更多关于如何配置防火墙以接受通过 UDP 协议传输的流 ASF 文件的信息,请参阅:
下一个选择就是 TCP,它是主要的 Internet 传输协议。TCP 的缺点是它将设法重新传输数据,而且还有可能无法穿过公司的防火墙(请参阅前面提到的文章,以了解更多关于 TCP 和防火墙的信息)。指定应该仅将 TCP 用作传输协议的语法如下:mmst://servername/filename.asf 最后的选择是 HTTP。虽然它是一个应用程序层协议而非传输层协议,而且它不是为流媒体设计的,但是 HTTP 可以穿过防火墙。任何可以浏览 Web 的人都能够通过 HTTP 接收流文件。指定应该仅将 HTTP 用作传输协议的语法如下:http://servername/filename.asf 使用 ASX 文件ASX 文件将 Web 页面链接到 ASF 文件。除非访问 Web 站点的每个客户端都在运行 Microsoft Internet Explorer,否则就不要直接在 HTML 页面中引用 MMS 路径。这是因为其他的浏览器并不理解该协议,因而在遇到该协议时会予以忽略。相反,可以引用指向流媒体文件的 ASX 文件。 简单的 ASX 文件可能如下所示: 在创建了 ASX 文件之后,可以将其放在 HTTP 或网络服务器上。要链接到 ASX 文件,请在 HTML 页面中使用标准的 标记: 当用户选择一个指向 ASX 文件的链接时,浏览器就会下载该文件(ASX 文件很小)。系统在文件关联表中查找 ASX 扩展名并启动 Windows Media Player。然后,Windows Media Player 在 ASX 文件中查找 ASF 文件的位置并打开流。要了解更多关于编写 ASX 文件的信息,请参阅 MSDN Online Web Workshop 上的相关文档 ,地址如下:。
Windows Media Encoder 可以压缩 AVI、MP3 或 WAV 格式的数字媒体文件并将其转换为 Windows Media Player 所用的 ASF 文件。该编码器既可以用于实时事件,也可以用于存储的文件。因为编码是 CPU 密集型的活动,所以建议将运行编码器的计算机与运行 Windows Media Service 的计算机分开。这一部分讨论以下与编码器有关的主题:
计算机硬件配置没有任何一种配置可以同时满足各种情况的需求。在购买新的硬件之前,请首先确定您将记录高速移动(High-Motion)视频还是记录低速移动(Low-Motion)视频。高速移动视频的例子如音乐视频等快速变化的视频,需要很高的处理能力。 选择 CPU 一般来说,对于带宽达到 300 千比特每秒(Kbps),也可能达到 500 Kbps 的任何视频,一个 Pentium II 处理器就可以执行实时编码。如果带宽达到 1 兆比特每秒(Mbps),就应该使用 Pentium III 或同等的处理器。对于更高的比特率(Microsoft CODEC 的实时编码可以扩展至 5 Mbps),可以使用两个处理器。通常,如果您正准备购买新的设备,请选择 Pentium III 或同等处理器的计算机。即使您现在不需要这样的处理能力,您将来也有可能需要使用。 增加内存 一般情况下,对于编码最理想的内存为 64 兆字节(MB)。大的内存没有必要,因为不会发生缓冲,并且只有操作系统和应用程序需要加载。可以使用性能工具来确保系统不对磁盘进行分页,以免影响性能。(要使用性能工具,请将鼠标指向开始菜单中的程序,再指向管理工具,然后单击性能。) 要检查可用内存,可以添加 Memory\Available Bytes 计数器。要检查分页发生的频率,可以添加 Memory\Pages/sec 计数器。这两个计数器均在 Memory 标题之下。图 2 给出了添加计数器的一个示例:
图 2:添加 Pages/sec 计数器 下面的图 3 显示了这些计数器以及正在使用的处理器的时间:
图 3:Performance Monitor 的示例 Memory\Available Bytes 计数器指示当前有多少字节的内存可供进程所用。这个数目应该保持在 4 MB 字节以上。Memory\Pages/sec 计数器指示因页面故障而从磁盘检索的页面数或写入磁盘以释放空间的页面数。要了解更多关于性能工具的信息,请参阅相关的帮助文件。 添加磁盘驱动器 磁盘驱动器可能是瓶颈,因为它们必须在数据传入时能够尽快捕获并存储数据。如果驱动器的传输速率太低,数据就会丢失,而流的质量也将会受到损害。对于 300 Kbps 到 500 Kbps 的编码速度,可以使用 SCSI 驱动器。对于更高的速率,可以考虑使用 RAID Level 0 磁盘阵列。 选择操作系统 尽管 Windows Media Encoder 在 Windows 2000 Professional 和 Windows 2000 Server 上都可以运行,但我们还是推荐使用 Professional,因为它可以为前台应用程序提供优先权。 选择视频捕获卡 要查找与 Windows Media Technologies 兼容的视频捕获卡的列表,请查阅“Windows Media 硬件提供商”Web 页面,地址如下:
有一点非常重要,即应该使用这个列表而不使用仅与 Windows 2000 操作系统兼容的视频捕获卡列表,因为只有一部分视频卡与它们两者兼容。最流行的视频捕获卡之一是 Viewcast.com 的 Osprey 100。虽然该卡无法捕获音频,但是迄今为止还没有人提出有关 Osprey 100 与声卡同步的问题。要了解更详细的情况,请浏览:
选择声卡 对于要对一个音频流进行编码的情况,请选择立体声声卡(如:Soundblaster Live)。Soundblaster16 或兼容卡是可接受的最低限度。请查阅 Windows 硬件兼容性列表(Windows Hardware Compatibility List)以查看符合 Windows 2000 操作系统系列的要求的声卡(任何与 Windows 2000 兼容的声卡均与 Windows Media Technologies 兼容)。硬件列表位于下列位置:
编码技术这一部分讨论音频和视频编码以及设置自动编码的技术。除了一些显而易见的区别以外,音频和视频编码还有一个不同之处,即视频文件可以包含多个比特率,而音频文件却不能包含多个比特率。多个比特率使得 Windows Media Player 可以通过选择最适于用户网络连接的质量和速度的比特率来适应不断变化的网络条件。对音频文件则不能如此,因为耳朵比眼睛更具辨识力,耳朵检测音频流中的带宽变化比眼睛检测视频流中的带宽变化更容易。 多个音频流的编码同时对多个音频流进行编码是很常见的情况。典型的示例是将不同的广播站编码为联机广播。要对多个音频流进行编码,可以在一个系统中使用多个编码器并同时运行它们。因为编码器是 CPU 密集型的,所以如有可能请使用 Pentium III。 对多个音频流进行编码需要考虑的另一个重要事项就是声卡。已有用户报告有关在一个系统中使用多个 Soundblaster 卡的问题。相反,可以安装仅需要一个插槽但有多个端口的声卡。 对多带宽视频流进行编码Windows Media Technologies 包括智能流(Intelligent Streaming)特征,它可以检测网络连接速度,调整以适应不断变化的网络条件并动态地自动提高视频流的质量。智能流作为 Windows Media Technologies Version 4.0 的组成部分之一,包括下列功能:
自动编码自动编码是指当系统启动并有人登录时编码器自动打开。当生产服务联机并持续运行时经常使用自动编码。要启用自动编码,可以创建快捷方式,其方法是使用“任务栏和开始菜单属性”窗口(要打开该窗口,请将鼠标指向“开始”菜单上的“设置”,然后单击“任务栏和开始菜单”)。下面的图 4 显示该菜单的示例:
图 4:任务栏和开始菜单窗口 单击“添加”。在“创建快捷方式”文本框中,键入: NsRex filename.asd /start 编码器的名称是 NsRex,filename 引用存储编码器配置的高级流描述符(Advanced Stream Descriptor, ASD)文件。例如,它包含有关使用哪个 CODEC 的信息、窗口的大小以及用于视频的 I 帧的帧速率以及帧数。/start 选项是指当有人登录时就开始进行编码。(为使该过程完全自动化,请启用自动登录,以便任何人均不需要键入名称和密码。)下面的图 5 给出了一个示例:
图 5:选择程序标题 在这个示例中,编码器使用称为 stereo28.8 的 .asd 文件。 Windows Media Server这一部分讨论如何配置计算机以运行 Windows Media Service,如何调整服务器以尽可能地获得最优性能以及如何保证服务器的安全。我们首先讨论服务器的硬件配置。 计算机硬件配置与 CPU 集中型的编码不同,服务器是 I/O 密集型的。服务器的瓶颈依次是网络接口卡(NIC)和磁盘系统。CPU 和内存处在第三、第四的位置。在这一部分中,我们将讨论 Windows Media Server 的最优硬件配置。 选择 CPU 和内存 对于要处理成千上万个并行连接的典型 Windows Media Server,请使用 Intel Pentium II 或同等的 CPU。除非服务器要处理 2,000 或 3,000 个以上的并行连接(每个连接的比特率均是 20 Kbps),否则没有就必要使用多个处理器。比特率越高,服务器可处理的并行连接就越少。要处理更多的并行连接,可以使用多个处理器。对于一个处理器系统,256 MB 的内存是最理想的。对于多个处理器系统,至少要使用 512 MB 内存。根据配置与服务器上的需要可能还需要更多的内存。要查看在压力下服务器的行为,可以使用 Windows Media Load Simulator,这将在本书的后面进行讨论。 选择网络接口卡 对于实时事件,在编码器和服务器之间有快速连接尤其重要。该连接属于主供给。如果没有足够的带宽,主信号将降级,用户将接收到低质量的传输。对于网络接口卡(NIC),可以使用快速以太网(100 Mbps)或 10/100 交换以太网。交换以太网将数据包从 10 Mbps 共享段传输到以 100 Mbps 运行的 LAN 段或工作站上。这使得以 10 Mbps 运行的多个终端站或工作组可以连接到以 100 Mbps 运行的服务器。 要处理 4,000 个并行连接(使两条 T3 线达到饱和),可以考虑添加另一个 NIC,以便于在编码器和服务器之间有独立的连接。即使网络连接饱和,主供给也不会受到影响且不会降级。网卡应配置为“全双工(full-duplex)”,即它们可同时发送并接收数据。 选择磁盘驱动器 快速磁盘驱动器对于良好的服务器性能至关重要。Windows Media Server 的可伸缩性经常受到磁盘阵列性能的限制。对于大量的并行连接,建议在 RAID 配置中使用多个硬盘。由于数据传输速率高,应考虑使用 SCSI 和光纤信道(如下所示)接口,但是最好咨询首选的硬件厂商以确定最佳配置。 随着所用文件的增多或可用缓存的减少,对磁盘速度的要求就提高了。注意:Windows Media Server 不使用缓存。因此,除非磁盘控制器上有缓存,否则每次读取均是显式从物理磁盘提取数据。 不要在系统驱动器上保存 ASF 根目录,因为在此会发生大量的活动和磁盘交换。另外,在多个驱动器上保存经常使用的内容的副本,这样用户就可以通过不同的路径进行连接。根据经验,一个磁盘可以支持大约 500 个 28.8 Kbps 的连接。 在配置好服务器后,可以将 Windows Media Load Simulator 与性能监视器联用以检测瓶颈,如内存分页和处理器时间。如果服务器无法处理负载,就再增加一个硬件或服务器。 存储区域网络 如果管理吞吐量很快且可伸缩性至关重要的大型站点,IT 经理就可能需要考虑存储区域网络(SAN)。SAN 是专门进行存储的网络。它们以极高的速度将服务器与存储设备(如 RAID 磁盘阵列、磁盘驱动器和磁带驱动器)连接起来。除提供高带宽外,SAN 将所有的存储 I/O 分隔为独立的网络部分以便其他的网络通信不受其影响。 SAN 的底层网络基础设施称为光纤信道-仲裁环(Fibre Channel - Arbitrated Loop,FC-AL)。这是工业标准的高速接口,是专为双向、点到点的串行数据信道而设计的。它可以以 100 MB/s 以上的速度连接距离在 10 公里范围内的系统。 光纤信道支持多个协议(如 TCP/IP 和 SCSI)在同一电缆上并行运行。可以最多将 126 个节点连接到一个环中。支持 FC-AL 接口的硬盘驱动器有 Seagate 的 Barracuda 和 Cheetah 驱动器。要了解更多关于这些驱动器的信息,请访问:
服务器的性能调整有几种方法可以提高服务器的性能。它们包括:
禁用不相关服务 服务器上经常有一些未被使用的服务在运行。通常,当机器启动时它们会自动运行。这样的服务的一个例子就是许可证日志记录,它进行检查以确定应用程序的用户许可证是否是当前的。如果服务器是专门用于分发流媒体的,则没有任何理由保留这种服务的运行。另一个例子是打印后台打印程序。除非服务器作为后台打印程序使用,否则就可以关闭该程序。另外,对于高端性能,不要在运行 Windows Media Service 的同一服务器上运行 Microsoft Internet Information Service(IIS)。要将服务器专用于 Windows Media Server。如果 IIS 在同一台机器上运行,请考虑关闭其内容索引程序和 FTP 服务。索引程序需要大量的内存和磁盘空间,且有可能不使用 FTP 服务。总之,首先确定真正需要的服务并关闭其他无关的服务。 设置注册表键 有两种注册表键,当负载过重时,可以调整其数值以提高服务器的性能。使用注册表编辑器可以添加键值(如果键尚不存在的话)或修改设置。 MaxConnectionPerSecondKey 通过设置存放等待请求的队列大小,MaxConnectionPerSecond 注册表键控制服务器每秒可以处理的客户端连接请求的次数。处理客户端连接请求可以使用系统资源(CPU 周期和内存),且根据计算机硬件的配置,这可能影响服务器性能以及传送到客户端的媒体流的质量。 从客户端将连接请求发送到 Windows Media Server 时,请求将放在连接队列中并连续进行处理。如果客户端试图连接到服务器的速率超过用于处理这些连接请求的客户端连接速率,队列就将变满。每秒所处理的客户端连接请求数的默认值是 25,因为满足 Windows Media Server 最小系统需求的计算机每秒可以处理 25 个连接请求而不会影响传送到连接的客户端的流的质量。放在队列中的客户端连接请求数的数值是每秒客户端连接数的二十倍,或默认值 500。该数值之所以设置为连接速率的二十倍,是因为 Windows Media Player 被设置为在试图使用故障切换 URL 进行连接之前等待 20 秒。所有队列中的请求会在 20 秒的等待时间内得到处理。 服务器保留放在队列中的客户端的计数。当所允许的最大请求次数放在队列中时,服务器将停止侦听连接请求。任一试图连接的客户端将立即得到服务器不能访问的消息。每当发生这种情况,Windows Media 日志条目就将带有错误代码 503。Microsoft Windows 2000 Server 应用程序事件日志条目将带有下列消息:Windows Media 服务已达到最大的待定连接数值 %1。但是,仅当服务器停止侦听且在前一时刻日志条目还未记录时才记录该条目。其中,%1 是变量,而所显示的数值是队列的大小。然后,服务器每 2.5 秒检查一次以确定队列是否已满。如果客户端已处理并从队列中删除,则服务器再次开始侦听连接请求。 如果所用的计算机带有多个处理器和大量内存,则该计算机可能可以用于处理大量的连接。但是在决定增加该数值之前,建议您使用 Windows Media Load Simulator 仔细估算计算机的 CPU 和内存的使用情况。 要将服务器的连接速率设置为自定义数值,可以编辑必须进行更改的每个 Windows Media Server 的系统注册表。对于特定的硬件配置,如果连接速率过高或过低,则可以将注册表键 HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \nsunicast \Parameters \MaxConnectionsPerSecond 设置为自定义值。在高端服务器上,数值为 75,甚至有可能为 100。 MaxUserPort 默认情况下,当应用程序从系统中请求套接字以用于出站呼叫时,系统提供的端口值在 1024 和 5000 之间。MaxUserPort 参数设置可以用于出站连接的最高端口值。如果 Windows Media Server 将在大负载的情况下运行,则有必要提高上限值。要设置该数值,请定位到 HKEY_LOCALMACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters。如果该值尚不存在,则添加数值 MaxUserPort,并将其设置为 0xFFFE。 使用最新的 NIC 驱动程序 使用最新的 NIC 驱动程序很重要。将旧的驱动程序升级到最新版本可以大大提高性能。 服务器端口号在基于 TCP/IP 的网络中,端口号分配给在计算机中运行的应用程序。该编号将传入的数据链接到正确的服务。通用的端口是每个人均会使用的标准端口号,例如,端口 80 通常用于 HTTP 通信(Web 通信)。Windows Media Technologies 使用下列端口号:
可能需要配置防火墙来支持这些端口上的通信。对于那些打开非通用端口有问题的站点,Windows Media 也可以通过 HTTP 流动到端口 80。 端口号和分布式 COM 端口号和分布式 COM 分布式 COM(DCOM)为每个进程动态分配端口。必须确定要将多少个端口分配给 DCOM 进程,它等于通过防火墙的同步 DCOM 进程数。同样也需要打开端口 135,它用于远程过程调用(RPC)端点映射。除此之外,必须编辑注册表以通知 DCOM 您已保留的端口。可以使用 HKEY_LOCAL_MACHINES \Software \Microsoft \Rpc \Internet 注册表键来实现这一点,您可能需使用注册表编辑器创建该键。 下面的示例告知 DCOM 将其端口范围限制为 10 个端口: 指定值:端口 要了解更多关于端口号、防火墙配置和 DCOM 的信息,请参见:
服务器安全性问题这一部分讨论保证 Windows Media Server 的安全和保护内容的方法。可以使用两种身份验证方法中的某一种来保证服务器的安全。可以通过 Windows Media Rights Manager来保护内容。 单播传输的身份验证身份验证是指对访问服务器的人的身份进行验证。因为在客户端和服务器之间有点到点连接,所以单播传输将使系统对其进行身份验证。在客户端和服务器间没有直接连接的多播传输会引起另一个问题。多播的身份验证将在本书的后面进行讨论。 Windows Media Server 可以使用两种身份验证方法中的一种。它们是:
可以通过使用 Windows Media Administrator 在服务器属性下选择任一种方法。 匿名身份验证 这个选项可以通过选择不使用验证来进行选择,它是默认的。通过使用匿名身份验证,网络管理员可以指定匿名登录用户账户名(或接受 Netshow 服务的默认用户名),并输入账户密码。如果客户端的 Web 浏览器在请求 URL 时未提供用户名或密码,那么服务器将模拟匿名用户账户并试图访问资源。 通过使用匿名访问,IT 经理可以凭借不接受 NetShowServices 用户名而拒绝对特定文件的访问。为此,在文件上设置访问控制列表(ACL)。(参见本书后面的“使用访问控制列表”。)如果用户试图匿名访问 Windows Media 内容而 NetShowServices 账户却无读取该文件的特权,则需要用户进行登录。如果该操作被拒绝,则将拒绝他或她访问该文件。 基本身份验证 在使用基本身份验证时,系统会提示用户输入纯文本(未加密的)用户名和密码,然后进行 Base64 编码并将结果传送到服务器。服务器将根据目录数据库检查来用户名和密码,如果用户名和密码都正确,则服务器将模拟用户并试图访问资源。基本身份验证可以使用账户数据库中的信息,或者如果未安装账户数据库,则使用 Microsoft Site Server 成员资格账户中的信息。 注意: Base64 编码是加密级别最低的类型。虽然监视网络通信的人看不到实际的用户名和密码,但对其进行解密非常简单。老练到足以监视网络流量的任何人几乎都可以研究该算法并进行反向处理,从而解开纯文本用户名和密码,以便用其闯入 Web 站点。 应用身份验证包要应用身份验证包,可以按下列步骤打开 Windows Media Administrator:将鼠标指向“程序”,再指向“管理工具”,然后单击“Windows Media”。 “应用身份验证数据包”
使用访问控制列表 如果身份验证数据包是活动的,则 Windows Media Server 也允许您通过选择“启用访问控制列表(ACL)检查”复选框来启用访问控制列表(ACL)检查。访问控制列表是与某个文件夹或文件相关的条目的列表,它指定哪些用户或组可以访问该文件夹或文件。如果没有 ACL,所有的文件或文件夹都会要求身份验证。有了 ACL,就可以设置每个用户在各个文件或文件夹上的权限。 ACL 中的每个条目都为用户或组分配以下一个或多个文件访问权限级别:
也可以在文件夹上设置类似特权集:
要了解更多的信息,请参阅 Windows Media Administrator 帮助文件中的“限制对 ASF 流的访问”。 Windows Media Rights ManagerWindows Media Rights Manager 是数字权限管理应用程序,它允许内容编写者通过 Internet 以打包、加密文件的格式传送歌曲、视频或其他媒体。最终用户需要一个包含解密文件所需密钥的单独的许可证以使用 Windows Media Player 播放这些内容。 Windows Media Rights Manager 使用强大的数字权限管理加密方案。每个文件均是以加密格式存储的,且对于每台运行 Windows 操作系统的 PC 均是唯一的,这就使得要破坏许可证保护或复制文件变得很困难。这种基于 Windows 的 PC-by-PC 加密模式防止用户的文件不小心被盗。它也可以用来防止故意盗版。要了解更多关于 Windows Media Rights Manager 的信息,请浏览:
日志记录和服务器性能信息有各种工具可以记录客户端的日志信息以及评估和监视服务器的性能。这一部分将概述如下几个方面:
所有这些工具都有它们自己的扩展帮助文件。请这些帮助文件以了解更详细的信息可以查阅。 Windows Media Administrator 日志Windows Media Administrator 可以记录有关事件及连接到单播发布点的客户的信息。(有关记录多播问题的日志信息是一个难度较大的问题,我们将在多播部分中进行讨论。)默认情况下禁用日志记录。要启用日志记录,可以通过下列步骤打开 Windows Media Administrator:将鼠标指向“开始”菜单上的“程序”,再指向“管理工具”,然后单击“Windows Media”。单击左边菜单中的“服务器属性”,然后单击“发布点日志” 选项卡。下面的图 7 显示了一个示例屏幕:
图 7:启用单播日志记录 发布点事件日志显示客户活动的日期、时间和描述。下面的图 8 显示了该日志的一个示例:
图 8:负载模拟器发布点事件 Windows Media Administrator 发布点客户日志显示下列信息:
下面的图 9 显示了一个“发布点客”户对话框示例:
图 9:发布点客户日志示例 在这种情况下,因为数据是通过 Windows Media Load Simulator 和模拟多客户端的一个计算机进行收集的,所以客户端 IP 地址在任何情况下都相同。每个客户端都有一个随机分配的独立端口号。 日志文件条目可以按您选择的时间进行保存或一直保存直到文件达到指定的大小。文件按 W3C 标准格式保存。可以在记事本中查看这些文件,且 Windows Media SDK 包含用于分析这些日志的样本 Windows Script Host 脚本。另外,还有很多第三方产品可以用于阅读和解释日志。提供这种产品的公司有:
Windows Media 性能工具作为管理工具集的一部分,Windows 2000 操作系统包括一个专门显示与 Windows Media 技术性能有关的统计的监视器。要使用该工具,请将鼠标指向“开始”菜单上的“程序”,再指向“管理工具”,然后单击“Windows Media 性能”。 该工具如下面的图 10 所示:
图 10:Windows Media 性能工具 它与常用的性能监视器很相似,但它包含与流媒体相关的计数器。对于所存储的按需提供(On-demand)的内容尤其重要的一个统计就是 Late Reads 计数器。该数应为 0。如果不是 0,则说明磁盘响应正在恶化,无法满足要求。延迟读取(Late read)问题在服务诸如静态图像和 Web 页面的静态数据时很少出现,但是当服务实时多媒体内容时,数据必须即时可用。 Windows Media Load SimulatorWindows Media Load Simulator 包括在 Windows 2000 资源工具包中,也可从下列位置下载:
它运行在客户端机器上,并且在 Windows Media Server 上通过模拟大量 Windows Media Player 连接来测试 Windows Media 单播服务的容量。可以对脱机服务器进行峰值和压力测试。峰值负载是在正常情况下使用系统的最大客户数。压力测试则是逐渐增加超出峰值负载的客户的数量。 负载模拟器也可以监视联机 Windows Media Server,并可以将它配置为当服务器性能开始下降或服务器停止响应时自动向管理员报警。下面的图 11 是一个负载模拟器外观的示例:
图 11:Windows Media Log Simulator 下列日志所包含的信息可以帮助您解释使用负载模拟器运行的测试结果:
Windows Media Performance Monitor 还包含可以与模拟器一起使用的信息。要了解更完整的关于负载模拟器的描述,请参见名为“Checking Server Performance with Microsoft Windows Media Load Simulator”文章,其位置如下:
多播多播是将数据发送到用户组的一到多的传输形式。多播会节省网络的带宽,因为文件是作为单一数据流一直传输到最后一个跃点点,然后由路径终端的路由器将各个流发送到目标位置。 在Windows Media Technologies 所用的术语中,有一些是专门用于多播会话的。在讨论如何使用多播以及如何对多播会话进行疑难解答之前,我们将对其进行解释。 理解 Windows Media Technologies 多播术语在设置多播传输时使用以下三个术语:广播站、节目和流。 广播站用于通过多播传输分发内容(发布点用于单播传输)。广播站与电视台类似。广播站分发称为节目的内容,而节目一般由几个流组成。例如,节目可能使用插有广告的视频剪辑。要了解完整的关于使用多播和创建多播站的信息,请在 Windows Media Administrator 帮助文件中查找。 定义广播站 广播站在 an .nsc 文件中定义。这是一个配置文件,其中包含联接多播传输所需的全部信息,如 IP 地址、端口号及所需的 CODEC。Windows Media Server 根据配置多播站时所输入的信息创建 .nsc 文件。 .nsc 文件是必需的,因为用户在节目开始时并不一定要联接多播传输。他们可以在任何时候成为多播组的成员,这意味着 Windows Media Player 立即开始接收流数据,而无需包含传输信息的头文件数据包。Windows Media Player 使用 .nsc 文件获取信息。 管理员一般可以通过电子邮件将文件发给加入组的用户或者通过 Web 站点发布文件。这意味着,即使 Windows Media 服务器创建文件,它也不分发文件。让管理员控制 .nsc 文件的分发有助于阻止未经授权的用户侦听传输。例如,通过在 Web 站点上发布文件,管理员可以在许可访问信息之前要求进行身份验证。 .nsc 文件可以包含内含编码器配置的 .asd 文件的名称。如果未使用模板中的 Windows Media Encoder 默认值,则在创建多播站时必须指定该文件。如果更改了任何默认值,则可以保存 .asd 文件,将其复制到服务器,然后在配置多播传输时指定该文件。这一切均在“指定流格式信息”对话框中进行。Windows Media Administrator 将信息存储在 .nsc 文件中。 配置多播站 这一部分将向您介绍定义多播会话广播站的过程。 定义多播会话的广播站
记录用户信息 在使用多播时,服务器和用户之间没有直接通信。这使得收集有关谁在侦听以及网络连接到指定客户端的质量的信息变得困难。为帮助解决这个问题,Windows Media Player 引入了用于多播传输的日志记录功能。它们是以 ISAPI DLL 实现的,ISAPI DLL 称为 Nsiislog.dll,运行在 IIS 服务上。为启用日志记录功能,请遵循下列步骤(默认情况下禁用该功能):
要了解更多关于启用日志记录的信息,请参见 Windows Media Administrator 帮助文件。 一般来说,统计归入以下三种类别之一:传输质量、内容信息和客户端信息。传输质量统计的示例:
内容信息的示例包括:
嵌入的 URL 是 Web 页面的 URL,该页面中包含嵌入式 Windows Media Player。通过了解该 URL,可以发现谁在使用您的内容。 客户端信息的示例包括:
多播的其他应用 多播可以用于分发除 .asf 文件之外的其他文件。不管是什么时候,只要是需要将数据的单一流发送到多个用户时,都应该考虑使用多播以节省带宽。(这里假定网络可以支持多播。例如,如果网络包含一个 LAN,或如果网络设备(如路由器)支持多播,即属于这种情况。)常见的例子是使用 Windows Media Technologies 多播通过网络来发送 Microsoft PowerPoint 演示文稿,但是它也可以用于其他类型的文件、文件目录。要配置多播文件传输,请选择 Windows Media Administrator 所显示的多播文件传输 选项。您还可以设置各种参数,其中包括:
要了解更详细的信息,请参见 Windows Media Administrator 的帮助文件。 多播传输疑难解答 虽然有关多播会话的疑难解答的完整指南并不在本书的讨论范围之内,本节还是包括一些建议,以便使您的任务更简单。同样,虽然在本书中未进行讨论,但对于单播还是有一些与多播类似的统计。要了解更多关于日志记录功能的信息,请参见 Windows Media Administrator 的帮助文件。 检查文件 首先,确保 asx 和 .nsc 文件可访问且不包含任何错误。没有这些文件,客户端将无法联接多播。切记:如果未使用编码器的默认模板,或如果对任何值进行了更改,则必须指定 .asd 文件。如果在配置完多播后对编码器进行了任何更改,则必须重新指定该文件以保证 .nsc 文件为最新的。如果在配置多播之后服务器配置的任何内容发生更改,则可以重新导出 .nsc 文件。为此,在“Windows Media 管理器”上选择“多播站”,然后选择“导出”。 “检查统计” 在传输过程中,可以使用 Windows Media Player 检查统计。为此,右键单击“Windows Media Player” 并单击 “统计”。下面的图 26 显示了一个示例:
图 26:Windows Media Player 统计 确保“协议”设置为“多播”。选中 “恢复的数据包”和“丢失的数据包”以查看当前是否丢失数据库。如果恢复的数据包数计数器在递增,则 Windows Media Player 正在重构丢弃的数据包。这可能是网络出现问题的迹象。(这些统计对于单播也可以使用。) 如果在配置多播会话时启用了日志记录,则在会话结束后可以使用 Nsiislog.dll 日志来获取详细信息。要尽力找到问题的趋势,如许多用户在某一段上均有问题。 跟踪 IGMP 版本 请注意不同版本的 Windows 操作系统实现不同版本的 Internet 组管理协议(Internet Group Management Protocol,IGMP),客户端使用该协议来联接多播会话。下表总结了 Windows 各个版本所使用的 IGMP 的版本:
隔离问题 除非通过一个 LAN 进行多播,否则多播一般涉及多个子网和路由器。请从服务器驻留与移动的位置开始,通过网络逐个跃点隔离问题。另外,确保生存时间(TTL)值足够高以使数据包能够通过必须遍历的每个跃点。一般说来,TTL 应与跃点数相等。如果该数过低,则数据包将在到达网络边缘之前被丢弃。默认值是 5。要设置跃点数,可以单击“配置服务器”,然后单击要编辑的广播站。系统将打开下面的图 27 所示的 “配置服务器 – 编辑广播站” 对话框:
图 27:更改 TTL 参数 将 TTL 条目的值更改为更高的值。 最后,查看防火墙或任何非多播启用的设备,它们有可能阻止向网络某些段中进行的传输。如果数据包必须经过的路由器或交换机不理解多播,则数据包将被丢弃。另外,如前所述,许多防火墙无法通过 UDP 数据包,它是用于多播传输的传输。 有许多第三方监视工具可用于检测网络问题,而且 Windows 2000 操作系统本身也包含一些工具。我们将简要讨论两个工具:网络监视器 和 tracert 工具。 网络监视器 Windows 2000 Server 袖珍版及 System Management Server 中的网络监视器允许您查看网络上的数据包。要使用网络监视器,请将鼠标指向“开始”菜单上的“程序”,再指向“管理工具”,然后单击“网络监视器”。 网络监视器如下面图 28 所示:
图 28:网络监视器 网络监视器通过将捕获主机的 NIC 置于 混合(promiscuous) 模式中进行工作,这样它就可以将在线路上所看到的每一帧传递到跟踪工具。可以定义捕获过滤器只保存特定的帧以便分析。可以根据源和目标 NIC 地址、源和目标协议地址以及模式匹配对这些过滤器器进行配置。在获取捕获后,可以使用显示过滤来进一步缩小问题的范围。显示过滤还允许选择特定的协议。要了解更多关于使用网络监视器的信息,请查询相关的帮助文件。 Tracert 工具 tracert 工具通过将数据包组连续发送到特定目标——所需要的目的计算机的 IP 地址运行。例如,如果要跟踪从您的机器到 whitehouse.gov 的路由,可键入:tracert whitehouse.gov。路径上的每个路由器将信息返回到启动跟踪的机器,向用户显示接收数据包的机器的 IP 地址以及每个数据包往返的时间(按毫秒计)。跟踪完成后,您就会知道数据包从源到目的地所需的跃点数以及每个跃点所占用的时间。 Tracert 操作的重要组件是数据包的 TTL(生存时间)数值。Tracert 将三个数据包组连续发送并不断增大 TTL 数值。沿着路径,每个路由器将 TTL 数值减 1,然后将它传递给下一个路由器。使用 TTL 为 1 发送第一个数据包组。第一个跃点的路由器将值减为 0,这导致数据包到期,并将到期信息发送回源机器。然后第二个组按 TTL 为 2 发出,第二个路由器而非第一个路由器返回到期信息。这将一直持续下去,直到达到最大的 TTL 数值,或者在理想情况下,目的计算机接收到数据包。Tracert 工具的默认最大 TTL 数值为 30,即可以报告前 30 个跃点。您也可以通过使用 -h 选项来增加该数值(在列表选项的命令行上仅输入 tracert)。 Tracert 会话的示例如下面图 29 所示:
图 29:Tracert 会话样本
要了解更多关于 tracert 的信息,请参见 Windows 2000 帮助文件。 负载平衡负载平衡跨服务器阵列分发所处理的负载,从而没有一个服务器在工作中首当其冲。它同时还可能提供故障转移功能,以便将负载从失败的服务器转移到另一个功能正常的服务器。有几种方式可以实现负载平衡。它们包括:
DNS 循环法DNS 循环法的工作方式是通过整个 IP 地址列表而非一个 IP 地址来应答 DNS 查询。执行查询的 Windows Media Player 通常选择第一个 IP 地址并在连接持续时间引用该服务器。要确保不反复选择同一个 IP 地址,则列表需要进行循环以便每次不同的 IP 地址出现在列表顶端。 举一个例子,假设我们有三台服务器,其名称和 IP 地址分别是:
要设置服务器以便于客户端请求通过循环法循环,可以使用多个 A 记录。(这些 DNS 记录将主机映射到 IP 地址。)在示例中,我们之所以让访问该站点的所有客户端都使用 example.microsoft.com 名称,仅仅是因为这些请求在三个服务器间是共享的。我们将 A 记录设置如下:
在每个 A 记录中,example.microsoft.com 名称末端的英文句点是强制性的,因为没有后缀点的名称有时被解释为与一些域关联而非与根目录关联,这就像没有前导斜杠的目录名经常被解释为与当前目录关联一样。后缀点表明域名是绝对的,这意味着它被编写为与根目录关联。我们的示例中的 TTL 域通知名称服务器 60 秒钟后将这些项从名称缓存中删除。这可以确保不将记录在不支持循环法的中间名称服务器上缓存过长的时间。 DNS 循环法的优势和局限 DNS 循环法的主要优势是简便且自由。添加记录时服务器池似乎为一个服务器,而事实上请求在池内的所有主机中循环进行。第一个局限是循环法实际上既不是负载共享技术也不是负载平衡技术。实际的负载平衡解决方案测量服务器上的负载,并判定发送客户请求的位置以便于平均分发工作。循环法不对服务器负载进行任何测量——它只是在多个主机间交替执行客户端请求,而不管服务器的能力如何。一个或多个主机可能会比其他主机获得更多的活动。第二个局限在于,如果一个服务器停机,来自客户的请求还会转到该 IP 地址,这些客户将无法接收到正确的响应。 Windows 负载平衡服务Windows 负载平衡服务 Windows 负载平衡服务(Windows Load Balancing Service,WLBS)允许传入的 IP 流量动态地在多个服务器间进行分发。WLBS 透明地在主机间分发客户端请求并让客户端使用一个或多个虚拟 IP 地址的访问池。从客户端的角度来看,池似乎是应答这些 IP 地址的唯一服务器。顾客经常询问对 Windows Media 应该使用 WLBS 还是 Microsoft 群集服务(Microsoft Cluster Service,MSCS):答案是使用 WLBS。如下面所讨论的,MSCS 用于数据密集型的应用程序,如 Microsoft SQL Server。 WLBS 服务器在它们之间进行通信以提供下列信息:
您可以在多个服务器(筛选为单一关系、没有关系或 C 类)上将 WLBS 配置为负载平衡。Windows Media Server 服务器的最佳选择(非无状态应用程序)是单一亲缘关系。当配置为单一关系时,所有使用 WLBS 虚拟 IP 地址传入的数据包锁定到 WLBS 群集中的指定节点。从使用该群集 IP 地址的客户端发送的每个数据包均连接到该节点。 Microsoft 群集服务(MSCS)MSCS 与数据密集型应用程序(如 SQL Server 和 Microsoft Exchange Server)一起使用。它不应用于负载平衡 Windows Media 服务。但是,可以将 WLBS 和 MSCS 技术一起使用以便为整个站点提供高度的可伸缩性和可用性。例如,数据库驱动的站点可以在 MSCS 群集上放置其数据库,MSCS 群集由 WLBS 群集的 HTTP 和基于 Windows Media 的服务器访问。该配置在数据库层提供高度可用性,在 Web/HTTP 层提供高度可伸缩性和可用性。 Windows Media Player HTTP 错误消息在 Windows Media Player 运行时可能发生的网络错误消息是标准 HTTP 1.1 状态码,它在 RFC 2068 中定义。可以从下列位置获取:
最常见的代码是服务器错误消息,这些消息在 5xx 范围内,代表服务器发出已出错或无法处理请求的情况。这些代码如下表所示:
其他信息要了解更多关于 Windows Media Technologies、软件下载、以及指向涉及创建和部署内容的文章的链接的信息,请参见正式的 Windows Media Technologies web 页面:
还有一些公共新闻组,可供用户订阅。它们是:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
上一篇: 下一篇: |