用Windows Media搭建流媒体系统

宽带视频的发展使流媒体服务器的部署不再仅仅是几大运营商的专利（如视频点播和广播业务），中小企业也开始搭建企业网的内部多媒体通信环境或者商用流媒体系统。Windows Media 是一种通过 Internet 向客户端传输音频和视频内容的平台，它的设计目的是为了协同工作，以提供最佳的数字媒体体验，目前这一技术被广泛地应用于流媒体系统。

Windows Media的设计目的是为了协同工作，以提供最佳的数字媒体体验。目前这一技术被广泛地应用于电信运营商及ISP宽带网络上的视频点播和广播业务以及企业网的内部多媒体通信环境。

Windows Media Services 是一种通过 Internet 或 Intranet 向客户端传输音频和视频内容的平台。客户端可以是使用播放器（例如 Windows Media Player）播放内容的其他计算机，也可以是用于、缓存或重新分发内容的运行 Windows Media Services 的设备（称为 Windows Media 服务器），还可以是使用 Windows Media 软件开发工具包 (SDK) 开发出来的自定义应用程序。

Windows Media 服务器流式传输给客户端的内容可以是实时流，也可以是预先存在的内容，例如数字媒体文件。如果计划传输实况内容，则服务器将连接到能够以服务器支持的格式广播实况流的编码软件（例如 Windows Media 编码器）。

在Windows Media 平台中，包括了下列软件包:

Windows Media Services （ 媒体播放服务器）――将流媒体到计算机网络上;

Windows Media Player（媒体播放器）――全功能的网络多媒体播放软件;

Windows Media Encoder（编码器）――将源音频和视频转换成可以下载或进行流传输的数字媒体;

Windows Media Right Manager（数字版权管理服务器）――一个保障安全数字媒体文件的DRM系统;

Windows Media SDK（软件开发包）――提供创建使用Windows Media技术的自定义程序和Web页面的详细信息;

Windows Media Producer――用于PowerPoint的多媒体演示创建工具。

部署Windows Media

基于 Windows Media 技术的流媒体系统一般都包括运行编码器（如 Windows Media 编码器）的计算机、运行 Windows Media Services 的服务器和大量运行播放器（如 Windows Media Player）的客户计算机。编码器可将实况的和预先录制的音频、视频内容转换成 Windows Media 格式。Windows Media 服务器通过网络来分发内容，然后播放器接收内容。

图1 典型的播放流程

在典型方案中，用户单击网页上的链接来请求内容，然后 Web 服务器将请求重定向到 Windows Media 服务器，并启动用户计算机上的播放器（如图1）。此时，Web 服务器不再参与流式媒体传输过程，这是因为 Windows Media 服务器与播放器建立了直接连接并已开始将内容传输给用户。

Windows Media 服务器可从多种不同的源接收内容（如图2）。预先录制的内容可以存储在本地服务器上，也可以从联网的文件服务器上提取。实况事件则可以使用数字录制设备记录下来，经编码器处理后发送到 Windows Media 服务器进行广播。Windows Media Services 还可以重新广播从远程 Windows Media 服务器上的点传输过来的内容。

图2 不同的内容源

典型的内容通过以下的方式来实现:

在网页中内嵌一个播放列表文件或信息文件链接，如asx / wsx / nsc格式的文件;

用户点击播放列表文件后将其下载，浏览器根据MIME类型启动媒体播放器;

媒体播放器读取播放列表文件，根据播放列表文件中的URL连接到媒体服务器进行播放。

播放列表（Playlist）通常是带有 .asx 文件扩展名的 Windows Media 元文件，该文件为播放器提供在连接到 Windows Media 服务器接收内容时需要的信息。播放列表文件是基于扩展标记语言 (XML) 的，它使用不同的标记来控制播放机的行为。.asx 扩展名注册在 Windows Media Player 上，因此用户单击播放列表文件时播放器将自动启动。

