于述春， 赵嫦花， 何 佳

1 概述

对于那些每个请求的业务处理量不大，但要支持大容量视频访问/播放的网站，采用传统的并发处理的web服务器方案不能很好的解决问题.例如那些以增加访问缓存为主要特点的方案[1-3]，由于视频文件显然不适合于大量缓存，因而，在面对这类大量视频播放要求的网站时就显得不太适合.相反，如果是专门为视频提供服务，那么刘烈等提出的视频服务器专门解决方案是可用的[4-7].

现在我们讨论一种与上述情形不同的应用场景：有少量的业务处理需要，同时又有大量的视频访问需要.这种应用场景其中一个最主要的应用就是在线教育类网站.如果将视频移到专门的视频服务器，但视频又需要与web服务器其他信息关联.在这样一类请求的业务处理要求不高，但视频访问量大的网络应用中，如何优化或应对高容量的视频访问，就成为系统构架必须解决的一个关键问题.

针对这类网络应用，我们提出一种web服务器+一群nginx视频服务器的方案.这个方案的特点是外部用户只需访问web网站，而实际上，用户对视频的访问完全委托给那一群nginx视频服务器处理.这种方案完全利用了如Apache和Tomcat等Web服务器强大的动态内容处理功能，以及Nginx高性能的静态内容访问特点[8].

2 框架概述

2.1 视频流和一般web请求处理策略

当今网络流量超过50%是视频[9]，许多网络视频采用流媒体技术.这种技术使得用户在播放视频之前不需要完全下载视频内容，而可以边播放边下载.这种流媒体处理策略一般分为两个阶段：缓冲阶段和稳定状态阶段[10]，在缓冲阶段，主要是下载视频帧信息到播放器缓冲区；稳定状态阶段主要是在缓冲区中视频帧播放完之前从服务器下载新的视频块到缓冲区.每个流服务一般以TCP长连接方式实现.

一般web请求采用HTTP协议传输，这类请求的特点是事务性的.据相关文献报道，现在许多web请求包含有 javascript，css，xml等内容，这些随着 Ajax 技术的推广而变得越来越普遍[11].因此，现在的web请求一般是采用动态网页技术进行处理，需要后台服务器有强大的处理功能.一般地，这些web请求（非视频类的请求）数据量相比视频流要少很多，但后台处理功能要求强大.

因此，在开发Web应用系统时，需要根据应用需要考虑是将视频内容与其他内容一起在Web服务器呢，还是将视频内容与其他非视频内容分开处理.

如果Web应用系统中视频内容很少或者没有性能方面的考虑，可以直接将视频内容部署于web服务器上，用未经优化的TCP连接来传输视频内容.这种方案的优点是简单节省.但如果Web应用系统含有大量视频内容，还将视频内容与其他内容一起由Web服务器处理，那么一方面会因视频而极大影响Web请求响应时间，另一方面视频观看总会出现卡顿现象，甚至很长时间都播放不了.因此，一般的办法是将视频与其他非视频的Web内容分开处理.

将视频和其他非视频的内容分开也可采用两种办法.一种办法是将视频上传到专门的视频服务网站如优酷等，然后在自己的网站中提供这些视频的超链接，这种办法的优点是明显的，不需要与视频相关的软硬件投资，但其缺点是不灵活，不适合于那些视频是由用户上传的情况.另一种办法是在开发和部署Web应用系统时，分别部署视频流媒体服务器和Web服务器，前者专门处理视频，后者专门处理非视频的Web请求.

2.2 流媒体服务器的选择

在基于Web的应用系统中，其访问模式都是基于B/S模式的，因此，要求客户端不需要专门的视频播放器，而统一采用浏览器观看视频.Adobe Flash有专门的播放插件，只要流媒体格式为flv或mp4即可.而且由于flv格式的视频在网络视频中占据主流[11]，因此，选用这种格式的流媒体是正当的.

针对HTTP流媒体对apache和nginx等Web服务器作过测试，测试结果表明：nginx针对apache等Web服务器在HTTP流媒体方面有更好的性能[12].Nginx出色的性能以及对flv和mp4 HTTP流媒体的支持使它成为构架流媒体服务器的不错的选择[13].

