于 波 ,繆紅娣 ,2

1(中國科學(xué)院 沈陽計(jì)算技術(shù)研究所,沈陽 110168)2(中國科學(xué)院大學(xué),北京 100049)

基于WebRTC的多媒體通信模塊①

于 波1,繆紅娣1,2

1(中國科學(xué)院 沈陽計(jì)算技術(shù)研究所,沈陽 110168)2(中國科學(xué)院大學(xué),北京 100049)

傳統(tǒng)的 Web IM 要求通信雙方在瀏覽器中安裝插件 (如 Adobe Flash Player),這不但降低了用戶體驗(yàn),還增加了開發(fā)者對插件開發(fā)、更新及維護(hù)的繁瑣工作.此外,傳統(tǒng)的Web IM主要采用了定時訪問服務(wù)器的方法(即輪詢方式)實(shí)現(xiàn)瀏覽器與服務(wù)器之間的交互,該方式降低了實(shí)時性且增加了對服務(wù)器資源的消耗.針對上述問題,本文采用WebSocket連接技術(shù)使得瀏覽器與服務(wù)器之間能夠通過長連接方式進(jìn)行數(shù)據(jù)交互,該方式提高了實(shí)時性,降低了對服務(wù)器的負(fù)載.然后,本文依據(jù)提供的WebRTC API,實(shí)現(xiàn)了一個具備音視頻通信以及文件傳輸功能的多媒體通信模塊.通過MVC三層架構(gòu)模式,對該模塊進(jìn)行了具體劃分與實(shí)現(xiàn).最后通過測試表明該設(shè)計(jì)能夠滿足用戶的基本功能需求.

WebRTC; WebSocket; 視頻通信; 文件傳輸

傳統(tǒng)的Web IM采用基于Ajax輪詢或是Comet的信令傳輸方式實(shí)現(xiàn)瀏覽器與服務(wù)器的數(shù)據(jù)交互.二者存在不同方面的缺陷.通過Ajax方式可以更新局部界面,減少了響應(yīng)中傳輸?shù)臄?shù)據(jù)量,但可能會導(dǎo)致大量請求的產(chǎn)生,浪費(fèi)了網(wǎng)絡(luò)資源,增加了服務(wù)器負(fù)載.而在Comet方式中,可以實(shí)時更新內(nèi)容,但為了保持響應(yīng),一次連接的時間會增加,為了保持瀏覽器與服務(wù)器之間連接的持久性需要消耗大量的資源.

本文采用WebSocket技術(shù),它通過瀏覽器與服務(wù)器之間建立持久連接的方式進(jìn)行數(shù)據(jù)的雙向通信,減少了連接服務(wù)器產(chǎn)生的開銷,降低了對網(wǎng)絡(luò)帶寬的占用,有效解決了Ajax和Comet造成的問題.本文還結(jié)合 WebRTC(Web Real-Time Commmunication,Web 實(shí)時通信)技術(shù),設(shè)計(jì)了一個多媒體通信模塊,實(shí)現(xiàn)了音視頻通信以及文件傳輸?shù)墓δ?相比于傳統(tǒng)的Web IM,其無需通信雙方在瀏覽器中安裝插件(如Adobe flash),也不要求開發(fā)者對音視頻數(shù)據(jù)進(jìn)行處理,只需要專注網(wǎng)頁的JavaScript程序的開發(fā).

1 相關(guān)技術(shù)簡介

1.1 WebSocket與其他Web推送技術(shù)

WebSocket是HTML5的一項(xiàng)新技術(shù),實(shí)現(xiàn)了瀏覽器與服務(wù)器之間的全雙工通信.WebSocket是建立在TCP協(xié)議之上的一個獨(dú)立的協(xié)議,IETF在2011年12月將其定義為標(biāo)準(zhǔn).它是建立在HTTP基礎(chǔ)上的協(xié)議,由客戶端發(fā)起連接,并使用HTTP協(xié)議的101狀態(tài)碼進(jìn)行協(xié)議切換.一旦WebSocket連接建立,瀏覽器和服務(wù)器之間就創(chuàng)建了持久性的連接,并允許數(shù)據(jù)進(jìn)行雙向傳送.由于其連接具有持久性,不需要再進(jìn)行連接的頻繁創(chuàng)建,節(jié)省了服務(wù)器資源,也減少了網(wǎng)絡(luò)帶寬的占用.同時,WebSocket頭部的信息量很小,因此通訊的信息量也相應(yīng)縮小,流量的開銷削減.