下列代码示例是最基本的播放列表文件类型，它仅将播放器定向到内容的位置:

< asx version = "3.0">

< entry>

< ref href = "mms://servername/publishingpointname/filename.wmv"/>

< /entry>

< /asx>

这里的URL是mms://servername/publishingpointname/filename.wmv，媒体播放器根据这个地址在媒体服务器上取得内容进行播放。

nsc文件是用于组播时的信息文件格式，组播播放列表向导可创建播放列表文件和多播信息文件。组播信息文件包含播放器对流进行解码时需要使用的信息。在接收以组播流方式传递的内容之前，媒体播放器必须访问组播信息文件以提取下列信息:

组播 IP 地址；

组播端口；

生存时间值；

默认纠错跨度；

组播日志记录 URL；

单播替代 URL；

正在传递的内容使用的流格式。

wsx文件也被称为Server-Side Playlists，不同于asx文件，wsx文件提供的媒体播放控制是由媒体服务器来进行控制的。这一功能的实现必须要基于RTSP协议来完成。wsx文件基于SMIL语言写成，因此可以提供更多的图形同步演示、用户交互、广告插入等功能。下面给出了一个实际的wsx文件示例:

< ?wsx version="1.0"?>

< smil>

< media src="racecar_300.wmv"/>

< media role="Advertisement" noSkip="TRUE" src="encoder_ad.wmv"/>

< media src="snowboard_300.wmv"/>

< media src="industrial.wmv" />

< /smil>

wsx文件可以由动态网页如ASP和CGI程序动态的生成，所以，媒体服务器可以根据用户的输入条件动态地响应并生成wsx文件，通过这种方式动态地产生媒体播放内容。目前NetCache无法对wsx文件和其中的媒体内容进行缓存，而只能作为将用户的请求发送回源服务器处理。

图3给出了wsx文件动态创建的一个流程示例。

图3 WSX文件动态创建流程

图中第3步中，客户端按照html网址中的内容向Content Distributor(媒体服务器)请求得到playlist.wsx文件内容; 然后进行第4步，媒体服务器将用户信息传送给Ad provider(广告提供商)，广告提供商根据用户的信息生成wsx文件，可能是通过ASP动态生成的，然后传递给媒体服务器，最后媒体服务器将wsx文件传送给客户端。

和缓存

Windows Media 9服务器通过增加由SDK创建的和缓存插件，可以作为WM（Windows Media）的或缓存设备来使用。因此也可以利用WM9来创建一个专门为Windows Media使用的CDN （Content Delivery Network,即内容分发网络）网络。

当客户端请求点播内容时，WM9 缓存/插件验证所请求的内容是在本地缓存并且是当前的，要实现这个目的，插件会首先检查内容的缓存过期属性。如果将内容设置成经过一段特定时间后过期，那么在这段时间过后，插件将请求缓存/服务器打开一个到源服务器的连接，并验证缓存中的内容与源服务器上的内容是否匹配。如果内容匹配，则缓存命中; 如果内容不匹配，则缓存未命中。如果源服务器不可用或不能提供请求的内容，则服务器会向客户端返回一个错误信息，声明该内容找不到。

如果缓存命中，则插件请求缓存/服务器将内容从其缓存传输给客户端（如图4）。

如果缓存未命中，则内容将被从缓存中清除，然后缓存/服务器再从源服务器下载更新的内容。缓存/服务器会启动另一个到源服务器的连接，以便作为服务器来将内容传递给客户端。这里需要注意的是缓存/服务器实际上打开了2个到源服务器的连接，同样一份内容要被2个不同连接下载，一个用于，一个用于存储到本地缓存（如图5）。

除了上面的处理方式以外，缓存/服务器还可以执行如下的动作:

拒绝用户对此内容的访问;

重定向用户的请求到另外一个URL（http 302）或Proxy（http 305）;

从源服务器下载这个内容到本地缓存;

