基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體直播系統(tǒng)設計

摘 ?要：針對直播系統(tǒng)在復雜網(wǎng)絡環(huán)境下傳輸信號差的缺陷，提出基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體直播系統(tǒng)。采用先進的流媒體服務器集群技術(shù)，在傳輸服務器接收流媒體信息時采用RUDP協(xié)議，在傳輸服務器將流媒體信息推送至媒體服務器時采用RTMP協(xié)議，可以極大地提升系統(tǒng)所要求支持的并發(fā)性流量和數(shù)目，有效地避免了單點失效給系統(tǒng)帶來的不良影響。通過分別對用RTMP與RUDP結(jié)合、RTMP和RUDP實現(xiàn)的消息傳輸性能進行測試和比較，表明該方法可以提高復雜網(wǎng)絡環(huán)境下直播系統(tǒng)中音視頻流媒體的傳輸質(zhì)量和傳輸效率。

關鍵詞：內(nèi)容分發(fā)網(wǎng)絡;推流;服務器集群;流媒體

中圖分類號：TP393 ? ? 文獻標識碼：A

Abstract： Aiming at poor transmission signal of the live broadcast system in complex network environment， the paper proposes to design a real-time streaming media live broadcast system based on content distribution network， by adopting advanced streaming media server cluster technology. RUDP （Reliable User Datagram Protocol） protocol is used when transmission server receives streaming media information. RTMP （Real-time Messaging Protocol） protocol is used when transmission server pushes the streaming media information to media server. This greatly increases the concurrent traffic and number required by the system， and effectively avoids the adverse impact of single-point failure on the system. The message transmission performance achieved by combining RTMP and RUDP， by RTMP and by RUDP is tested and compared， which shows that this method can improve the transmission quality and transmission efficiency of audio and video streaming media in a live broadcast system in a complex network environment.

Keywords： content distribution network; push flow; server cluster; streaming media

1 ? 引言（Introduction）

在用戶觀看直播過程中，如果網(wǎng)絡傳輸信號差，則用戶收到的語音數(shù)據(jù)和視頻信號可能會變得較差，并且正在播放的視頻信號效果會因此變得更糟[1]。針對上述問題，本文設計了一種基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體直播系統(tǒng)，采用先進的流媒體服務器集群技術(shù)[2-3]，在傳輸服務器接收流媒體信息時采用RUDP（Reliable User Datagram Protocol）協(xié)議[4]，在傳輸服務器將流媒體信息推送至媒體服務器時采用RTMP（Real Time Messaging Protocol）協(xié)議[5]。RUDP主要為了彌補RTMP在復雜網(wǎng)絡環(huán)境下傳輸信號差的缺陷[6-7]，通過內(nèi)容分發(fā)網(wǎng)絡設計，可以極大地提升系統(tǒng)所要求支持的并發(fā)性流量和數(shù)目，有效地避免了單點失效給系統(tǒng)帶來的不良影響，可以提高復雜網(wǎng)絡環(huán)境下直播系統(tǒng)中音視頻流媒體的傳輸質(zhì)量和傳輸效率。

2 ? 系統(tǒng)總體設計（Overall system design）

本文設計的基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體直播系統(tǒng)，包括系統(tǒng)物理架構(gòu)和系統(tǒng)邏輯架構(gòu)設計、系統(tǒng)推流設計、內(nèi)容分發(fā)網(wǎng)絡CDN（Content Delivery Network）設計、媒體數(shù)據(jù)NAT（Network Address Translation， 網(wǎng)絡地址轉(zhuǎn)換）設計。

2.1 ? 系統(tǒng)物理架構(gòu)

系統(tǒng)物理架構(gòu)采用三級交換網(wǎng)絡，主播將音視頻信息發(fā)送到MTS（Media Transfer Server， 媒體轉(zhuǎn)發(fā)服務器），MTS在發(fā)生故障時可以通過備份的MTS進行房間遷移。MTS處于一級交換網(wǎng)絡，MTS將信息推流到二級交換網(wǎng)的MSS-Origin（Media Streaming Server of Origin， 源媒體流服務器），然后推流到分布式CDN集群。觀眾通過各種瀏覽器訪問MSS-Edge（Media Streaming Server of Edge， 邊界媒體流服務器），MSS-Edge上的信息也可以回源到MSS-Origin端，數(shù)據(jù)流是可以雙向訪問和互動的。系統(tǒng)物理架構(gòu)如圖1所示。

