一种高效流媒体电影服务器的设计

　　1　引言

　　随着网络技术的发展，主干网与宽带网接入技术的日臻成熟，网络视频的传输成为 Internet应用的一个亮点。为了提高视频数据在网上的传输效率，并实现视频的实时播放，流媒体技术的研究与应用得到了很大发展。

　　其中，流媒体服务器技术在流媒体的应用中发挥了关键的作用。

　　传统的网络传输数据的方法是文件下载：用户需要准备大量的磁盘空间，并花大量的时间等待下载结束。但是，当数据变成海量的视频数据时，在数据处理量大，数据吞吐量高，视频播放实时性，客户连接请求数目大，连接时间长等一些情况下，传统的服务器技术已经无法高效的满足要求。面对这样的技术要求，本文从 CPU调度，资源控制内存分配，I／O总线管理这三个方面出发，综合的给出了一种高效的服务器设计方法，从而有效的提高了视频流式传输时的效率。该方法也具有很强的可扩展性，当服务器的CPU数目增加时，服务器的性能将能得到成倍的增长。

　　2　流媒体服务器的设计

　　2．1　流媒体服务器的功能

　　流媒体在播放前不是完全下载整个文件，而是把开始部分内容存入内存，数据流是随时传送随时播放。

　　流媒体服务器提供的流式传输方式有两种：顺序流式传输和实时流式传输两种方式。顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体。实时流式传输与顺序流式传输不同，实时流式传输总是实时传送，特别适合现场事件。实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差。

　　在流式传输时，流媒体数据具有实时性，等时性等基本特点，流服务期和客户终端要保证各种媒体间的同步关系，因此，流媒体传输对“最大延时”，“延时抖动”等QoS参数都有严格要求。

　　2．2　流媒体服务器协议栈的设计

　　在TCP／IP参考模型中，传输层通信协议TCP和UDP都不能满足流媒体传输的QoS要求。由于TCP协议采用滑动窗口控制机制，数据传送随着流控窗口动态的启动和关闭，难以满足流媒体实时和等时的传送要求。UDP协议的无连接特点能够提高传输速率，虽然可以在某种程度上满足流媒体的实时性要求，但是由于其本身的不可靠性，也无法满足流媒体传输的需要。

　　针对传输层协议的矛盾，为了实现流媒体在IP上的实时传送播放，设计流媒体服务器时需要在传输层协议（TCP／UDP）和应用层之间增加一个通信控制层。在增加的通信控制层，采用相应的实时传输协议，主要有：数据流部分的实时传输协议RTP（Real－time Transport Protocol），用于控制部分的实时传输控制协议RTCP（Real－time Transport图1　流媒体服务协议栈Streaming Protocol）。RTP协议主要是用来传送实时的流媒体信息，数据报主要包括多媒体数据，以及所携带负载的时间戳，顺序号等。RTCP协议的数据报主要包括了接收者收到某个多媒体流的服务质量信息，用于对服务器端的反馈。

　　流媒体服务器的协议栈如图1所示。

　　当服务器收到RTSP请求，它首先产生RTSP请求对象。服务器通过RTSP协议的应答信息将请求的内容以流会话（streaming session）的形式描述，内容包括数据流包含多少个流、媒体类型、和编解码格式。一个流会话由一个或多个数据流组成，如视频流和音频流等。实际的数据流通过RTP协议传递到客户端。RTP在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP本身并不能为顺序传送数据包提供可靠的传送机制，它依靠RTCP一起提供流量控制和拥塞控制服务。在RTP会话期间，各连接者监视下层网络的性能，并将相关信息放入RTCP包，周期性地传送 RTCP包来通知发送方。发送方也可以用RTCP包提供每次的会话信息，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，因有效的反馈和最小的开销使传输效率最佳化。

　　流媒体服务器的功能框图如图2所示。

2．3高效流媒体服务器的设计

　　通过流媒体服务器的协议栈的设计，可以明确流媒体服务器是在传输层协议（TCP，UDP）上解释RTP，RTCP，RTSP协议的，所有的客户连接请求都是以TCP的端口获得的，流媒体数据也都是打成RTP包，通过UDP端口发出去的，因此，对于TCP，UDP端口事件的调度以及如何把大量的流媒体数据从磁盘空间传递到网络上成为制约流媒体服务器性能的主要因素。

　　流媒体服务器面对一个单一的客户，完成的过程如下：

　　1）在客户端发出RTSP连接请求后，服务器通过对TCP端口的监听，读入请求。

　　2）解析请求内容，调入相应的流媒体文件。

　　3）形成RTP包，分发数据流包，获得RTCP包。

　　4）数据包发送完毕，关闭连接。

　　上述过程如果采用传统的服务器设计方法实现，一般的办法是用一个线程不断的读入用户的连接请求，然后将这些请求分派给其它的工作线程，这些工作线程则分别循环往复的完成以下的工作：

　　1）解析请求内容。

　　2）发送RTP包，发送接收RTCP包

　　3）判断数据发送完毕，关闭连接。服务器的结构如图3所示。

　　操作系统在对流媒体服务器的功能实现上采用以应用进程（线程）为中心的系统资源管理方式。操作系统采用虚拟内存方式，应用程序的虚拟内存空间映射到物理内存，物理内存与CPU之间有Cache。当流媒体数据从磁盘上到网络上进行传递时，要在不同的系统空间中进行多次传递拷贝，如图4所示。

