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

董振江 李從兵 王蔚 呂達(dá)

針對Web實(shí)時(shí)通信（WebRTC）技術(shù)，提出一種WebRTC實(shí)時(shí)通信服務(wù)的改進(jìn)設(shè)計(jì)方案。方案在客戶端側(cè)、服務(wù)端側(cè)、客戶端與服務(wù)端之間的通信等部分對WebRTC進(jìn)行了改進(jìn)。改進(jìn)方案采用了HTML5 WebSocket技術(shù)、媒體協(xié)商與合成技術(shù)、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）/防火墻穿越技術(shù)、基于會話發(fā)起協(xié)議（SIP）棧的信令交互技術(shù)、P2P通信安全技術(shù)，較好地解決了跨瀏覽器運(yùn)行、對客戶端側(cè)處理能力的過分依賴和帶寬消耗等問題，提高了系統(tǒng)的可擴(kuò)展性。

WebRTC技術(shù)；應(yīng)用模式；跨瀏覽器運(yùn)行；可擴(kuò)展性

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實(shí)時(shí)通信（WebRTC）[1]是一種構(gòu)建在Web瀏覽器基礎(chǔ)上的實(shí)時(shí)音視頻通信的技術(shù)。目標(biāo)是在不安裝任何插件的前提下，開發(fā)者基于瀏覽器利用簡單的Web技術(shù)方便快捷地開發(fā)出豐富的實(shí)時(shí)Web多媒體應(yīng)用。

隨著網(wǎng)絡(luò)帶寬和瀏覽器版本的升級，WebRTC將會對傳統(tǒng)的實(shí)時(shí)通信業(yè)務(wù)造成巨大影響，正逐漸成為主流的實(shí)時(shí)通信方式。Google已開始在Android平臺的新版Chrome瀏覽器上提供WebRTC支持，預(yù)計(jì)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í)時(shí)通信的技術(shù)熱點(diǎn)，在W3C和IETF都成立了WebRTC相關(guān)的標(biāo)準(zhǔn)組，并得到業(yè)界越來越多廠商的支持。

與傳統(tǒng)的通信技術(shù)相比，WebRTC具備了如下明顯優(yōu)勢：

（1）用戶使用方便，不需要安裝插件或者不同的客戶端。

（2）用戶體驗(yàn)一致性高，升級方便快捷，在服務(wù)器側(cè)完成。

（3）基于JavaScript或超文本鏈接標(biāo)記語言（HTML）開發(fā)簡單快捷。

（4）跨操作系統(tǒng)。開發(fā)者不需要為專門的操作系統(tǒng)開發(fā)不同的版本，一次開發(fā)統(tǒng)一版本。

（5）開發(fā)者重點(diǎn)關(guān)注業(yè)務(wù)本身，不用太關(guān)注媒體處理。

1 WebRTC標(biāo)準(zhǔn)進(jìn)展

負(fù)責(zé)WebRTC的標(biāo)準(zhǔn)組織是W3C和IETF。

W3C WebRTC負(fù)責(zé)定義客戶端側(cè)Javascript API，這些應(yīng)用編程接口（API）用于幫助Web應(yīng)用完成Web瀏覽器之間點(diǎn)對點(diǎn)或點(diǎn)對多點(diǎn)之間的實(shí)時(shí)通信。

W3C WebRTC標(biāo)準(zhǔn)組的主要成員由Web瀏覽器廠商組成，包括Google、Microsoft、Mozilla和Opera等。

IETF RTC-Web負(fù)責(zé)定義瀏覽器之間的實(shí)時(shí)通信協(xié)議和格式。該標(biāo)準(zhǔn)所關(guān)注的是媒體編解碼、網(wǎng)絡(luò)傳輸、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）/防火墻穿越以及安全與隱私等內(nèi)容。其主要成員包括Microsoft、Google、Skype、yahoo、Cisco和FT（Orange）等。