2.2 ? 系統(tǒng)邏輯架構(gòu)

系統(tǒng)邏輯架構(gòu)采用四層架構(gòu)，最底層是LINUX內(nèi)核，上層通過系統(tǒng)API接口訪問LINUX內(nèi)核。然后是網(wǎng)絡層，網(wǎng)絡層分為網(wǎng)絡適配層、Net API接口和Event Drive三個部分，其中Net API接口遵循TCP/UDP（Transmission Control Protocol/User Datagram Protocol， 傳輸控制協(xié)議/用戶數(shù)據(jù)報協(xié)議）協(xié)議[8]，Event Drive通過epol（）函數(shù)進行LINUX系統(tǒng)設備訪問。接著是MTS層，MTS層包含房間管理、游客管理、認證鑒權(quán)、媒體轉(zhuǎn)發(fā)、直播推流和故障管理這幾個功能。最上層是接口層，包括MRS Interface（媒體資源管理服務器接口）、MTM Interface（媒體任務管理服務器接口）、MSS Interface（媒體流服務器接口）、Client Interface（客戶端接口）。系統(tǒng)邏輯架構(gòu)如圖2所示。

2.3 ? 主要狀態(tài)圖設計

首先，房間管理單元向媒體任務管理服務器（MTM）申請創(chuàng)建房間。MTM向媒體資源管理服務器（MRS）申請創(chuàng)建房間的消息代理，MRS向MTS發(fā)送申請創(chuàng)建房間消息，創(chuàng)建房間后向上一級返回創(chuàng)建結(jié)果。其次，房間管理單元進入房間，登記游客信息。第三，房間管理單元將開播參數(shù)發(fā)送給主播助手，主播助手連接MTS發(fā)送實時數(shù)據(jù)流，MTS通過用戶鑒權(quán)接收實時數(shù)據(jù)流。第四，MTS將房間信息推流到MSS（媒體流服務器），用戶通過瀏覽器訪問MSS拉取房間數(shù)據(jù)流并播放房間數(shù)據(jù)信息。狀態(tài)圖如圖3所示。

2.4 ? 系統(tǒng)時序圖

系統(tǒng)時序圖包括房間管理時序圖、用戶管理時序圖和角色管理時序圖，各個時序圖分別給出了各個模塊的操作流程。

2.4.1 ? 創(chuàng)建房間

房間管理單元向MTM申請創(chuàng)建房間，MTM審核通過后向MRS申請創(chuàng)建房間，MRS持久化房間信息，向MTM返回創(chuàng)建結(jié)果，MTM向RM返回申請結(jié)果。然后，MRS向MTS申請按能力分配房間資源，MTS分配資源后將分配的地址信息返回給MRS。創(chuàng)建房間時序圖如圖4所示。

2.4.2 ? 刪除房間

首先，RM向MTM申請刪除房間，MTM審核通過后向MRS發(fā)送刪除房間消息，MRS刪除房間持久化信息，向MTM返回刪除結(jié)果，MTM向RM返回刪除結(jié)果。然后，MRS向MTS申請刪除房間資源，MTS刪除房間資源后向MRS返回刪除結(jié)果。刪除房間時序圖如圖5所示。

2.4.3 ? 添加用戶

首先RM向MTM申請?zhí)砑佑脩?，MTM獲取該用戶所在房間地址，然后向MTS反向代理申請?zhí)砑佑脩?MTS向MTM返回結(jié)果和用戶標記信息，然后MTM向RM返回結(jié)果和標記信息。添加用戶時序圖如圖6所示。

2.4.4 ? 刪除用戶

首先RM向MTM申請刪除用戶，MTM獲取該用戶所在房間地址，然后反向代理，向MTS申請刪除用戶;MTS刪除用戶后向MTM返回結(jié)果，然后MTM向RM返回結(jié)果。刪除用戶時序圖如圖7所示。

2.4.5 ? 設置角色

首先RM向MTM申請變更用戶角色，MTM獲取該用戶所在房間地址信息，然后反向代理變更角色;MTS變更角色后向MTM返回變更結(jié)果，然后MTM向RM返回結(jié)果。設置角色時序圖如圖8所示。

3 ? 系統(tǒng)推流設計（System push flow design）