Flash XML Socket技術(shù):用戶在安裝了 Flash 播放器之后,根據(jù) Flash 提供的相應(yīng)的 XML Socket類,利用JavaScript直接調(diào)用Flash提供相應(yīng)的接口與服務(wù)器端的套接口進(jìn)行相關(guān)通訊.服務(wù)器端返回的XML格式的傳送信息,之后在web端顯示出HTML頁面的內(nèi)容.采用該技術(shù)需要安裝相應(yīng)的插件.

Ajax輪詢:客戶端在處理完服務(wù)器端返回的相應(yīng)信息后,會再一次發(fā)出請求,重新建立連接.如果服務(wù)器端此時有新的數(shù)據(jù)達(dá)到,服務(wù)器端將會對信息進(jìn)行保存,由客戶端通過建立連接,之后一次性的取回所有信息并進(jìn)行處置.該種方式不需要安裝插件,但存在多次連接的可能,增加了服務(wù)器的負(fù)載.

基于Iframe的流方式:Iframe是一種HTML標(biāo)記,通過在HTML頁面中嵌入隱藏幀,將該幀的src屬性設(shè)置為對一個長連接的請求,以此來完成客戶端與服務(wù)器端之間的數(shù)據(jù)信息的傳輸.

WebSocket技術(shù)與其他推送技術(shù)在是否需要插件、重連次數(shù)以及對瀏覽器的兼容性這幾個方面的對比如表1.

表1 Web 推送技術(shù)對比

1.2 WebRTC

WebRTC技術(shù)是一個基于標(biāo)準(zhǔn)化的行業(yè)性開源項(xiàng)目,旨在將實(shí)時通訊模塊引入到所有瀏覽器中,并通過標(biāo)準(zhǔn)的HTML5標(biāo)簽和JavaScript API將即時通訊功能提供給Web開發(fā)者.

WebRTC系統(tǒng)架構(gòu)主要分三層:上層是面向第三方開發(fā)者的WebRTC標(biāo)準(zhǔn)API(JavaScript),方便開發(fā)者使用; 中間層主要包括相應(yīng)的音頻引擎、視頻引擎、數(shù)據(jù)傳輸模塊,是WebRTC技術(shù)的核心實(shí)現(xiàn); 底層包括音視頻的采集和網(wǎng)絡(luò)IO,由相應(yīng)的瀏覽器廠商進(jìn)行自主實(shí)現(xiàn).瀏覽器之間通過PeerConnection API對雙向媒體流進(jìn)行管理; 使用 JavaScript會話建立協(xié)議JSEP(JavaScript session establishment protocol)對媒體參數(shù)進(jìn)行協(xié)商.在建立了 DataChannel之后,使用SCTP協(xié)議對媒體數(shù)據(jù)流進(jìn)行可靠地傳輸.

2 核心模塊設(shè)計(jì)

多媒體通信模塊主要分為UI界面層; 業(yè)務(wù)邏輯層以及連接層.其中業(yè)務(wù)邏輯層主要實(shí)現(xiàn)了文件傳輸以及音視頻通信功能模塊; 連接層實(shí)現(xiàn)了瀏覽器與服務(wù)器之間的雙向通信,并建立了對等連接,實(shí)現(xiàn)了音視頻以及文件媒體流的傳輸通道.模塊化分如圖1.

圖1 模塊劃分

2.1 連接模塊

2.1.1 WebSocket連接