目前，WebRTC標(biāo)準(zhǔn)已經(jīng)提供了Network Stream、RTCPeerConnection以及DataChannel共3類API，分別用來完成媒體流的獲取、點(diǎn)到點(diǎn)的媒體、NAT/防火墻穿越連接的協(xié)商、瀏覽器之間音視頻流之外的數(shù)據(jù)傳輸。3類API中，Network Stream API和RTCPeerConnection API比較成熟，DataChannel API則是新增加的特性，目前的應(yīng)用還不太廣泛。

隨著WebRTC標(biāo)準(zhǔn)的不斷推進(jìn)和完善，WebRTC標(biāo)準(zhǔn)得到越來越多瀏覽器廠商的支持。表1給出了目前各種瀏覽器對于WebRTC技術(shù)的支持情況。

在WebRTC技術(shù)的運(yùn)用上，瀏覽器廠商Google、Mozilla，VoIP中間件平臺Mobicents[3]（目前已被Redhat收購）、通信廠商Livecome[4]以及一些Web即時(shí)通信服務(wù)開發(fā)人員都進(jìn)行了相應(yīng)的探索，并提供了相應(yīng)的原型實(shí)現(xiàn)。

2 WebRTC運(yùn)用模式

WebRTC應(yīng)用主要有3種模式：

（1）WebRTC接入傳統(tǒng)的音、視頻業(yè)務(wù)

電信運(yùn)營商與解決方案提供商將WebRTC作為傳統(tǒng)音視頻業(yè)務(wù)中的一個(gè)新的接入方式，如傳統(tǒng)呼叫中心增加瀏覽器方式的接聽、傳統(tǒng)會控系統(tǒng)增加瀏覽器終端等。

該模式重點(diǎn)解決WebRTC技術(shù)與傳統(tǒng)應(yīng)用架構(gòu)之間的差異和兼容問題：在WebRTC與傳統(tǒng)的應(yīng)用架構(gòu)之間，加入一個(gè)負(fù)責(zé)協(xié)調(diào)兩者差異的網(wǎng)關(guān)設(shè)備。

中興通訊WebRTC-IMS網(wǎng)關(guān)的接入方案，由WebRTC-IMS網(wǎng)關(guān)負(fù)責(zé)WebRTC與傳統(tǒng)IMS網(wǎng)絡(luò)之間的信令轉(zhuǎn)換、媒體流中繼以及NAT/防火墻穿越機(jī)制的轉(zhuǎn)換等工作。該方案具有下面的優(yōu)勢：

·增加傳統(tǒng)音視頻業(yè)務(wù)的軟接入方式，同時(shí)不需要為增加瀏覽器的接入做各種各樣的插件，大大減少了傳統(tǒng)瀏覽器客戶端的工作量。

·利用傳統(tǒng)業(yè)務(wù)架構(gòu)中的媒體服務(wù)器來強(qiáng)化即時(shí)通信中音視頻的處理能力，提升WebRTC接入的用戶體驗(yàn)。

·可有效減少WebRTC接入對客戶端側(cè)處理能力的依賴和帶寬消耗。

（2）輕量級Web實(shí)時(shí)通信服務(wù)

利用WebRTC標(biāo)準(zhǔn)接口，開發(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è)計(jì)思路：將多方之間的媒體協(xié)商過程分解成多個(gè)端到端的協(xié)商過程，傳統(tǒng)上由媒體服務(wù)器來完成的功能都轉(zhuǎn)移到了客戶端瀏覽器側(cè)。

當(dāng)兩個(gè)瀏覽器實(shí)時(shí)通信時(shí)，通過信令交互獲取到雙方都支持的媒體格式和傳輸協(xié)議后，直接按照約定好的原則進(jìn)行端到端的媒體傳輸。一旦有第三方加入進(jìn)來，則由第三方代理分別在信令層面發(fā)起對前兩個(gè)用戶代理的協(xié)商，之后的過程與兩方之間通信過程一致。