因此，在有大量视频的web应用系统中，最具可扩展性的方法是将视频部分与一般的信息处理部分分开：将视频播放与其他web信息分开，在不同机器上进行，通过web系统对视频进行上传或删除等管理功能.

2.3 可扩展框架概述

基于视频与其他Web请求分开处理的策略，整个富视频的Web应用系统主要由四大模块组成：nginx流媒体服务器，作为视频播放服务器；web服务器，作为传统的web服务器，处理除视频播放外的其他业务；视频接收程序，在nginx服务器一端，接收由web服务器一端上传的视频，并向web服务器注册，以及获取视频截图并将截图返回web服务器；视频发送程序，在web服务器一端，发送用户上传到web服务器的视频，管理视频接收程序的注册，接收回传的视频截图.

图1中，流媒体服务器即由nginx充当，web服务器即传统的web系统服务器端，用户上传视频或浏览网页只与web服务器交互，当上传的视频文件到达web服务器时，即由视频发送程序将视频发送到某个视频服务器中；在视频服务器一端，由视频接收程序将视频格式进行一定的变换，并将转换后的视频格式文件保存到流媒体服务器所配置的目录中，同时自动从视频中抓取截图，并将截图返回给视频发送程序，后者再保存到相应web目录下，并相应修改与web服务器共享的数据库表.

图1 Web服务器与流媒体服务器的分离

从图1中还可看出，多个流服务器对应一个web服务器，这也正是这个网络视频传播的特点：当网站视频数量增多或视频观看并发用户访问量增加时，可通过部署更多的nginx流服务器进扩展.

3 框架组件

3.1 nginx流服务器

nginx流服务器的主要作用是提供视频播放时服务器端对流媒体的支持功能，其所支持的视频格式有flv与mp4.

Nginx主要用作http服务器，但加入nginx_mod_h264_streaming-2.2.7和http_flv_module模块后，即可支持flv和mp4格式的视频，加入yamdi-1.4模块即可拖动.

在从网上下载这些模块并解压后，可通过下述命令配置nginx，使其包含上述模块：

configure

-add-module=../ngnix_mod_h264_streaming

--with-http_flv_module

为支持从视频抓取截图，需要ffmpeg软件的支持，以下命令是配置ffmpeg的，其相应模块也需要从网上下载：

./configure -enable-mp3lame -enable-amr_nb-enable-amr_wb -enable-a52 -enable-xvid-enable-x264-enable-faad-enable-faac-enable-gpl-enable-libogg -enable-vorbis

最后是对nginx进行配置：