WebSocket連接負(fù)責(zé)瀏覽器與服務(wù)器之間的數(shù)據(jù)交互.在HTTP連接建立后,需要完成一次“握手”操作才能實(shí)現(xiàn)瀏覽器與服務(wù)器之間的持久連接.該模塊在與服務(wù)器建立連接時,調(diào)用connect方法,并對onpen,onmessage,onerror及onclose的回調(diào)函數(shù)進(jìn)行相應(yīng)的實(shí)現(xiàn).關(guān)于WebSocket的連接模塊函數(shù)如表2.

表2 WebSocket的連接模塊函數(shù)說明

2.1.1 PeerCon 模塊

本模塊通過信令交換了對等連接兩端的Session信息,網(wǎng)絡(luò)配置(ice候選項(xiàng)后)實(shí)現(xiàn)了瀏覽器之間的對等連接,為瀏覽器間的直接通信提供了條件.并建立了數(shù)據(jù)通道DataChannel,經(jīng)由此通道可以進(jìn)行各種類型數(shù)據(jù)的傳輸.PeerCon模塊主要函數(shù)的說明如表3.

表3 PeerCon 模塊主要函數(shù)說明

2.2 音視頻通信模塊

Alpha和Beta進(jìn)入同一個房間,連入服務(wù)器進(jìn)行通信.當(dāng)Alpha(或 Beta)點(diǎn)擊瀏覽器調(diào)用該應(yīng)用時,便下載相關(guān)的HTML頁以及Javacscript并通過WebSocket保持瀏覽器的持久連接.

2.2.1 呼叫流程

Alpha點(diǎn)擊網(wǎng)頁上的呼叫按鈕啟動與Beta的通話,先調(diào)用getUserMedia函數(shù),控制本機(jī)的音視頻設(shè)備,獲取本地音視頻流.而后對PeerConnection對象進(jìn)行實(shí)例化,通過addStream將媒體流關(guān)聯(lián)到該對象中.設(shè)置本地sdp,并通過請求信令(offer)轉(zhuǎn)發(fā)給Beta,在接收到Beta的應(yīng)答(answer)后,解析出Beta的sdp消息,加載至瀏覽器內(nèi)核,完成呼叫建立.

其中信令類型為Json字符串,其格式為

2.2.2 被呼叫流程

Beta收到請求信令(offer)后,從中解析出Alpha的 sdp,并決定是否要接受通話請求.若接受請求,則實(shí)體化一個與Alpha請求相關(guān)的對等連接.Beta的瀏覽器確認(rèn)呼叫建立并且媒體流已經(jīng)產(chǎn)生.之后作為響應(yīng),產(chǎn)生一個包含媒體信息和ICE候選的信令信息answer,并傳回給Alpha.如圖2所示為用戶通信流程.

2.3 文件傳輸模塊

WebRTC不僅支持對等媒體的連接,還提供了一種靈活可配置的數(shù)據(jù)通道.基于此通道實(shí)現(xiàn)的文件與信息的傳輸有如下優(yōu)勢.

(1)DataChannel支持流量大,延遲低的連接,既穩(wěn)定可靠又不失靈活性.

(2)無需服務(wù)器中轉(zhuǎn)即可實(shí)現(xiàn)數(shù)據(jù)的交換.

(3)無需插件,即可實(shí)現(xiàn)文件的實(shí)時傳輸與共享.

在本模塊中,首先讀取文件數(shù)據(jù),使用PeerCon模塊在用戶間創(chuàng)建一個對等連接,并建立一個數(shù)據(jù)通道;對所選擇的文件進(jìn)行分片,并通過文件信令控制碎片傳輸.最后對碎片進(jìn)行組裝并提供下載.

2.3.1 文件讀取與分片

通過HTML5提供的File API規(guī)范使得用戶能夠與本地文件進(jìn)行交互.用戶通過表單選擇文件后,觸發(fā)了文件選擇框的change事件,通過files屬性獲取選定文件列表.然后通過FileReader的接口異步讀取文件內(nèi)容為DataURL.

如果要上傳的文件很小,則可以直接通過File API將其存儲為一個Blob對象,并通過數(shù)據(jù)通道進(jìn)行可靠地傳輸.