本系統(tǒng)設計了一種基于RUDP和RTMP結(jié)合的實時流媒體直播系統(tǒng)的推流方法[9]，包括：

步驟1：流媒體從助手端通過RUDP實時傳輸至MTS，流媒體包括音頻、視頻數(shù)據(jù)包。

步驟2：流媒體進入MTS的緩沖隊列進行去抖動后，判斷緩沖隊列中是否有數(shù)據(jù)，若有數(shù)據(jù)，則進入步驟3。

步驟3：將數(shù)據(jù)封裝成RTMP流推送至MSS中，向MSS推送時需要遵循RTMP的URL格式，例如：RTMP：//119.140.0.67：1935/live/10005689。然后判斷是否結(jié)束直播，如果是，則關閉直播，結(jié)束推送;如果不結(jié)束直播，則MTS繼續(xù)接收助手端推送的流媒體，并重復步驟1[10]。推流系統(tǒng)流程圖如圖9所示。

4 ? CDN內(nèi)容分發(fā)網(wǎng)絡設計（CDN content distribution network design）

本文設計了采用流媒體服務器集群技術(shù)的CDN（內(nèi)容分發(fā)網(wǎng)絡）。CDN是構(gòu)建在數(shù)據(jù)網(wǎng)絡上的一種分布式的內(nèi)容分發(fā)網(wǎng)絡。CDN的作用主要是采用流媒體服務器集群技術(shù)，克服單機系統(tǒng)輸出帶寬及并發(fā)能力不足的缺點，可極大提升系統(tǒng)支持的并發(fā)流數(shù)目，減少或避免單點失效帶來的不良影響。愛歌助手通過RUDP上傳流媒體信息到MTS，MTS將數(shù)據(jù)封裝成RTMP流，以推流的方式將流媒體信息推流到MSS內(nèi)多個CDN網(wǎng)絡中。在每個CDN網(wǎng)絡內(nèi)部，MSS Origin又將流媒體信息推送到多個MSS Edge，用戶通過MSS Edge接收流媒體信息或與MSS Edge進行交互。CDN內(nèi)容分發(fā)網(wǎng)絡設計如圖10所示。

5 ? 媒體數(shù)據(jù)NAT設計（Media data NAT design）

考慮到傳輸效率，愛歌助手通過RUDP傳輸媒體數(shù)據(jù)到MTS，需要處理NAT（Network Address Translation）問題。為了確保互聯(lián)網(wǎng)上每個客戶端都能順利地接入音視頻房間，需避免全對稱性NAT情況，所以每臺中心服務器必須都使用一個固定公網(wǎng)IP與之綁定。媒體數(shù)據(jù)NAT設計如圖11所示。

6 ? 系統(tǒng)測試及分析（System test and analysis）

測試環(huán)境是基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體傳輸技術(shù)應用于愛歌助手系統(tǒng)進行測試，包括主播機1 臺、MTS集群2 個、MSS-Origin服務器2 臺、MSS-Edge服務器6 臺，分布在不同的CDN網(wǎng)絡，客戶機6 臺。

（1）主播機配置：Intel core i5 CPU，16 GB內(nèi)存，Windows 10操作系統(tǒng)。

（2）MTS集群配置：

硬件環(huán)境：奔騰處理器。

軟件環(huán)境：操作系統(tǒng)為Linux Cent OS 7.0，Web Server

為Tomcat 8+Nginx，文件元數(shù)據(jù)庫為MySQL，文件系統(tǒng)為MFS，基礎文件系統(tǒng)為lighthttd+fastCGI+MooseFS，內(nèi)存為64 GB，硬盤為8 TB，SSD為480 GB，網(wǎng)卡為1000 Mb/s。

（3）MSS服務器配置：CentOS 7.0，CPU至強E3、4核、3.10 GHz，內(nèi)存16 GB，硬盤500 GB，網(wǎng)卡1000 Mb/s。

在現(xiàn)有網(wǎng)絡中分別對用RTMP與RUDP結(jié)合、RTMP和RUDP實現(xiàn)的消息傳輸性能進行了測試和比較。

6.1 ? RTMP與RUDP結(jié)合同RTMP和RUDP的測試與比較