該方案的優(yōu)勢是開發(fā)簡單快捷，基本不關(guān)注媒體處理。缺點(diǎn)是隨著瀏覽器端的增加，每個(gè)瀏覽器需要向其他瀏覽器端分別發(fā)送媒體流，同時(shí)接受來自其他瀏覽器端的媒體流，這對瀏覽器端的媒體處理能力提出了較高的要求，相對應(yīng)的帶寬需求也比較大。

（3）綜合型的Web實(shí)時(shí)通信服務(wù)

在終端采用WebRTC，在服務(wù)側(cè)結(jié)合電信的多點(diǎn)控制單元（MCU）等設(shè)備，解決掉混頻和混音問題，增強(qiáng)對各種應(yīng)用場景的支持，同時(shí)減輕對網(wǎng)絡(luò)的壓力。

綜合型的Web實(shí)時(shí)通信服務(wù)通過采用輕量級Web實(shí)時(shí)通信服務(wù)當(dāng)中的點(diǎn)對點(diǎn)以及點(diǎn)對多點(diǎn)的媒體協(xié)商策略，讓客戶端之間就可以完成媒體協(xié)商過程，進(jìn)而使得整體應(yīng)用架構(gòu)變得簡潔。同時(shí)，它還在服務(wù)側(cè)引入了多點(diǎn)控制單元來接管多方媒體流的處理，較大程度地緩解了客戶端側(cè)處理壓力，給WebRTC在各種場景中的充分應(yīng)用創(chuàng)造了有利條件。

綜合型的Web實(shí)時(shí)通信服務(wù)融合了前兩種方案各自的優(yōu)勢，能夠適應(yīng)大規(guī)模應(yīng)用。

3 WebRTC技術(shù)方案分析

與改進(jìn)

3.1 當(dāng)前WebRTC應(yīng)用存在的技術(shù)

問題

作為一種發(fā)展中的技術(shù)和標(biāo)準(zhǔn)，WebRTC還有諸多不夠完善之處，這些缺陷給WebRTC的利用帶來了不少挑戰(zhàn)：

·與傳統(tǒng)的會議視頻業(yè)務(wù)相比，媒體控制弱，需要增強(qiáng)以適應(yīng)復(fù)雜會議控制的需求。

·媒體流的P2P直傳對給客戶端的處理能力帶來挑戰(zhàn)。2到4個(gè)參與方比較合適，超過4個(gè)參與方對客戶端處理能力都提出了很高的要求。業(yè)界應(yīng)用PC端參與方很少超過6個(gè)參與方。如果是移動客戶端則問題更大。

·端到端直傳大量媒體流的上傳下載帶來巨大的帶寬消耗。不僅增加了用戶使用服務(wù)的成本，對用戶體驗(yàn)造成不良的沖擊。

·當(dāng)前瀏覽器廠商在WebRTC標(biāo)準(zhǔn)Javascript API和HTML5 API的設(shè)計(jì)上，存在命名或方法調(diào)用的差異[8-9]，在一個(gè)瀏覽器正常運(yùn)行的WebRTC應(yīng)用，在另一套瀏覽器環(huán)境可能會出現(xiàn)異常。

·通過WebRTC Javascript API直接操作本地音視頻媒體文件和相關(guān)設(shè)備能力也為系統(tǒng)的安全性帶來挑戰(zhàn)[10]。

3.2 設(shè)計(jì)方案的改進(jìn)

為了有效解決跨瀏覽器運(yùn)行、減少應(yīng)用運(yùn)行對客戶端側(cè)處理能力的依賴和帶寬消耗，同時(shí)提高系統(tǒng)的可擴(kuò)展性，本文提出了一種利用WebRTC技術(shù)開發(fā)輕量級Web實(shí)時(shí)通信服務(wù)的改進(jìn)思路，其整體框架如圖1所示。

圖1主要包括客戶端側(cè)、服務(wù)端側(cè)、客戶端與服務(wù)端之間的通信，說明如下：