只对用户的请求进行。

如果在缓存/服务器试图传输多比特率 (MBR) 内容时发生了缓存未命中，则缓存/服务器将立即从源服务器下载所有不同比特率的流。如果对源服务器或缓存/服务器上的带宽设置了带宽限制，则多比特率流需要的总带宽可能超过这一限制。如果这样，缓存/服务器将无法将内容下载到其缓存中，并且只能以客户端请求的带宽来传输内容。

Windows Media 服务器上安装了缓存/插件后，可以使WM9服务器能够通过其他 Windows Media 服务器来源服务器中的实况流。客户端请求一个实况流时，缓存/插件将检查缓存/服务器是否已了这个流。如果服务器没有该流，则插件将请求缓存/服务器打开到源服务器的连接。建立了源服务器的连接后，缓存/服务器会将内容从源服务器传输给客户端。如果缓存/服务器了该流，那么插件将请求服务器拆分该流，以便所有发出请求的客户端都能接收到内容。这样，缓存/服务器和源服务器之间只需建立一个连接。由于实况流没有与之关联的文件，因此内容不缓存。

Windows Media 缓存/服务器能够缓存Sever side playlist（wsx）。wsx文件中可能包含多个内容项，但是服务器在做新鲜性检查时无法对其中的每个内容对象进行检查，而只是针对wsx文件作新鲜性检查，如果发现过期，则会将整个文件中的内容更新。

另外需要指出的是，Windows Media缓存/服务器下载内容到本地缓存时，必须将内容下载完毕后才能够播出，而不能像NetCache一样下载一部分也可以播出。因为WM9使用的下载Plug-in On DownloadContent Progress不支持部分下载功能。

WM9 源服务器和缓存/服务器之间会有事件的通知，可以被源服务器用于日志记录等应用。可以记录的事件有如下三种:

WMS_EVENT_REMOTE_CACHE_

OPEN:表示一个客户机在缓存/服务器上打开了连接;

WMS_EVENT_REMOTE_CACHE_

CLOSE:表示一个客户机在缓存/服务器上关闭了连接;

WMS_EVENT_REMOTE_CACHE_

LOG：提供客户机和缓存/服务器上的日志信息，在客户端播放完后将播放的日志信息再送回源服务器，LOG信息会详细记录客户机的播放情况。

负载均衡策略

配置了缓存/插件的WM9服务器可以作为反向服务器来使用，也可以进行简单的负载均衡功能。但是它没有提供GSLB（整体负载均衡）功能，因此如果构建电信级的CDN时还需要额外的硬件来实施GSLB。

微软的WM9的负载均衡策略有下面两种:

基于硬件的负载均衡: 也称为反向，此方法依赖于网络中位于服务器群集和客户端之间的服务器。反向服务器接收客户端的流请求，然后将客户端重定向到适当的服务器(L7 Redirection)，或者为客户端该服务器中的内容。为避免创建单个的故障点，可以同时使用两个或多个反向计算机。

基于软件的负载均衡: 基于软件的负载均衡产品，例如 Microsoft Network Load Balancing，将一定比例的服务器总负载分配给群集中的每一个节点。负载均衡软件在群集的每一个节点上运行，并根据每一台服务器承担的总工作负载的百分比来计算出下一个接受新请求的节点。微软的2003 服务器操作系统最多支持32台服务器群集。

如果在使用反向时涉及到用户认证问题，反向服务器会将认证信息送往源服务器进行认证。此时在反向服务器上，需要运行一个脚本，如下面所示。 在此脚本中，password 是要用来验证源服务器的密码，user_name 是用户名。

Dim server

Set server = CreateObject("WMSserver.Server")

Dim pp1

Set pp1 = server.PublishingPoints.Item("Cache/Proxy Broadcast")

pp1.DistributionPassword = "password"

pp1.DistributionUserName = "user_name"

