富視頻類Web應用系統的一種可擴展框架

于述春， 趙嫦花， 何 佳

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.