（1）客戶端側(cè)

在客戶端側(cè)，Browser負(fù)責(zé)提供WebRTC標(biāo)準(zhǔn)接口支持，SIP Stack負(fù)責(zé)提供客戶端側(cè)會話發(fā)起協(xié)議（SIP）[11]信令的處理。WebRTC封裝庫建立在Browser WebRTC Javascript API和SIP Stack的基礎(chǔ)上，解決客戶端與服務(wù)端雙向通信、媒體及防火墻穿越連接協(xié)商以及跨瀏覽器運(yùn)行等方面的問題。Webrtc APP負(fù)責(zé)完成用戶界面展示。

（2）服務(wù)端側(cè)

服務(wù)端側(cè)包括交互式連接建立（ICE）[12]服務(wù)器、MCU、Web服務(wù)器以及信令服務(wù)器4個(gè)網(wǎng)元。其中，ICE服務(wù)器用于與客戶端側(cè)瀏覽器交互，幫助客戶端獲取到能夠穿越NAT/防火墻的ICE地址。MCU負(fù)責(zé)對各方代理傳輸過來的視頻流進(jìn)行合成，并將最終合成的多方視頻流發(fā)送給各方代理。Web服務(wù)器用于運(yùn)行Webrtc APP。信令服務(wù)器用于對客戶端的SIP請求進(jìn)行處理和路由分發(fā)，并輔助完成用戶認(rèn)證、用戶管理、會議控制與錄制、會議計(jì)費(fèi)等功能。在實(shí)際的部署中，上述4種網(wǎng)元既可以單獨(dú)部署，也可以根據(jù)需要部署在同一臺或幾臺服務(wù)器當(dāng)中。

（3）客戶端與服務(wù)端之間的通信

NAT/防火墻穿越的客戶端程序與交互式連接建立服務(wù)器通信遵從數(shù)據(jù)報(bào)協(xié)議通過網(wǎng)絡(luò)地址轉(zhuǎn)換簡單穿越（STUN）[13]、中繼NAT實(shí)現(xiàn)的穿透（TURN）[14]等標(biāo)準(zhǔn)協(xié)議，采用數(shù)據(jù)報(bào)協(xié)議（UDP）進(jìn)行消息傳輸?？蛻舳伺c服務(wù)端雙向的SIP交互采用SIP over WebSocket[15]技術(shù)。

客戶端與服務(wù)端之間媒體流傳輸采用實(shí)時(shí)傳送協(xié)議/實(shí)時(shí)傳輸控制協(xié)議（RTP/RTCP）格式。Web服務(wù)的訪問采用超文本傳輸協(xié)議（HTTP）。

基于上述框架，一個(gè)大致的多方視頻通信過程可以簡要描述如下：

·用戶通過客戶端瀏覽器訪問Web服務(wù)器提供的服務(wù)。

·客戶端之間通過信令服務(wù)器注冊并借助ICE服務(wù)器完成多方之間點(diǎn)多多點(diǎn)的媒體協(xié)商過程。

·MCU接收各方按照約定的格式傳送的本地音視頻流，并將其按照相關(guān)策略進(jìn)行混音、混頻等后臺處理，然后將得到的合成流再返回給參會的各方。

·各方瀏覽器完成媒體流的接收和顯示。

·建立起多方通信過程。

3.3 采用的關(guān)鍵技術(shù)

（1）HTML5 WebSocket技術(shù)

傳統(tǒng)實(shí)時(shí)通信中，通常采用輪詢或長輪詢的方式來實(shí)現(xiàn)。這種通過增加客戶端請求頻次或延長服務(wù)端響應(yīng)時(shí)段的做法，雖然在一定程度改善實(shí)時(shí)性服務(wù)程序的體驗(yàn)，但其基于HTTP的請求響應(yīng)模式，無法做到真正的實(shí)時(shí)。此外，還會給客戶端的帶寬和服務(wù)端的資源消耗帶來額外的負(fù)擔(dān)。