WM9 SDK并没有提供任何关于内容推送的功能（微软的名词为PRESTUFF），因此如果要构建具有内容推送功能的CDN网络必须进行额外的软件开发。

安全特性

WM9提供了一系列的特性来进行媒体播放的安全控制，它包括:

* 用户身份认证;

* 用户授权;

* 通过SDK编写定制插件的认证和授权控制;

* 数字版权管理 （DRM）。

如果通过WM9构建电信级的商业视频网络，比较适合的具有扩展性的方案是DRM和定制插件。

1．身份认证

身份认证是保证运行 Windows Media Services服务器的安全性的最基本方面，它将对试图访问Windows Media服务器资源的任何用户进行身份确认。Windows Media Services的身份验证插件与授权插件协同工作，在对用户进行身份验证之后，授权插件将控制对内容的访问。

Windows Media Services身份验证插件分为下列几个类别:

匿名身份验证

此类WM9认证插件不在服务器和播放器之间交换请求与响应信息，即用户不需要输入密码和用户名。当用户访问服务器或点时，服务器首先尝试通过匿名身份验证插件对用户进行身份验证，如果该尝试失败或者匿名身份验证插件没有启用，那么服务器就尝试使用网络身份验证插件对用户进行身份验证。

如果播放器是通过 HTTP 进行连接的，那么每当用户停止、暂停、快进或者倒回内容时，播放机都会断开与服务器的连接。如果用户尝试继续接收内容，则身份验证和授权过程将再次进行。

协商身份验证

如果希望用户能够基于他们的网络账号访问内容，则可以启用WMS 协商身份验证插件。此插件使用加密的请求/响应方案对用户进行身份验证。这是一种安全的身份验证形式，因为用户名和密码不直接通过网络发送。播放器通过与 Windows Media 服务器进行加密信息交流来确认密码，它使用 NTLM 或 Kerberos 身份验证方法对其进行验证。

此种认证方式较适合对各种微软操作系统上的用户进行身份验证。NTLM 身份验证是 Microsoft Windows NT Server 4.0 中的默认身份验证方法; Kerberos 身份验证是 Microsoft Windows 2000 Server 和 Microsoft Windows XP 操作系统中使用的默认身份验证方法。 因此这种形式的身份验证适用于需要支持多种 Windows 客户端并为机密内容提供保护的 Intranet 站点。

摘要式身份验证

此种认证方式是基于 HTTP 身份验证方案，它不会在网络上直接发送密码，相反，该插件使用以哈希算法加密的密码对用户进行身份验证。此方法比基本身份验证更安全，但不如 NTLM、Kerberos 或其他私钥身份验证方案安全。

当客户端通过外部网络 (如 Internet) 进行连接，并且内容提供者希望提供起码的用户身份验证时，适宜使用 WMS 摘要式身份验证。

摘要式身份验证方式使用域标识，通过对比 Microsoft Active Directory 域来验证用户身份。因此要使用 WMS （Windows Media Services）摘要式身份验证插件，则必须把 Windows Media Services服务器配置为 Microsoft Active Directory 域的一部分。

2． 授权

身份验证是对尝试连接到服务器的客户端的账号进行验证的过程。此过程包括从客户端向服务器发送凭据，以及使用身份验证方案识别用户。 授权是验证是否允许客户端连接到服务器的过程，授权在身份验证成功之后进行。在授权过程中，服务器对照为用户试图连接的资源设置的访问权限对用户进行检查。例如用户使用NTLM域账号进行点播，授权插件会检查此用户账号是否有权限访问媒体文件，如果有则会进行播放。

WM9通过授权插件来控制已通过身份验证的用户对内容的访问。如果WM9服务器启用了授权插件，那么就还要启用身份验证插件以便用户能够访问点。如果此时不启动身份验证插件的话，用户连接会被拒绝。但其中的一个例外情况是，WMS IP 地址授权插件则不需要身份验证插件即可对播放机进行身份验证。