如果文件較大,則需要一個分片機(jī)制:將文件分成多個碎片(chunk),然后進(jìn)行分片發(fā)送.在發(fā)送過程中,數(shù)據(jù)包大小應(yīng)該控制在1200字節(jié),且文件塊上應(yīng)該附加一些便于對方識別的元數(shù)據(jù),如塊的ID.若文件的分片過小,分片數(shù)量將會增加,會導(dǎo)致傳輸延時的增加,此時可以對chunk進(jìn)行進(jìn)一步地封裝,將多個chunk封裝成一個block塊,如此便可節(jié)省很多的帶寬和CPU.

2.3.2 文件傳輸與碎片組裝

對于文件的傳輸有兩種方式,支持SCTP的可靠傳輸方式,其內(nèi)置了流量控制,可以進(jìn)行可靠的傳輸.以及不可靠的傳輸方式,雖然可以提升傳輸速率,但文件可能丟失,無法得到完整文件.因此需要進(jìn)行動態(tài)的流量控制和重傳機(jī)制.

圖2 用戶通信流程

為了保證接收到完整的文件以及所有的文件塊.在不可靠的傳輸方式上,接收端將請求它沒有的chunk,并監(jiān)控這些chunk,防止請求端沒有接收到回應(yīng).設(shè)置一個數(shù)據(jù)結(jié)構(gòu):PendingChunks,根據(jù)它來判斷哪些chunk沒有被請求到或者還沒有到達(dá).并通過監(jiān)控它來設(shè)置一個定時機(jī)制,決定一個請求何時被拋棄以及如何處理.

此外,可以通過動態(tài)調(diào)整數(shù)據(jù)片量的方式來控制流量.通過設(shè)置 SDP 中參數(shù)字段 b,定義最大寬帶.若所有請求發(fā)送成功,我們將窗口大小加一.若有一個失敗,則將窗口大小減去 2 *(丟棄的 chunk),且窗口大小不超過窗口的一半.如圖3所示為文件發(fā)送流程.

在接收方接收到文件塊之后,先對數(shù)據(jù)包進(jìn)行解析,判斷其是否為最后一個碎片.如果不是,則將碎片保存在離線存儲中,并等待下一個碎片.如果所有的碎片都接收完畢,則對碎片進(jìn)行組合,將其拼合為一個完整的文件,并進(jìn)行下載,方法如下:

圖3 文件發(fā)送流程

如圖4所示為文件接收流程.

圖4 文件接收流程

2.3.3 文件信令控制

在文件傳輸?shù)倪^程中,通過解析DataChannel上的文件類型包來確定文件信令的類型.主要的信令類型有請求發(fā)送request; 文件碎片chunk; 文件接收accept;文件拒絕refuse; 文件確認(rèn)ask.其中文件類型包定義為Json字符串,定義的格式為:

3 性能測試

測試環(huán)境為使用Node.js編寫的WebRTC服務(wù)器端,通過在 3000端口監(jiān)聽 WebSocket連接請求.根據(jù)分片的大小不同,對于傳輸1MB的文件,所需要的時間也會有所不同,如下圖所示.當(dāng)分片過小時,分片數(shù)據(jù)量增大,導(dǎo)致傳輸中延遲增加,文件傳輸總時間也會增加.當(dāng)傳輸?shù)姆制龃?總傳輸延遲減小,總傳輸時間就會趨于一個平穩(wěn)的值.如圖5所示為文件分片傳輸結(jié)果.

圖5 文件分片傳輸

在分片大小固定為40000B的情況下,對于傳輸不同大小的文件所需時間進(jìn)行測試.從測試結(jié)果中可以看出,傳輸時間基本趨于線性的增長.如圖6所示.

4 結(jié)語