為了減少實(shí)時(shí)通信的延遲，降低帶寬消耗，HTML5工作組制訂了WebSocket通信標(biāo)準(zhǔn)。通俗地說，HTML5 WebSocket是通過在Web上的單個(gè)Socket定義了一個(gè)全雙工通信信道，進(jìn)而為Web實(shí)時(shí)通信帶來顯著的改善。

在客戶端與服務(wù)端通信之前，首先需要完成一次WebSocket握手過程來建立雙方之間的連接。一旦連接建立起來，客戶端與服務(wù)端之間就可以雙向進(jìn)行數(shù)據(jù)的發(fā)送或接收。這樣，當(dāng)服務(wù)端有數(shù)據(jù)更新時(shí)，就可以直接推送到客戶端側(cè)，而不需要等待客戶端側(cè)是請求。

在音視頻通信這類實(shí)時(shí)性非常強(qiáng)的應(yīng)用場景中，采用HTML5 WebSocket技術(shù)可以極大地提高服務(wù)的實(shí)時(shí)性，并通過降低傳輸載荷減少帶寬消耗。

（2）媒體協(xié)商與合成技術(shù)

上述改進(jìn)思路中，各方媒體信息的協(xié)商還是放在客戶端自己來完成。對于多方參會情形而言，在實(shí)現(xiàn)上還是需要將多方的協(xié)商過程分解成多個(gè)端到端的協(xié)商過程，可選的協(xié)商策略包括圖2、圖3所示的兩種實(shí)現(xiàn)方法。

理論上來說，在多方之間的媒體協(xié)商完畢之后，就可以實(shí)現(xiàn)多方之間的媒體流的直傳通信了。但這種應(yīng)用方式會帶來顯著的問題，以4方會議為例，每一方需要同時(shí)向外發(fā)送3路本地視頻流，同時(shí)接收其他3方的視頻流。這樣，客戶端側(cè)能夠支撐的用戶量非常有限，而且網(wǎng)絡(luò)帶寬消耗巨大。

為了解決該問題，需要在服務(wù)端借助MCU完成媒體流的轉(zhuǎn)換、合成等工作。引進(jìn)MCU之后，每個(gè)客戶端只需要向外發(fā)送本地的一路視頻流，同時(shí)也只需要接收從MCU合成后的一路視頻流。無疑，這將給系統(tǒng)的性能帶來極大的改善。

（3）NAT/防火墻穿越技術(shù)

在跨局域網(wǎng)環(huán)境中使用Web音視頻通信時(shí)，必須要有一套穿越NAT/防火墻的設(shè)備來輔助完成媒體流的路由傳輸。

在IETF-RTC Web標(biāo)準(zhǔn)中，規(guī)定了客戶端瀏覽器當(dāng)中WebRTC需要支持ICE框架，這樣服務(wù)端就需要提供相應(yīng)的ICE服務(wù)器。

在穿越方案的選擇上，同時(shí)支持STUN和TURN兩種服務(wù)器。其中，STUN服務(wù)器用于完成非對稱NAT穿越，TURN則負(fù)責(zé)完成對非對稱NAT穿越及防火墻的穿越。通過兩者的協(xié)同，保障WebRTC媒體流的暢通。

（4）基于SIP棧的信令交互技術(shù)

在W3C WebRTC標(biāo)準(zhǔn)中，并沒有對客戶端與服務(wù)端之間的信令進(jìn)行標(biāo)準(zhǔn)化。

SIP以其簡單、靈活和可擴(kuò)展等特性，受到業(yè)界越來越多的關(guān)注和支持，并已成為下一代通信事實(shí)上的標(biāo)準(zhǔn)。

