本文關(guān)鍵詞：移動互聯(lián)網(wǎng)WebRTC及相關(guān)技術(shù)，由筆耕文化傳播整理發(fā)布。

當前所在位置：中國論文網(wǎng) > 科技論文發(fā)表 > 移動互聯(lián)網(wǎng)WebRTC及相關(guān)技術(shù)

移動互聯(lián)網(wǎng)WebRTC及相關(guān)技術(shù)

發(fā)布日期： 2013-12-13 發(fā)布：  

  2013年6期目錄       本期共收錄文章18篇

　　針對Web實時通信（WebRTC）技術(shù)，提出一種WebRTC實時通信服務(wù)的改進設(shè)計方案。方案在客戶端側(cè)、服務(wù)端側(cè)、客戶端與服務(wù)端之間的通信等部分對WebRTC進行了改進。改進方案采用了HTML5 WebSocket技術(shù)、媒體協(xié)商與合成技術(shù)、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）/防火墻穿越技術(shù)、基于會話發(fā)起協(xié)議（SIP）棧的信令交互技術(shù)、P2P通信安全技術(shù)，較好地解決了跨瀏覽器運行、對客戶端側(cè)處理能力的過分依賴和帶寬消耗等問題，提高了系統(tǒng)的可擴展性。
中國論文網(wǎng)
　　WebRTC技術(shù)；應(yīng)用模式；跨瀏覽器運行；可擴展性
　　This paper describes an improved design for WebRTC technology. With this design， WebRTC communication at client side， server side， and between these two sides is improved. HTML5 WebSocket， media negotiation and synthesis， network address translator（NAT）/firewall traversal， Session Initiation Protocol （SIP） signaling interaction， and P2P communication security are used in this improved design. These solve problems such as cross-browse running， over-reliance on the client-side processing， and bandwidth problems. With this design， they can be made more scalable.
　　WebRTC technology； application model； running across browsers； extension
　　Web實時通信（WebRTC）[1]是一種構(gòu)建在Web瀏覽器基礎(chǔ)上的實時音視頻通信的技術(shù)。目標是在不安裝任何插件的前提下，開發(fā)者基于瀏覽器利用簡單的Web技術(shù)方便快捷地開發(fā)出豐富的實時Web多媒體應(yīng)用。
　　隨著網(wǎng)絡(luò)帶寬和瀏覽器版本的升級，WebRTC將會對傳統(tǒng)的實時通信業(yè)務(wù)造成巨大影響，正逐漸成為主流的實時通信方式。Google已開始在Android平臺的新版Chrome瀏覽器上提供WebRTC支持，預(yù)計2013年至少有10億終端支持WebRTC。中國著名的融合通信論壇CTI調(diào)查結(jié)果顯示[2]：87%電信企業(yè)考慮將WebRTC融入產(chǎn)品戰(zhàn)略，86.9%的受訪者表示W(wǎng)ebRTC對于他們的整體產(chǎn)品戰(zhàn)略而言具有十分重要的意義，49%的受訪者打算在未來1年內(nèi)部署WebRTC解決方案。
　　WebRTC由Google收購的Global IP Solution公司開發(fā)，并由Google在2010年向外開放，目前已成為實時通信的技術(shù)熱點，在W3C和IETF都成立了WebRTC相關(guān)的標準組，并得到業(yè)界越來越多廠商的支持。
　　與傳統(tǒng)的通信技術(shù)相比，WebRTC具備了如下明顯優(yōu)勢：
　�。�1）用戶使用方便，不需要安裝插件或者不同的客戶端。
　�。�2）用戶體驗一致性高，升級方便快捷，在服務(wù)器側(cè)完成。
　�。�3）基于JavaScript或超文本鏈接標記語言（HTML）開發(fā)簡單快捷。
　　（4）跨操作系統(tǒng)。開發(fā)者不需要為專門的操作系統(tǒng)開發(fā)不同的版本，一次開發(fā)統(tǒng)一版本。
　�。�5）開發(fā)者重點關(guān)注業(yè)務(wù)本身，不用太關(guān)注媒體處理。
　　1 WebRTC標準進展
　　負責(zé)WebRTC的標準組織是W3C和IETF。
　　W3C WebRTC負責(zé)定義客戶端側(cè)Javascript API，這些應(yīng)用編程接口（API）用于幫助Web應(yīng)用完成Web瀏覽器之間點對點或點對多點之間的實時通信。
　　W3C WebRTC標準組的主要成員由Web瀏覽器廠商組成，包括Google、Microsoft、Mozilla和Opera等。
　　IETF RTC-Web負責(zé)定義瀏覽器之間的實時通信協(xié)議和格式。該標準所關(guān)注的是媒體編解碼、網(wǎng)絡(luò)傳輸、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）/防火墻穿越以及安全與隱私等內(nèi)容。其主要成員包括Microsoft、Google、Skype、yahoo、Cisco和FT（Orange）等。
　　目前，WebRTC標準已經(jīng)提供了Network Stream、RTCPeerConnection以及DataChannel共3類API，分別用來完成媒體流的獲取、點到點的媒體、NAT/防火墻穿越連接的協(xié)商、瀏覽器之間音視頻流之外的數(shù)據(jù)傳輸。3類API中，Network Stream API和RTCPeerConnection API比較成熟，DataChannel API則是新增加的特性，目前的應(yīng)用還不太廣泛。
　　隨著WebRTC標準的不斷推進和完善，WebRTC標準得到越來越多瀏覽器廠商的支持。表1給出了目前各種瀏覽器對于WebRTC技術(shù)的支持情況。
　　在WebRTC技術(shù)的運用上，瀏覽器廠商Google、Mozilla，VoIP中間件平臺Mobicents[3]（目前已被Redhat收購）、通信廠商Livecome[4]以及一些Web即時通信服務(wù)開發(fā)人員都進行了相應(yīng)的探索，并提供了相應(yīng)的原型實現(xiàn)。
　　2 WebRTC運用模式
　　WebRTC應(yīng)用主要有3種模式：
　　（1）WebRTC接入傳統(tǒng)的音、視頻業(yè)務(wù)
　　電信運營商與解決方案提供商將WebRTC作為傳統(tǒng)音視頻業(yè)務(wù)中的一個新的接入方式，如傳統(tǒng)呼叫中心增加瀏覽器方式的接聽、傳統(tǒng)會控系統(tǒng)增加瀏覽器終端等。 　　該模式重點解決WebRTC技術(shù)與傳統(tǒng)應(yīng)用架構(gòu)之間的差異和兼容問題：在WebRTC與傳統(tǒng)的應(yīng)用架構(gòu)之間，加入一個負責(zé)協(xié)調(diào)兩者差異的網(wǎng)關(guān)設(shè)備。
　　中興通訊WebRTC-IMS網(wǎng)關(guān)的接入方案，由WebRTC-IMS網(wǎng)關(guān)負責(zé)WebRTC與傳統(tǒng)IMS網(wǎng)絡(luò)之間的信令轉(zhuǎn)換、媒體流中繼以及NAT/防火墻穿越機制的轉(zhuǎn)換等工作。該方案具有下面的優(yōu)勢：
　　·增加傳統(tǒng)音視頻業(yè)務(wù)的軟接入方式，同時不需要為增加瀏覽器的接入做各種各樣的插件，大大減少了傳統(tǒng)瀏覽器客戶端的工作量。
　　·利用傳統(tǒng)業(yè)務(wù)架構(gòu)中的媒體服務(wù)器來強化即時通信中音視頻的處理能力，提升WebRTC接入的用戶體驗。
　　·可有效減少WebRTC接入對客戶端側(cè)處理能力的依賴和帶寬消耗。
　　（2）輕量級Web實時通信服務(wù)
　　利用WebRTC標準接口，開發(fā)輕量級Web視頻通話、Web音視頻會議中心是WebRTC的典型應(yīng)用場景。業(yè)界比較有代表性的原型包括Mobicents SIP Servlet[5]、Conversat.io[6]（現(xiàn)更名為Talky.io）、Chatdemo[7]等。
　　這種場景中，各原型在應(yīng)用架構(gòu)上基本上都采用了“去中心化”的設(shè)計思路：將多方之間的媒體協(xié)商過程分解成多個端到端的協(xié)商過程，傳統(tǒng)上由媒體服務(wù)器來完成的功能都轉(zhuǎn)移到了客戶端瀏覽器側(cè)。
　　當兩個瀏覽器實時通信時，通過信令交互獲取到雙方都支持的媒體格式和傳輸協(xié)議后，直接按照約定好的原則進行端到端的媒體傳輸。一旦有第三方加入進來，則由第三方代理分別在信令層面發(fā)起對前兩個用戶代理的協(xié)商，之后的過程與兩方之間通信過程一致。
　　該方案的優(yōu)勢是開發(fā)簡單快捷，基本不關(guān)注媒體處理。缺點是隨著瀏覽器端的增加，每個瀏覽器需要向其他瀏覽器端分別發(fā)送媒體流，同時接受來自其他瀏覽器端的媒體流，這對瀏覽器端的媒體處理能力提出了較高的要求，相對應(yīng)的帶寬需求也比較大。
　�。�3）綜合型的Web實時通信服務(wù)
　　在終端采用WebRTC，在服務(wù)側(cè)結(jié)合電信的多點控制單元（MCU）等設(shè)備，解決掉混頻和混音問題，，增強對各種應(yīng)用場景的支持，同時減輕對網(wǎng)絡(luò)的壓力。
　　綜合型的Web實時通信服務(wù)通過采用輕量級Web實時通信服務(wù)當中的點對點以及點對多點的媒體協(xié)商策略，讓客戶端之間就可以完成媒體協(xié)商過程，進而使得整體應(yīng)用架構(gòu)變得簡潔。同時，它還在服務(wù)側(cè)引入了多點控制單元來接管多方媒體流的處理，較大程度地緩解了客戶端側(cè)處理壓力，給WebRTC在各種場景中的充分應(yīng)用創(chuàng)造了有利條件。
　　綜合型的Web實時通信服務(wù)融合了前兩種方案各自的優(yōu)勢，能夠適應(yīng)大規(guī)模應(yīng)用。
　　3 WebRTC技術(shù)方案分析
　　與改進
　　3.1 當前WebRTC應(yīng)用存在的技術(shù)
　　問題
　　作為一種發(fā)展中的技術(shù)和標準，WebRTC還有諸多不夠完善之處，這些缺陷給WebRTC的利用帶來了不少挑戰(zhàn)：
　　·與傳統(tǒng)的會議視頻業(yè)務(wù)相比，媒體控制弱，需要增強以適應(yīng)復(fù)雜會議控制的需求。
　　·媒體流的P2P直傳對給客戶端的處理能力帶來挑戰(zhàn)。2到4個參與方比較合適，超過4個參與方對客戶端處理能力都提出了很高的要求。業(yè)界應(yīng)用PC端參與方很少超過6個參與方。如果是移動客戶端則問題更大。
　　·端到端直傳大量媒體流的上傳下載帶來巨大的帶寬消耗。不僅增加了用戶使用服務(wù)的成本，對用戶體驗造成不良的沖擊。
　　·當前瀏覽器廠商在WebRTC標準Javascript API和HTML5 API的設(shè)計上，存在命名或方法調(diào)用的差異[8-9]，在一個瀏覽器正常運行的WebRTC應(yīng)用，在另一套瀏覽器環(huán)境可能會出現(xiàn)異常。
　　·通過WebRTC Javascript API直接操作本地音視頻媒體文件和相關(guān)設(shè)備能力也為系統(tǒng)的安全性帶來挑戰(zhàn)[10]。
　　3.2 設(shè)計方案的改進
　　為了有效解決跨瀏覽器運行、減少應(yīng)用運行對客戶端側(cè)處理能力的依賴和帶寬消耗，同時提高系統(tǒng)的可擴展性，本文提出了一種利用WebRTC技術(shù)開發(fā)輕量級Web實時通信服務(wù)的改進思路，其整體框架如圖1所示。
　　圖1主要包括客戶端側(cè)、服務(wù)端側(cè)、客戶端與服務(wù)端之間的通信，說明如下：
　�。�1）客戶端側(cè)
　　在客戶端側(cè)，Browser負責(zé)提供WebRTC標準接口支持，SIP Stack負責(zé)提供客戶端側(cè)會話發(fā)起協(xié)議（SIP）[11]信令的處理。WebRTC封裝庫建立在Browser WebRTC Javascript API和SIP Stack的基礎(chǔ)上，解決客戶端與服務(wù)端雙向通信、媒體及防火墻穿越連接協(xié)商以及跨瀏覽器運行等方面的問題。Webrtc APP負責(zé)完成用戶界面展示。
　�。�2）服務(wù)端側(cè)
　　服務(wù)端側(cè)包括交互式連接建立（ICE）[12]服務(wù)器、MCU、Web服務(wù)器以及信令服務(wù)器4個網(wǎng)元。其中，ICE服務(wù)器用于與客戶端側(cè)瀏覽器交互，幫助客戶端獲取到能夠穿越NAT/防火墻的ICE地址。MCU負責(zé)對各方代理傳輸過來的視頻流進行合成，并將最終合成的多方視頻流發(fā)送給各方代理。Web服務(wù)器用于運行Webrtc APP。信令服務(wù)器用于對客戶端的SIP請求進行處理和路由分發(fā)，并輔助完成用戶認證、用戶管理、會議控制與錄制、會議計費等功能。在實際的部署中，上述4種網(wǎng)元既可以單獨部署，也可以根據(jù)需要部署在同一臺或幾臺服務(wù)器當中。
　　（3）客戶端與服務(wù)端之間的通信
　　NAT/防火墻穿越的客戶端程序與交互式連接建立服務(wù)器通信遵從數(shù)據(jù)報協(xié)議通過網(wǎng)絡(luò)地址轉(zhuǎn)換簡單穿越（STUN）[13]、中繼NAT實現(xiàn)的穿透（TURN）[14]等標準協(xié)議，采用數(shù)據(jù)報協(xié)議（UDP）進行消息傳輸�？蛻舳伺c服務(wù)端雙向的SIP交互采用SIP over WebSocket[15]技術(shù)。 　　客戶端與服務(wù)端之間媒體流傳輸采用實時傳送協(xié)議/實時傳輸控制協(xié)議（RTP/RTCP）格式。Web服務(wù)的訪問采用超文本傳輸協(xié)議（HTTP）。
　　基于上述框架，一個大致的多方視頻通信過程可以簡要描述如下：
　　·用戶通過客戶端瀏覽器訪問Web服務(wù)器提供的服務(wù)。
　　·客戶端之間通過信令服務(wù)器注冊并借助ICE服務(wù)器完成多方之間點多多點的媒體協(xié)商過程。
　　·MCU接收各方按照約定的格式傳送的本地音視頻流，并將其按照相關(guān)策略進行混音、混頻等后臺處理，然后將得到的合成流再返回給參會的各方。
　　·各方瀏覽器完成媒體流的接收和顯示。
　　·建立起多方通信過程。
　　3.3 采用的關(guān)鍵技術(shù)
　�。�1）HTML5 WebSocket技術(shù)
　　傳統(tǒng)實時通信中，通常采用輪詢或長輪詢的方式來實現(xiàn)。這種通過增加客戶端請求頻次或延長服務(wù)端響應(yīng)時段的做法，雖然在一定程度改善實時性服務(wù)程序的體驗，但其基于HTTP的請求響應(yīng)模式，無法做到真正的實時。此外，還會給客戶端的帶寬和服務(wù)端的資源消耗帶來額外的負擔。
　　為了減少實時通信的延遲，降低帶寬消耗，HTML5工作組制訂了WebSocket通信標準。通俗地說，HTML5 WebSocket是通過在Web上的單個Socket定義了一個全雙工通信信道，進而為Web實時通信帶來顯著的改善。
　　在客戶端與服務(wù)端通信之前，首先需要完成一次WebSocket握手過程來建立雙方之間的連接。一旦連接建立起來，客戶端與服務(wù)端之間就可以雙向進行數(shù)據(jù)的發(fā)送或接收。這樣，當服務(wù)端有數(shù)據(jù)更新時，就可以直接推送到客戶端側(cè)，而不需要等待客戶端側(cè)是請求。
　　在音視頻通信這類實時性非常強的應(yīng)用場景中，采用HTML5 WebSocket技術(shù)可以極大地提高服務(wù)的實時性，并通過降低傳輸載荷減少帶寬消耗。
　�。�2）媒體協(xié)商與合成技術(shù)
　　上述改進思路中，各方媒體信息的協(xié)商還是放在客戶端自己來完成。對于多方參會情形而言，在實現(xiàn)上還是需要將多方的協(xié)商過程分解成多個端到端的協(xié)商過程，可選的協(xié)商策略包括圖2、圖3所示的兩種實現(xiàn)方法。
　　理論上來說，在多方之間的媒體協(xié)商完畢之后，就可以實現(xiàn)多方之間的媒體流的直傳通信了。但這種應(yīng)用方式會帶來顯著的問題，以4方會議為例，每一方需要同時向外發(fā)送3路本地視頻流，同時接收其他3方的視頻流。這樣，客戶端側(cè)能夠支撐的用戶量非常有限，而且網(wǎng)絡(luò)帶寬消耗巨大。
　　為了解決該問題，需要在服務(wù)端借助MCU完成媒體流的轉(zhuǎn)換、合成等工作。引進MCU之后，每個客戶端只需要向外發(fā)送本地的一路視頻流，同時也只需要接收從MCU合成后的一路視頻流。無疑，這將給系統(tǒng)的性能帶來極大的改善。
　　（3）NAT/防火墻穿越技術(shù)
　　在跨局域網(wǎng)環(huán)境中使用Web音視頻通信時，必須要有一套穿越NAT/防火墻的設(shè)備來輔助完成媒體流的路由傳輸。
　　在IETF-RTC Web標準中，規(guī)定了客戶端瀏覽器當中WebRTC需要支持ICE框架，這樣服務(wù)端就需要提供相應(yīng)的ICE服務(wù)器。
　　在穿越方案的選擇上，同時支持STUN和TURN兩種服務(wù)器。其中，STUN服務(wù)器用于完成非對稱NAT穿越，TURN則負責(zé)完成對非對稱NAT穿越及防火墻的穿越。通過兩者的協(xié)同，保障WebRTC媒體流的暢通。
　　（4）基于SIP棧的信令交互技術(shù)
　　在W3C WebRTC標準中，并沒有對客戶端與服務(wù)端之間的信令進行標準化。
　　SIP以其簡單、靈活和可擴展等特性，受到業(yè)界越來越多的關(guān)注和支持，并已成為下一代通信事實上的標準。
　　為完成客戶端與服務(wù)端SIP信令交互，需要在客戶端側(cè)使用Mobicents JAIN-SIP標準的參考實現(xiàn)來提供SIP棧服務(wù)，服務(wù)端側(cè)利用SIP Servlet來處理客戶端側(cè)請求或進行路由分發(fā)。一個服務(wù)端充當代理實現(xiàn)路由分發(fā)的大致交互過程如圖4所示。
　�。�5）P2P通信安全技術(shù)
　　為了防止瀏覽器程序?qū)Ρ镜刭Y源的濫用，在WebRTC即時通信服務(wù)框架中，我們參照文獻[10]引入了沙箱技術(shù)。該技術(shù)的核心思路是，將外部站點劃分成可信站點和不可信站點。其中，可信站點認為是安全的，能夠訪問一切的本地資源（或者受限的部分資源）；不可信站點由于存在安全隱患，將其放入沙箱之中，不能直接訪問本地資源。
　　對于可信與非可信站點的甄別，采用IETF中的同源策略（SOP）[16]加以考慮：即一個網(wǎng)頁的安全性由其來源決定，需要對其所使用的協(xié)議、主機和端口進行同源匹配；為每一個起源都分配一個與之匹配的安全訪問策略，比如從一個站點（記為A）訪問另一個目的站點（記為B）的資源時，不允許訪問B站點的本地加密文件等等。
　　此外，為了防止惡意站點通過Javascript API進行分布式拒絕服務(wù)攻擊（DDOS）[17]攻擊或通過瀏覽器協(xié)議包仿真域名服務(wù)器（DNS）攻擊公司的DNS，因此還引入像定期掃描、檢查訪問者來源等輔助防御措施。
　　4 結(jié)束語
　　當前WebRTC技術(shù)和標準尚不成熟，在實用中還存在不少問題，如很多功能尚未定義、不同瀏覽器間的不兼容、客戶端側(cè)處理能力要求較高以及高帶寬消耗等問題。本文提出一種WebRTC實時通信服務(wù)的改進設(shè)計思路，較好地解決了當前WebRTC技術(shù)應(yīng)用面臨的主要問題，對于WebRTC技術(shù)的產(chǎn)品化具有重要的借鑒價值和現(xiàn)實意義。
　　隨著LTE、Wi-Fi和有線寬帶的普及、帶寬得到解決，PC和各種移動終端處理能力大幅提升，各種終端上瀏覽器基本都會支持WebRTC，基于WebRTC的實時音視頻通信會成為一種普遍服務(wù)。綜合型的Web通信服務(wù)方案將會成為一種較為理想的應(yīng)用模式。 　　HTML5和WebRTC技術(shù)和標準正走向成熟、快速普及，傳統(tǒng)的IM、桌面共享、電子白板、音視頻會議錄制等將進一步朝Web化的方向發(fā)展，并將最終融合到一個完整的基于Web的統(tǒng)一通信系統(tǒng)當中。屆時，用戶基于瀏覽器就可以進行全方位的溝通與交流，人際交互將變得更加簡便、快捷。
　　參考文獻
　　[1] WebRTC 1.0： Real-time Communication Between Browsers [EB/OL]. [2013-08-21]. http：//www.w3.org/TR/Webrtc/#rtcpeerconnection.
　　[2] CTI論壇調(diào)查 [EB/OL]. [2013-09-11]. http：//www.ctiforum.com/news/baogao/370610.html.
　　[3] Mobicents Project. [EB/OL]. [2013-07-15]. http：//hudson.jboss.org/hudson/view/All/job/Mobicents/.
　　[4] livecome Webrtc demo [EB/OL]. [2013-03-11]. http：//lwork.hk：8086.
　　[5] Mobicents SIP Servlet. [EB/OL]. [2013-07-22]. http：//dev.telestax.com/sipservlets/wiki/HTML5WebRTCVideoApplication
　　[6] talky.io [EB/OL]. [2013-07-15]. http：//talky.io.
　　[7] chatdemo [EB/OL]. [2013-08-18]. http：//ishare.iask.sina.com.cn/f/35083616.html.
　　[8] simpleWebrtc [EB/OL]. [2013-08-17]. https：//github.com/HenrikJoreteg/SimpleWebRTC.
　　[9] Webrtc.io [EB/OL]. [2013-09-11]. https：//github.com/WebRTC/Webrtc.io-client/blob/master/lib/ Webrtc.io.js.
　　[10] 李琳. 基于Web瀏覽器的P2P實時通信的安全性分析 [J]. 計算機安全， 2012，06：54-56.
　　[11] Session Initiation Protocol [EB/OL]. [2013-04-19]. http：//www.rfc-editor.org/rfc/rfc3261.txt.
　　[12] RFC5245-Interactive Connectivity Establishment [EB/OL]. [2012-11-17]. http：//www.packetizer.com /rfc/rfc5245/.
　　[13] RFC3489-Simple Traversal of User Datagram Protocol [EB/OL]. [2013-06-16]. http：//
　　[14] RFC5766-Traversal Using Relays around NAT （TURN）： Relay Extensions to Session Traversal Utilities for NAT （STUN） [EB/OL]. [2013-08-22]. http：//www.rfc-editor.org/info/rfc5766.
　　[15] draft-ietf-sipcore-sip-Websocket-04 [EB/OL]. [2013-08-22]. http：//tools.ietf.org/html/draft-ietf-sipcore -sip-Websocket-04.
　　[16] IETF-Security Considerations for RTC-Web draft-ietf-rtcWeb-security-02 [EB/OL]. [2012-03-12]. https：//datatracker.ietf.org/doc/draft-ietfrtcWeb-security.
　　[17] 吳敏， 王汝傳， 王治平. 基于支持向量機的P2P網(wǎng)絡(luò)DoS攻擊檢測 [J]. 計算機技術(shù)與發(fā)展， 2009，11：151-154.

  本文關(guān)鍵詞：移動互聯(lián)網(wǎng)WebRTC及相關(guān)技術(shù)，由筆耕文化傳播整理發(fā)布。