WebRTC不但給我們帶來了基于瀏覽器的音視頻體驗(yàn),還給我們提供了無需插件,無需服務(wù)器中轉(zhuǎn)即可以實(shí)現(xiàn)文件傳輸?shù)臈l件.本文通過WebSocket連接模塊構(gòu)建起服務(wù)器與瀏覽器之間的數(shù)據(jù)交互.通過PeerCon模塊實(shí)現(xiàn)瀏覽器間的連接建立,為瀏覽器間音視頻通信提供基礎(chǔ); 同時為文件傳輸建立起數(shù)據(jù)通道Data-Channel.在本文中,文件通過分片以及重組的方式進(jìn)行傳輸,在不可靠傳輸方式時為其提供動態(tài)流量控制以及重傳機(jī)制保證文件的完整性.從最后的測試結(jié)果可以得出,該模塊實(shí)現(xiàn)了實(shí)時的音視頻聊天以及文件傳輸?shù)墓δ?

1屈振華,李慧云,張海濤,等.WebRTC 技術(shù)初探.電信科學(xué),2012,28(10):106–110.[doi:10.3969/j.issn.1000-0801.2012.10.018]

2付斌,楊鑫,王松,等.WebRTC 技術(shù)研究及其應(yīng)用.電信科學(xué),2013,29(9):108–112.

3林鴻,王松,楊鑫,等.基于 WebRTC 技術(shù)的應(yīng)用及平臺技術(shù)開發(fā)與設(shè)計(jì).電信科學(xué),2013,29(9):20–25,36.

4才鑫.基于WebRTC的多方多媒體通信系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文].北京:北京郵電大學(xué),2015.

5王令宇.基于SaaS模式的即時通信平臺的設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文].北京:北京郵電大學(xué),2015.

6Schaefer C,HO C,Harrop R.WebSocket.In:Sv C,HO C,Harrop R,eds.Pro Spring.4th ed.New York:Apress,2014:645–661.

7Johnston AB,Burnett DC.WebRTC:APIs and RTCWEB protocols of the HTML5 real-time web.St.Louis:Digital Codex LLC,2012.

8Nurminen JK,Meyn AJR,Jalonen E,et al.P2P media streaming with HTML5 and WebRTC.Proc.of 2013 IEEE Conference on Computer Communications Workshops.Turin,Italy.2013.63–64.

9Sredojev B,Samardzija D,Posarat D.WebRTC technology overview and signaling solution design and implementation.Proc.of the 2015 38th International Convention on Information and Communication Technology,Electronics and Microelectronics.Opatija,Croatia.2015.1006–1009.

10Janczukowicz E,Braud A,Tuffin S,et al.Evaluation of network solutions for improving WebRTC quality.Proc.of the 24th International Conference on Software,Telecommunications and Computer Networks.Split,Yugoslavia.2016.1–6.

11Johnston AB,Buenett DC.Web WebRTC 權(quán)威指南.聲網(wǎng)Agora.io,譯.北京:機(jī)械工業(yè)出版社,2016.

Multimedia Communication Module Based on WebRTC

YU Bo1,MIAO Hong-Di1,21(Shenyang Institute of Computer Technology,Chinese Academy of Sciences,Shenyang 110168,China)2(University of Chinese Academy of Sciences,Beijing 100049,China)

The traditional Web IM requires both sides to install plug-ins (such as Adobe Flash Player)in the browser,which does not only reduce the user experience,but also increases the developers’ tedious work for plug-in development,updating and maintenance.In addition,the traditional Web IM mainly adopts the method of the regular access server (the polling mode)to achieve the interaction between the browser and server,which reduces the real-time performance and increases the consumption of server resources.According to the problems above,this article implements the long connection between the browser and server and data interaction through WebSocket,which improves the real-time performance.Then on the basis of providing WebRTC API,we implement a module which performs the function of audio and video communication and file transfer.Through the MVC three-tier architecture model,we carry on the concrete division and implementation of the module.Finally,the test shows that the design can meet the basic functional requirements of the user.

WebRTC; WebSocket; video communication; file transport

于波,繆紅娣.基于 WebRTC 的多媒體通信模塊.計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(10):118–123.http://www.c-s-a.org.cn/1003-3254/5989.html

2017-01-17; 采用時間:2017-02-15