于述春， 趙嫦花， 何 佳

1 概述

對于那些每個請求的業(yè)務處理量不大，但要支持大容量視頻訪問/播放的網(wǎng)站，采用傳統(tǒng)的并發(fā)處理的web服務器方案不能很好的解決問題.例如那些以增加訪問緩存為主要特點的方案[1-3]，由于視頻文件顯然不適合于大量緩存，因而，在面對這類大量視頻播放要求的網(wǎng)站時就顯得不太適合.相反，如果是專門為視頻提供服務，那么劉烈等提出的視頻服務器專門解決方案是可用的[4-7].

現(xiàn)在我們討論一種與上述情形不同的應用場景：有少量的業(yè)務處理需要，同時又有大量的視頻訪問需要.這種應用場景其中一個最主要的應用就是在線教育類網(wǎng)站.如果將視頻移到專門的視頻服務器，但視頻又需要與web服務器其他信息關聯(lián).在這樣一類請求的業(yè)務處理要求不高，但視頻訪問量大的網(wǎng)絡應用中，如何優(yōu)化或應對高容量的視頻訪問，就成為系統(tǒng)構(gòu)架必須解決的一個關鍵問題.

針對這類網(wǎng)絡應用，我們提出一種web服務器+一群nginx視頻服務器的方案.這個方案的特點是外部用戶只需訪問web網(wǎng)站，而實際上，用戶對視頻的訪問完全委托給那一群nginx視頻服務器處理.這種方案完全利用了如Apache和Tomcat等Web服務器強大的動態(tài)內(nèi)容處理功能，以及Nginx高性能的靜態(tài)內(nèi)容訪問特點[8].

2 框架概述

2.1 視頻流和一般web請求處理策略

當今網(wǎng)絡流量超過50%是視頻[9]，許多網(wǎng)絡視頻采用流媒體技術(shù).這種技術(shù)使得用戶在播放視頻之前不需要完全下載視頻內(nèi)容，而可以邊播放邊下載.這種流媒體處理策略一般分為兩個階段：緩沖階段和穩(wěn)定狀態(tài)階段[10]，在緩沖階段，主要是下載視頻幀信息到播放器緩沖區(qū)；穩(wěn)定狀態(tài)階段主要是在緩沖區(qū)中視頻幀播放完之前從服務器下載新的視頻塊到緩沖區(qū).每個流服務一般以TCP長連接方式實現(xiàn).

一般web請求采用HTTP協(xié)議傳輸，這類請求的特點是事務性的.據(jù)相關文獻報道，現(xiàn)在許多web請求包含有 javascript，css，xml等內(nèi)容，這些隨著 Ajax 技術(shù)的推廣而變得越來越普遍[11].因此，現(xiàn)在的web請求一般是采用動態(tài)網(wǎng)頁技術(shù)進行處理，需要后臺服務器有強大的處理功能.一般地，這些web請求（非視頻類的請求）數(shù)據(jù)量相比視頻流要少很多，但后臺處理功能要求強大.

因此，在開發(fā)Web應用系統(tǒng)時，需要根據(jù)應用需要考慮是將視頻內(nèi)容與其他內(nèi)容一起在Web服務器呢，還是將視頻內(nèi)容與其他非視頻內(nèi)容分開處理.

如果Web應用系統(tǒng)中視頻內(nèi)容很少或者沒有性能方面的考慮，可以直接將視頻內(nèi)容部署于web服務器上，用未經(jīng)優(yōu)化的TCP連接來傳輸視頻內(nèi)容.這種方案的優(yōu)點是簡單節(jié)省.但如果Web應用系統(tǒng)含有大量視頻內(nèi)容，還將視頻內(nèi)容與其他內(nèi)容一起由Web服務器處理，那么一方面會因視頻而極大影響Web請求響應時間，另一方面視頻觀看總會出現(xiàn)卡頓現(xiàn)象，甚至很長時間都播放不了.因此，一般的辦法是將視頻與其他非視頻的Web內(nèi)容分開處理.

將視頻和其他非視頻的內(nèi)容分開也可采用兩種辦法.一種辦法是將視頻上傳到專門的視頻服務網(wǎng)站如優(yōu)酷等，然后在自己的網(wǎng)站中提供這些視頻的超鏈接，這種辦法的優(yōu)點是明顯的，不需要與視頻相關的軟硬件投資，但其缺點是不靈活，不適合于那些視頻是由用戶上傳的情況.另一種辦法是在開發(fā)和部署Web應用系統(tǒng)時，分別部署視頻流媒體服務器和Web服務器，前者專門處理視頻，后者專門處理非視頻的Web請求.