server{

listen 80；

server_name serverIP；

root/flv/；

limit_rate_after 5m；

limit_rate512k；

index index.html；

charset utf-8；

#access_log logs/host.access.logmain；

location～.flv${

flv；

}

location～.mp4${

mp4；}

｝

上述配置中，指定服务器侦听端口为80，指定服务器IP，服务器视频文件根目录为/flv，而location～.flv$与location～.mp4表示服务器支持flv格式和mp4格式的视频.

3.2 web服务器

web服务器可使用任何传统的开发web系统的平台或工具开发，如SSH2框架或tapestry框架或ASP.NET都可以.其主要功能是提供除视频播放外的其他业务功能，也包括为注册用户或系统管理员提供视频上传功能.除此之外，还有其他一些业务处理功能.

下面只讨论一下视频上传功能.在用传统的文件上传功能完成视频上传到web服务器后，web服务器将视频文件根据系统要求进行重命名，并将文件名保存到视频信息表中，设置视频移动标志为0，表示视频文件还未移到视频服务器.

在用户访问视频链接时，web服务器根据视频信息表中移动标志是否为1来将相应记录中的视频服务器IP地址和新视频文件名取出，加入到相应的视频链接.当用户点击这样的视频链接时，用户就可观看相应视频.

3.3 视频接收程序

图2说明了平台四大组件间的数据流传递关系.视频发送程序从数据库接收未发送到流媒体服务器的视频信息，并将收到的截图文件名更新到数据库，同时更新视频文件移动标志；视频接收程序接收由视频发送程序从网络发送的视频文件；流媒体服务器只从所配置的视频文件目录中获取视频文件，视频接收程序只将格式转换后的视频保存到该目录.

图2 四大模块间的关系

视频接收程序将以后台进程的方式运行.

视频接收程序的子模块划分如图3所示.

图3 视频接收程序模块图

注册模块：向视频发送程序发送注册信息，注册信息包括以下内容：流媒体服务器IP地址，侦听端口，流媒体服务器内存大小，流媒体服务器空闲硬盘空间.以便视频发送程序可根据各流媒体服务器的性能参数选择适当的服务器接收新的视频文件.同时，注册模块在完成向视频发送程序发送注册信息后，将启动一个在线询问回复线程，其作用是在视频接收程序仍在运行，但视频发送程序重启时，由视频发送程序主动询问视频接收程序是否仍在线，若收到这样的询问（即收到“hello”），那么将回复“run”，表示视频接收程序仍在线运行.

文件接收线程：接收来自视频发送程序所发送的视频文件，双方发送视频文件的协议为：

（1）视频发送程序发送视频文件信息：文件名|格式|大小；

（2）视频接收程序在正确接收到视频文件信息时，发送：ok

（3）视频发送程序发送视频文件

（4）视频接收程序在正确接收视频文件后，发送：success

然后视频接收程序根据接收到的视频文件名后缀确定视频格式，如果视频格式不是flv或mp4，则调用ffmpeg进行必要的格式转换，在转换完成后，将新格式视频保存到视频目录.然后启动图像抓取与发送线程.

图像发送线程：调用ffmpeg程序对新转换的视频文件或原格式的视频抓取两幅截图，然后将截图发送给视频发送程序.截图传送协议是：

（1）图像发送线程发送截图个数及所属视频和新的视频格式：个数，视频ID，新格式；

（2）视频接收程序接收；

（3）图像发送线程发送：图像文件名，大小

（4）视频接收程序接收到后，响应：ready

（5）图像发送线程发送图像文件本身；

（6）视频接收程序接收后，如果不是最后一个图像，响应：next；

接着重复流程（3）～（6）.

3.4 视频发送程序

视频发送程序的功能是将web服务器收到的仍未移到某个视频服务器的视频文件发送到视频服务器，并接收从该视频中抓取的截图，然后更新相应数据库表的对应记录.如果web服务器部署在windows平台，那么视频发送程序将作为一个windows服务程序运行；如果web服务器部署在linux平台，那么视频发送程序将作为一个后台进行运行.

在windows平台下，采用C#语言开发，以方便访问数据库.

视频发送程序的子模块如图4所示.

注册接收线程：这个线程先从数据库表中搜索曾经有哪些视频接收程序注册过，然后向这些程序发送询问消息“hello”，如果它们在线，则以“run”响应，注册接收线程将收到响应的视频接收程序的IP地址加入一个视频接收者列表.在对曾注册的视频接收程序都询问完后，启动一个线程，等待视频接收程序主动注册.

文件传输线程池：在windows平台，利用C#的ThreadPool组件完成线程池，设置线程池中线程最大可用个数.每个线程的功能是将分配给它的一个视频文件发送到视频接收程序.它与视频接收程序的通信协议已于前述，如果它在发送完视频文件信息后，收到”refuse”，那么表示视频服务器端已经有此视频文件，因而不用重传，此时可直接更新数据库视频表的移动标志，放弃传输视频文件.

正常情况下，在线程传输完一个视频文件后，视频接收程序如果返回”success”，那么线程将更新视频表的移动标志及视频服务器IP地址.

图像接收线程：这个线程将接收从视频服务器发来的视频截图，并将截图文件名更新到视频表相应字段.由于视频截图发送时会发送视频ID，因此，这个线程在接收到截图后，即可更新特定视频的截图文件名.这些视频截图用于web服务器在列出视频链接时给出相应的视频截图.

这个程序的主要过程如下：

（1）查询所有在线的视频接收程序，将它们加入视频服务器列表；

（2）启动注册接收线程，将接收到的注册视频服务器加入视频服务器列表，并同时插入数据库表；

（3）启动图像接收线程；

（4）查询数据库视频表中移动标志为0的视频记录，放到待传输文件列表；

a）对每个待传输文件，从视频服务器列表中找一个适合的服务器，启动一个文件传输线程，传输视频文件；

b）睡眠 5秒，继续（4）.

4 测试环境与结果

测试平台由两台计算机组成，一台安装windows 7，web服务器部署在其上，内存4 G，硬盘500 G，100 Mbps局域网；一台安装centos6.5，nginx服务器部署在其上，内存也是4 G，200 G硬盘空间，连接100 Mbps局域网.通过web服务器上传5个大小在200～500 MB的视频.

对比组：两台计算机的硬件配置完全相同，唯一不同的是，两台计算机部署相同的web系统，且视频也由web服务器处理.

上述的web应用采用tomcat作为服务器.

测试过程：每个访问web系统的同时也访问视频.访问web系统需要进行一些简单的业务处理.因此，测试过程中重点测试对视频的访问导致对web系统性能的影响.

测试结果如图5所示.

上述结果中，对于仅采用web方式来处理业务请求和视频访问来说，如果web服务器不是选用tomcat，而是用nginx，可能会好得多.

结语

上述结果说明：（1）将视频交给nginx处理，在并发访问视频用户数上升到某个数量时，它会比由web服务器来提供视频访问有好得多的性能.

Ashwin Rao等[10]认为nginx其开发就是解决C10K[14]问题，而Apache系列，也包括Tomcat就是不能很好地解决高并发条件下的web访问性能.因此，采用nginx本身就比采用tomcat作为web服务器性能要好.故上述测试结果在视频访问量增加时，nginx的性能要明显好于tomcat.

同时，在nginx中加入支持flv流媒体和mp4流媒体模块，将nginx作为流媒体服务器，也得到广泛认可[15]，而且还有很好的性能.

（2）一个web服务器+一群nginx流媒体服务器架构具有很好的可扩展性.上述测试虽然仅部署一台nginx流媒体服务器，但随着更大的并发视频访问量的到来，可再以同样的方式部署一台nginx流媒体服务器.而且新部署到系统的Nginx服务器对原服务器无任何影响，只是分担更多的视频的访问.

这种可扩展性还不能做到自动化，还需要人工部署与配置.另外，这个方案也未提供访问视频时的用户安全性检查.如果恶意用户保存合法用户访问某个视频的链接，那么他也可访问此视频.这些都是有待改进的地方.

[1]蒋文旭.基于nginx部署环境的Web加速方案设计与实现[D].北京：北京邮电大学，2012：20-25.

[2]李艳生，汪自云.一种实用的海量Web系统架构设计研究与实现[J].湖北师范学院学报（自然科学版），2009（4）：87-90.

[3]戴华.基于nginx和memcached的高并发web服务器设计[D].上海：复旦大学，2013：30-41.

[4]刘烈.基于linux的视频服务器开发[D].济南：济南大学，2012：31-37.

[5]罗文.基于http自适应流媒体关键技术的研究及实现[D].南京：南京邮电大学，2014：40-45.

[6]周怡兵.流媒体服务器软件的设计与实现[D].武汉：华中科技大学，2011：32-37.

[7]董科军，南凯，阎保平.一种可扩展的集群流媒体服务器[J].计算机工程与应用，2003（25）：46-49.

[8]Walker Rowe.Nginx vs Apache[EB/OL].https：//anturis.com/blog/nginx-vs-apache/.

[9]Sandvine.Global Internet phenomena report 1H 2014[EB/OL].https：//www.sandvine.com/downloads/general/global-internetphenomena/2014/1h-2014-global-internet-phenomena-report.pdf.

[10]Ashwin Rao，Arnaud Legout，Yeon-sup Lim，et.ac.Network characteristics of video streaming traffic[C].Proceedings of Seventh Conference on emerging Networking Experiments and Technologies，2011.

[11]Sunghwan Ihm，Vivek S.Pai.Towardsunderstandingmodern web traffic[C].Proceedings of the 2011 ACM SIGCOMM Conference on Internet measurement conference：295-312.

[12]Jim Summers，Tim Brecht，Derek Eager，et.ac.Methodologies for generating HTTP streaming video workloads to evaluate web server performance[C].Proceedings of the 5th Annual International Systemsand Storage Conference，2012.

[13]Nginx.Streaming media delivery using nginx plus[EB/OL].https：//www.nginx.com/products/streaming-media-delivery.

[14]Daniel Kegel.The C10Kproblem[EB/OL].http：//www.kegel.com/c10k.html.

[15]NGINX Media Server-Amazon Linux AMI[EB/OL].https：//aws.amazon.com/marketplace/pp/B00LIC1GPM/ref=mkt_wir_nginx_stream_media.