為完成客戶端與服務(wù)端SIP信令交互，需要在客戶端側(cè)使用Mobicents JAIN-SIP標(biāo)準(zhǔn)的參考實(shí)現(xiàn)來提供SIP棧服務(wù)，服務(wù)端側(cè)利用SIP Servlet來處理客戶端側(cè)請求或進(jìn)行路由分發(fā)。一個(gè)服務(wù)端充當(dāng)代理實(shí)現(xiàn)路由分發(fā)的大致交互過程如圖4所示。

（5）P2P通信安全技術(shù)

為了防止瀏覽器程序?qū)Ρ镜刭Y源的濫用，在WebRTC即時(shí)通信服務(wù)框架中，我們參照文獻(xiàn)[10]引入了沙箱技術(shù)。該技術(shù)的核心思路是，將外部站點(diǎn)劃分成可信站點(diǎn)和不可信站點(diǎn)。其中，可信站點(diǎn)認(rèn)為是安全的，能夠訪問一切的本地資源（或者受限的部分資源）；不可信站點(diǎn)由于存在安全隱患，將其放入沙箱之中，不能直接訪問本地資源。

對于可信與非可信站點(diǎn)的甄別，采用IETF中的同源策略（SOP）[16]加以考慮：即一個(gè)網(wǎng)頁的安全性由其來源決定，需要對其所使用的協(xié)議、主機(jī)和端口進(jìn)行同源匹配；為每一個(gè)起源都分配一個(gè)與之匹配的安全訪問策略，比如從一個(gè)站點(diǎn)（記為A）訪問另一個(gè)目的站點(diǎn)（記為B）的資源時(shí)，不允許訪問B站點(diǎn)的本地加密文件等等。

此外，為了防止惡意站點(diǎn)通過Javascript API進(jìn)行分布式拒絕服務(wù)攻擊（DDOS）[17]攻擊或通過瀏覽器協(xié)議包仿真域名服務(wù)器（DNS）攻擊公司的DNS，因此還引入像定期掃描、檢查訪問者來源等輔助防御措施。

4 結(jié)束語

當(dāng)前WebRTC技術(shù)和標(biāo)準(zhǔn)尚不成熟，在實(shí)用中還存在不少問題，如很多功能尚未定義、不同瀏覽器間的不兼容、客戶端側(cè)處理能力要求較高以及高帶寬消耗等問題。本文提出一種WebRTC實(shí)時(shí)通信服務(wù)的改進(jìn)設(shè)計(jì)思路，較好地解決了當(dāng)前WebRTC技術(shù)應(yīng)用面臨的主要問題，對于WebRTC技術(shù)的產(chǎn)品化具有重要的借鑒價(jià)值和現(xiàn)實(shí)意義。

隨著LTE、Wi-Fi和有線寬帶的普及、帶寬得到解決，PC和各種移動終端處理能力大幅提升，各種終端上瀏覽器基本都會支持WebRTC，基于WebRTC的實(shí)時(shí)音視頻通信會成為一種普遍服務(wù)。綜合型的Web通信服務(wù)方案將會成為一種較為理想的應(yīng)用模式。

HTML5和WebRTC技術(shù)和標(biāo)準(zhǔn)正走向成熟、快速普及，傳統(tǒng)的IM、桌面共享、電子白板、音視頻會議錄制等將進(jìn)一步朝Web化的方向發(fā)展，并將最終融合到一個(gè)完整的基于Web的統(tǒng)一通信系統(tǒng)當(dāng)中。屆時(shí)，用戶基于瀏覽器就可以進(jìn)行全方位的溝通與交流，人際交互將變得更加簡便、快捷。

參考文獻(xiàn)

[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實(shí)時(shí)通信的安全性分析 [J]. 計(jì)算機(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：// www.ietf.org/rfc/rfc3489.txt.

[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] 吳敏， 王汝傳， 王治平. 基于支持向量機(jī)的P2P網(wǎng)絡(luò)DoS攻擊檢測 [J]. 計(jì)算機(jī)技術(shù)與發(fā)展， 2009，11：151-154.