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

于 波 ,繆紅娣 ,2

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

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

于 波1,繆紅娣1,2

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

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

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

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

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

1 相關技術簡介

1.1 WebSocket與其他Web推送技術

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

Flash XML Socket技術:用戶在安裝了 Flash 播放器之后,根據 Flash 提供的相應的 XML Socket類,利用JavaScript直接調用Flash提供相應的接口與服務器端的套接口進行相關通訊.服務器端返回的XML格式的傳送信息,之后在web端顯示出HTML頁面的內容.采用該技術需要安裝相應的插件.

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

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

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

表1 Web 推送技術對比

1.2 WebRTC

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

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

2 核心模塊設計

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

圖1 模塊劃分

2.1 連接模塊

2.1.1 WebSocket連接

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

表2 WebSocket的連接模塊函數說明

2.1.1 PeerCon 模塊

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

表3 PeerCon 模塊主要函數說明

2.2 音視頻通信模塊

Alpha和Beta進入同一個房間,連入服務器進行通信.當Alpha(或 Beta)點擊瀏覽器調用該應用時,便下載相關的HTML頁以及Javacscript并通過WebSocket保持瀏覽器的持久連接.

2.2.1 呼叫流程

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

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

2.2.2 被呼叫流程

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

2.3 文件傳輸模塊

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

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

(2)無需服務器中轉即可實現(xiàn)數據的交換.

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

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

2.3.1 文件讀取與分片

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

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

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

2.3.2 文件傳輸與碎片組裝

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

圖2 用戶通信流程

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

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

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

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

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

圖4 文件接收流程

2.3.3 文件信令控制

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

3 性能測試

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

圖5 文件分片傳輸

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

4 結語

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

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

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

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

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

5王令宇.基于SaaS模式的即時通信平臺的設計與實現(xiàn)[碩士學位論文].北京:北京郵電大學,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 權威指南.聲網Agora.io,譯.北京:機械工業(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 的多媒體通信模塊.計算機系統(tǒng)應用,2017,26(10):118–123.http://www.c-s-a.org.cn/1003-3254/5989.html

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