　　图4显示了磁盘数据到网络接口的传递路径：首先，数据对象从磁盘拷贝到内存中，然后，数据在内存中由于每个工作线程的空间不同，进行空间拷贝，即从核心空间拷贝到进程空间，接着，数据再从进程空间拷贝到核心空间，最后数据再拷贝到网络上。由于流媒体数据要经过RTP的打包处理，因此，数据在拷贝到网络上之前，还要拷贝到Cache，再从Cache中拷贝到CPU寄存器，进行打包处理。

　　从图3可以看出，随着工作线程数n的增大，系统在各线程之间的切换开销将急剧增加，从操作系统的角度来看，由于每个线程都涉及对硬盘视频数据的读取，各自独立的线程越多，对硬盘读写的数据量就越大，数据在不同空间的拷贝增加，操作系统将不断的进行页面切换，服务器的性能随着客户连接数的增多，效率将急剧下降。

　　为了改善上述设计的缺点，需重新设计服务器的服务程序结构。根据服务器在流媒体传输中所要完成的功能，可以看出，服务器在客户有连接请求时，解析连接请求和关闭连接请求是很短的过程，服务器的大部分时间都用于给每个客户发送RTP数据流包。发送RTP数据流包包括服务器把相应的媒体文件调入内存，打包发送，以及获得RTCP包的反馈。因此，可以设计一个单独的处理线程，专门用于给客户发送RTP的数据流包。

　　改进的流媒体服务器设计如图5所示，完成主要的功能通过两个线程来实现。

　　事件线程负责检测客户连接，以及客户发的RTCP包的到来。事件线程通过对TCP端口的检测，在有连接请求时建立可维护客户信息的RTSP会话，在每一个客户的RTSP会话的存活期内，事件线程不断的把向客户发送RTP包这一任务放入处理线程的队列，直到RTSP会话终止，事件线程再把关闭连接的任务放入队列。

　　事件线程把对不同客户的服务（发送RTP数据包）以任务的形式放入队列后，处理线程对对列中的任务依次进行处理，也就是说，处理线程根据客户的不同，不断的把相应的流媒体文件形成RTP包，依次发出，直到视频服务的终止。

　　可以看的出来，处理线程虽然对所有的客户提供服务，但是执行的任务始终是发送RTP数据流包，同时，该线程所访问的媒体文件被调入内存后，可以被同一线程的其它任务重复调用，这样的设计，不但减少了随着客户数增加而造成的系统频繁切换的资源损失，也减少了访问硬盘数据的次数，缩短了访问时间，也发挥了指令局部性效率提高的优点。设图5　改进后的处理流程计中，解析客户的连接请求也放入处理线程的队列中，在处理线程中进行处理，虽然解析连接的任务不同于大部分发送RTP包的任务，但是该任务消耗时间少，所以对对系统性能的影响并不大。

　　采用图5的设计方法，服务器还可以根据客户端反馈的RTCP包得知客户端的网络状况，采取一定的策略针对不同的客户网络质量进行RTP包发送任务的调度，对于带宽质量好的客户，事件线程可以多放一些RTP包到队列中；对于由于网络质量造成的即将超时的客户连接，服务器也可以通过任务调度的方式进行特殊处理，最大限度的提供不同质量的客户连接服务。

　　上述的设计是在硬件具有一个CPU的情况下，当系统硬件具有的CPU个数为n时（n＞1，事实上做为流媒体服务器的硬件需求，一个CPU是远远不能满足系统需求的），程序将采用n个处理线程来分担事件线程调度的任务，利用系统的可扩展性来提高性能。

　　2．4　性能分析

　　新设计的方案充分发挥了指令局部性和数据局部性的优点。处理线程在处理队列任务时，由于队列中每一个操作所作的事都一样（如不停的发RTP 包），因此每个操作的指令序列都是完全相同的；而且，当客户在连接后要求获得热点节目的媒体文件时，指令操作的数据也将非常相近，都在一个范围很小的区域内。这样，经过几次操作后，当指令被加载到Cache中，数据加载到内存中后，就不再需要从磁盘中去调，极大提高了程序的性能。

　　新设计的方案可以实现流媒体数据在内存中连续存放，快速存取以及Cache预取，资源管理方式从以应用线程为中心的资源管理与分配转变为以数据为中心的资源管理与分配。

　　衡量流媒体服务器的性能可以根据服务CPU的负载情况来衡量。CPU的使用情况主要和连接的客户数目，客户端的操作如读取，快进，搜索等相关。对于一个22kbps的文件集，改进的服务器设计方案与传统的服务器设计方案的性能优劣比较曲线，如图6所示。

　　图6体现了随着CPU数的增加，传统设计方案的性能变化不大，改进的设计方案在多个CPU的系统里，充分利用了CPU所带的Cache的强大功能，CPU的总体负载明显下降，可以获得性能的极大提高。

3结束语

　　本文从系统可扩展方面提出了实现高效的流媒体服务器的解决方案。除了系统可扩展方面，设计一个完善的高效流媒体服务器，还需要在实时的服务器操作系统，系统资源管理（CPU管理，内存管理，磁盘资源管理），文件管理，服务器磁盘调度方面进行高效的设计，这需要我们进一步研究和设计。