2.2 流媒體服務器的選擇

在基于Web的應用系統(tǒng)中，其訪問模式都是基于B/S模式的，因此，要求客戶端不需要專門的視頻播放器，而統(tǒng)一采用瀏覽器觀看視頻.Adobe Flash有專門的播放插件，只要流媒體格式為flv或mp4即可.而且由于flv格式的視頻在網(wǎng)絡視頻中占據(jù)主流[11]，因此，選用這種格式的流媒體是正當?shù)?

針對HTTP流媒體對apache和nginx等Web服務器作過測試，測試結(jié)果表明：nginx針對apache等Web服務器在HTTP流媒體方面有更好的性能[12].Nginx出色的性能以及對flv和mp4 HTTP流媒體的支持使它成為構(gòu)架流媒體服務器的不錯的選擇[13].

因此，在有大量視頻的web應用系統(tǒng)中，最具可擴展性的方法是將視頻部分與一般的信息處理部分分開：將視頻播放與其他web信息分開，在不同機器上進行，通過web系統(tǒng)對視頻進行上傳或刪除等管理功能.

2.3 可擴展框架概述

基于視頻與其他Web請求分開處理的策略，整個富視頻的Web應用系統(tǒng)主要由四大模塊組成：nginx流媒體服務器，作為視頻播放服務器；web服務器，作為傳統(tǒng)的web服務器，處理除視頻播放外的其他業(yè)務；視頻接收程序，在nginx服務器一端，接收由web服務器一端上傳的視頻，并向web服務器注冊，以及獲取視頻截圖并將截圖返回web服務器；視頻發(fā)送程序，在web服務器一端，發(fā)送用戶上傳到web服務器的視頻，管理視頻接收程序的注冊，接收回傳的視頻截圖.

圖1中，流媒體服務器即由nginx充當，web服務器即傳統(tǒng)的web系統(tǒng)服務器端，用戶上傳視頻或瀏覽網(wǎng)頁只與web服務器交互，當上傳的視頻文件到達web服務器時，即由視頻發(fā)送程序?qū)⒁曨l發(fā)送到某個視頻服務器中；在視頻服務器一端，由視頻接收程序?qū)⒁曨l格式進行一定的變換，并將轉(zhuǎn)換后的視頻格式文件保存到流媒體服務器所配置的目錄中，同時自動從視頻中抓取截圖，并將截圖返回給視頻發(fā)送程序，后者再保存到相應web目錄下，并相應修改與web服務器共享的數(shù)據(jù)庫表.

圖1 Web服務器與流媒體服務器的分離

從圖1中還可看出，多個流服務器對應一個web服務器，這也正是這個網(wǎng)絡視頻傳播的特點：當網(wǎng)站視頻數(shù)量增多或視頻觀看并發(fā)用戶訪問量增加時，可通過部署更多的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模塊即可拖動.

在從網(wǎng)上下載這些模塊并解壓后，可通過下述命令配置nginx，使其包含上述模塊：

configure

-add-module=../ngnix_mod_h264_streaming

--with-http_flv_module

為支持從視頻抓取截圖，需要ffmpeg軟件的支持，以下命令是配置ffmpeg的，其相應模塊也需要從網(wǎng)上下載：

./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服務器可使用任何傳統(tǒng)的開發(fā)web系統(tǒng)的平臺或工具開發(fā)，如SSH2框架或tapestry框架或ASP.NET都可以.其主要功能是提供除視頻播放外的其他業(yè)務功能，也包括為注冊用戶或系統(tǒng)管理員提供視頻上傳功能.除此之外，還有其他一些業(yè)務處理功能.

下面只討論一下視頻上傳功能.在用傳統(tǒng)的文件上傳功能完成視頻上傳到web服務器后，web服務器將視頻文件根據(jù)系統(tǒng)要求進行重命名，并將文件名保存到視頻信息表中，設置視頻移動標志為0，表示視頻文件還未移到視頻服務器.

在用戶訪問視頻鏈接時，web服務器根據(jù)視頻信息表中移動標志是否為1來將相應記錄中的視頻服務器IP地址和新視頻文件名取出，加入到相應的視頻鏈接.當用戶點擊這樣的視頻鏈接時，用戶就可觀看相應視頻.

3.3 視頻接收程序

圖2說明了平臺四大組件間的數(shù)據(jù)流傳遞關系.視頻發(fā)送程序從數(shù)據(jù)庫接收未發(fā)送到流媒體服務器的視頻信息，并將收到的截圖文件名更新到數(shù)據(jù)庫，同時更新視頻文件移動標志；視頻接收程序接收由視頻發(fā)送程序從網(wǎng)絡發(fā)送的視頻文件；流媒體服務器只從所配置的視頻文件目錄中獲取視頻文件，視頻接收程序只將格式轉(zhuǎn)換后的視頻保存到該目錄.

