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

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

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

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

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

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

系統(tǒng)物理架構(gòu)采用三級(jí)交換網(wǎng)絡(luò)，主播將音視頻信息發(fā)送到MTS（Media Transfer Server， 媒體轉(zhuǎn)發(fā)服務(wù)器），MTS在發(fā)生故障時(shí)可以通過備份的MTS進(jìn)行房間遷移。MTS處于一級(jí)交換網(wǎng)絡(luò)，MTS將信息推流到二級(jí)交換網(wǎng)的MSS-Origin（Media Streaming Server of Origin， 源媒體流服務(wù)器），然后推流到分布式CDN集群。觀眾通過各種瀏覽器訪問MSS-Edge（Media Streaming Server of Edge， 邊界媒體流服務(wù)器），MSS-Edge上的信息也可以回源到MSS-Origin端，數(shù)據(jù)流是可以雙向訪問和互動(dòng)的。系統(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)絡(luò)層，網(wǎng)絡(luò)層分為網(wǎng)絡(luò)適配層、Net API接口和Event Drive三個(gè)部分，其中Net API接口遵循TCP/UDP（Transmission Control Protocol/User Datagram Protocol， 傳輸控制協(xié)議/用戶數(shù)據(jù)報(bào)協(xié)議）協(xié)議[8]，Event Drive通過epol（）函數(shù)進(jìn)行LINUX系統(tǒng)設(shè)備訪問。接著是MTS層，MTS層包含房間管理、游客管理、認(rèn)證鑒權(quán)、媒體轉(zhuǎn)發(fā)、直播推流和故障管理這幾個(gè)功能。最上層是接口層，包括MRS Interface（媒體資源管理服務(wù)器接口）、MTM Interface（媒體任務(wù)管理服務(wù)器接口）、MSS Interface（媒體流服務(wù)器接口）、Client Interface（客戶端接口）。系統(tǒng)邏輯架構(gòu)如圖2所示。

2.3 ? 主要狀態(tài)圖設(shè)計(jì)

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

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

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

2.4.1 ? 創(chuàng)建房間

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

2.4.2 ? 刪除房間

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

2.4.3 ? 添加用戶

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

2.4.4 ? 刪除用戶

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

2.4.5 ? 設(shè)置角色

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）MTS集群配置：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 ? 結(jié)論（Conclusion）

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

參考文獻(xiàn)（References）

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

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

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

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

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

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

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

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

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

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

作者簡(jiǎn)介：

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