對RTMP與RUDP相結(jié)合同RTMP和RUDP協(xié)議方式發(fā)送消息進行了比較性的測試，方法是：對主播與用戶之間發(fā)送相同的消息量參數(shù)，用戶在接收到相同的消息后，發(fā)送一個異步消息給主播，測試主播收到用戶回發(fā)的異步消息后記錄消息發(fā)送次數(shù)和當前系統(tǒng)運行時間（tick數(shù)），根據(jù)運行時間和消息數(shù)計算出異步通信效率。每個消息的長度為sizeof

（T_MSG）+50=90。實驗結(jié)果如表1所示。

式中，表示通信效率，N表示通信的消息數(shù)，L表示每個消息的長度，T表示通信的時間，t表示每秒的tick數(shù)。

6.2 ? 通信效率測試結(jié)果分析

（1） 使用RTMP與RUDP結(jié)合發(fā)送異步消息的平均效率為=0.841 Mb/s，使用RTMP發(fā)送異步消息的平均效率為=0.652 Mb/s，異步通信效率提高百分比為：

由式（2）可知，在使用異步消息通信時，使用RTMP與RUDP結(jié)合比使用RTMP的通信效率提高了28.99%。

（2）使用RTMP與RUDP結(jié)合發(fā)送異步消息的平均效率為=0.841 Mb/s，使用RUDP發(fā)送異步消息的平均效率為=0.761 Mb/s，異步通信效率提高百分比為：

由式（3）可知，在使用異步消息通信時，使用RTMP與RUDP結(jié)合比使用RUDP的通信效率提高了13.50%。

7 ? 結(jié)論（Conclusion）

本文介紹了基于內(nèi)容分發(fā)網(wǎng)絡的實時流媒體直播系統(tǒng)，采用先進的流媒體服務器集群技術(shù)，在傳輸服務器接收流媒體信息時采用RUDP協(xié)議，在傳輸服務器將流媒體信息推送至媒體流服務器時采用RTMP協(xié)議。RUDP主要為了彌補RTMP復雜網(wǎng)絡環(huán)境下傳輸信號差的缺陷，通過內(nèi)容分發(fā)網(wǎng)絡設計，可以極大地提升系統(tǒng)所要求支持的并發(fā)性流量和數(shù)目。通過在實際網(wǎng)絡環(huán)境中的測試，表明該技術(shù)可以極大地提高整個系統(tǒng)的分發(fā)效率，提高復雜網(wǎng)絡環(huán)境下直播系統(tǒng)中音視頻流媒體的傳輸質(zhì)量和傳輸效率。該技術(shù)值得更廣泛地研究與應用。

參考文獻（References）

[1] 李聞斌，龐璐寧，黃晟.實時流媒體傳輸系統(tǒng)中關鍵技術(shù)的研究與實現(xiàn)[J].信息通信，2020，216（12）：159-161.

[2] 翁小松，張征.基于Storm的流媒體實時傳輸系統(tǒng)[J].計算機系統(tǒng)應用，2020，29（6）：64-72.

[3] 李靜，王軍政，沈位.基于B/S和流媒體技術(shù)的遠程監(jiān)控系統(tǒng)研究[J].北京理工大學學報，2018，28（8）：682-686.

[4] 陳炯.傳輸協(xié)議RUDP的分析研究及改進[D].成都：電子科技大學，2008.

[5] 張印.基于RTMP的流媒體系統(tǒng)的設計與實現(xiàn)[D].成都：電子科技大學，2015.

[6] 胡廣.基于RUDP的可靠數(shù)據(jù)傳輸研究[D].武漢：武漢理工大學，2006.

[7] 李國棟，張琳琳，柳長安.基于RUDP的視頻傳輸技術(shù)研究[J].計算機工程，2006，24（12）：226-228.

[8] 王海軍，劉彩霞，程東年.一種基于UDP的可靠傳輸協(xié)議分析與研究[J].計算機應用與研究，2005，22（11）：181-183.

[9] 李濤，韓鵬，侯冠東，等.ORUDP協(xié)議棧設計與FPGA實現(xiàn)[J].計算機工程，2019，16（08）：2-10.

[10] 呂昊.基于RTMP協(xié)議的嵌入式流媒體系統(tǒng)的設計與實現(xiàn)[D].北京：北京郵電大學，2019.

作者簡介：

蘇永紅（1980-），女，碩士，講師.研究領域：網(wǎng)絡通信，網(wǎng)絡安全，分布式計算.