圖2 四大模塊間的關系

視頻接收程序?qū)⒁院笈_進程的方式運行.

視頻接收程序的子模塊劃分如圖3所示.

圖3 視頻接收程序模塊圖

注冊模塊：向視頻發(fā)送程序發(fā)送注冊信息，注冊信息包括以下內(nèi)容：流媒體服務器IP地址，偵聽端口，流媒體服務器內(nèi)存大小，流媒體服務器空閑硬盤空間.以便視頻發(fā)送程序可根據(jù)各流媒體服務器的性能參數(shù)選擇適當?shù)姆掌鹘邮招碌囊曨l文件.同時，注冊模塊在完成向視頻發(fā)送程序發(fā)送注冊信息后，將啟動一個在線詢問回復線程，其作用是在視頻接收程序仍在運行，但視頻發(fā)送程序重啟時，由視頻發(fā)送程序主動詢問視頻接收程序是否仍在線，若收到這樣的詢問（即收到“hello”），那么將回復“run”，表示視頻接收程序仍在線運行.

文件接收線程：接收來自視頻發(fā)送程序所發(fā)送的視頻文件，雙方發(fā)送視頻文件的協(xié)議為：

（1）視頻發(fā)送程序發(fā)送視頻文件信息：文件名|格式|大小；

（2）視頻接收程序在正確接收到視頻文件信息時，發(fā)送：ok

（3）視頻發(fā)送程序發(fā)送視頻文件

（4）視頻接收程序在正確接收視頻文件后，發(fā)送：success

然后視頻接收程序根據(jù)接收到的視頻文件名后綴確定視頻格式，如果視頻格式不是flv或mp4，則調(diào)用ffmpeg進行必要的格式轉(zhuǎn)換，在轉(zhuǎn)換完成后，將新格式視頻保存到視頻目錄.然后啟動圖像抓取與發(fā)送線程.

圖像發(fā)送線程：調(diào)用ffmpeg程序?qū)π罗D(zhuǎn)換的視頻文件或原格式的視頻抓取兩幅截圖，然后將截圖發(fā)送給視頻發(fā)送程序.截圖傳送協(xié)議是：

（1）圖像發(fā)送線程發(fā)送截圖個數(shù)及所屬視頻和新的視頻格式：個數(shù)，視頻ID，新格式；

（2）視頻接收程序接收；

（3）圖像發(fā)送線程發(fā)送：圖像文件名，大小

（4）視頻接收程序接收到后，響應：ready

（5）圖像發(fā)送線程發(fā)送圖像文件本身；

（6）視頻接收程序接收后，如果不是最后一個圖像，響應：next；

接著重復流程（3）～（6）.

3.4 視頻發(fā)送程序

視頻發(fā)送程序的功能是將web服務器收到的仍未移到某個視頻服務器的視頻文件發(fā)送到視頻服務器，并接收從該視頻中抓取的截圖，然后更新相應數(shù)據(jù)庫表的對應記錄.如果web服務器部署在windows平臺，那么視頻發(fā)送程序?qū)⒆鳛橐粋€windows服務程序運行；如果web服務器部署在linux平臺，那么視頻發(fā)送程序?qū)⒆鳛橐粋€后臺進行運行.

在windows平臺下，采用C#語言開發(fā)，以方便訪問數(shù)據(jù)庫.

視頻發(fā)送程序的子模塊如圖4所示.

注冊接收線程：這個線程先從數(shù)據(jù)庫表中搜索曾經(jīng)有哪些視頻接收程序注冊過，然后向這些程序發(fā)送詢問消息“hello”，如果它們在線，則以“run”響應，注冊接收線程將收到響應的視頻接收程序的IP地址加入一個視頻接收者列表.在對曾注冊的視頻接收程序都詢問完后，啟動一個線程，等待視頻接收程序主動注冊.

文件傳輸線程池：在windows平臺，利用C#的ThreadPool組件完成線程池，設置線程池中線程最大可用個數(shù).每個線程的功能是將分配給它的一個視頻文件發(fā)送到視頻接收程序.它與視頻接收程序的通信協(xié)議已于前述，如果它在發(fā)送完視頻文件信息后，收到”refuse”，那么表示視頻服務器端已經(jīng)有此視頻文件，因而不用重傳，此時可直接更新數(shù)據(jù)庫視頻表的移動標志，放棄傳輸視頻文件.

正常情況下，在線程傳輸完一個視頻文件后，視頻接收程序如果返回”success”，那么線程將更新視頻表的移動標志及視頻服務器IP地址.

圖像接收線程：這個線程將接收從視頻服務器發(fā)來的視頻截圖，并將截圖文件名更新到視頻表相應字段.由于視頻截圖發(fā)送時會發(fā)送視頻ID，因此，這個線程在接收到截圖后，即可更新特定視頻的截圖文件名.這些視頻截圖用于web服務器在列出視頻鏈接時給出相應的視頻截圖.

這個程序的主要過程如下：

（1）查詢所有在線的視頻接收程序，將它們加入視頻服務器列表；

（2）啟動注冊接收線程，將接收到的注冊視頻服務器加入視頻服務器列表，并同時插入數(shù)據(jù)庫表；

（3）啟動圖像接收線程；

（4）查詢數(shù)據(jù)庫視頻表中移動標志為0的視頻記錄，放到待傳輸文件列表；

a）對每個待傳輸文件，從視頻服務器列表中找一個適合的服務器，啟動一個文件傳輸線程，傳輸視頻文件；

b）睡眠 5秒，繼續(xù)（4）.

4 測試環(huán)境與結(jié)果

測試平臺由兩臺計算機組成，一臺安裝windows 7，web服務器部署在其上，內(nèi)存4 G，硬盤500 G，100 Mbps局域網(wǎng)；一臺安裝centos6.5，nginx服務器部署在其上，內(nèi)存也是4 G，200 G硬盤空間，連接100 Mbps局域網(wǎng).通過web服務器上傳5個大小在200～500 MB的視頻.

對比組：兩臺計算機的硬件配置完全相同，唯一不同的是，兩臺計算機部署相同的web系統(tǒng)，且視頻也由web服務器處理.

上述的web應用采用tomcat作為服務器.

測試過程：每個訪問web系統(tǒng)的同時也訪問視頻.訪問web系統(tǒng)需要進行一些簡單的業(yè)務處理.因此，測試過程中重點測試對視頻的訪問導致對web系統(tǒng)性能的影響.

測試結(jié)果如圖5所示.

上述結(jié)果中，對于僅采用web方式來處理業(yè)務請求和視頻訪問來說，如果web服務器不是選用tomcat，而是用nginx，可能會好得多.

結(jié)語

上述結(jié)果說明：（1）將視頻交給nginx處理，在并發(fā)訪問視頻用戶數(shù)上升到某個數(shù)量時，它會比由web服務器來提供視頻訪問有好得多的性能.

Ashwin Rao等[10]認為nginx其開發(fā)就是解決C10K[14]問題，而Apache系列，也包括Tomcat就是不能很好地解決高并發(fā)條件下的web訪問性能.因此，采用nginx本身就比采用tomcat作為web服務器性能要好.故上述測試結(jié)果在視頻訪問量增加時，nginx的性能要明顯好于tomcat.

同時，在nginx中加入支持flv流媒體和mp4流媒體模塊，將nginx作為流媒體服務器，也得到廣泛認可[15]，而且還有很好的性能.

（2）一個web服務器+一群nginx流媒體服務器架構(gòu)具有很好的可擴展性.上述測試雖然僅部署一臺nginx流媒體服務器，但隨著更大的并發(fā)視頻訪問量的到來，可再以同樣的方式部署一臺nginx流媒體服務器.而且新部署到系統(tǒng)的Nginx服務器對原服務器無任何影響，只是分擔更多的視頻的訪問.

這種可擴展性還不能做到自動化，還需要人工部署與配置.另外，這個方案也未提供訪問視頻時的用戶安全性檢查.如果惡意用戶保存合法用戶訪問某個視頻的鏈接，那么他也可訪問此視頻.這些都是有待改進的地方.

[1]蔣文旭.基于nginx部署環(huán)境的Web加速方案設計與實現(xiàn)[D].北京：北京郵電大學，2012：20-25.

[2]李艷生，汪自云.一種實用的海量Web系統(tǒng)架構(gòu)設計研究與實現(xiàn)[J].湖北師范學院學報（自然科學版），2009（4）：87-90.

[3]戴華.基于nginx和memcached的高并發(fā)web服務器設計[D].上海：復旦大學，2013：30-41.

[4]劉烈.基于linux的視頻服務器開發(fā)[D].濟南：濟南大學，2012：31-37.

[5]羅文.基于http自適應流媒體關鍵技術(shù)的研究及實現(xiàn)[D].南京：南京郵電大學，2014：40-45.

[6]周怡兵.流媒體服務器軟件的設計與實現(xiàn)[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.