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

針對(duì)Web實(shí)時(shí)通信（WebRTC）技術(shù)，提出一種WebRTC實(shí)時(shí)通信服務(wù)的改進(jìn)設(shè)計(jì)方案。方案在客戶(hù)端側(cè)、服務(wù)端側(cè)、客戶(hù)端與服務(wù)端之間的通信等部分對(duì)WebRTC進(jìn)行了改進(jìn)。改進(jìn)方案采用了HTML5 WebSocket技術(shù)、媒體協(xié)商與合成技術(shù)、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）/防火墻穿越技術(shù)、基于會(huì)話(huà)發(fā)起協(xié)議（SIP）棧的信令交互技術(shù)、P2P通信安全技術(shù)，較好地解決了跨瀏覽器運(yùn)行、對(duì)客戶(hù)端側(cè)處理能力的過(guò)分依賴(lài)和帶寬消耗等問(wèn)題，提高了系統(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)是在不安裝任何插件的前提下，開(kāi)發(fā)者基于瀏覽器利用簡(jiǎn)單的Web技術(shù)方便快捷地開(kāi)發(fā)出豐富的實(shí)時(shí)Web多媒體應(yīng)用。

隨著網(wǎng)絡(luò)帶寬和瀏覽器版本的升級(jí)，WebRTC將會(huì)對(duì)傳統(tǒng)的實(shí)時(shí)通信業(yè)務(wù)造成巨大影響，正逐漸成為主流的實(shí)時(shí)通信方式。Google已開(kāi)始在Android平臺(tái)的新版Chrome瀏覽器上提供WebRTC支持，預(yù)計(jì)2013年至少有10億終端支持WebRTC。中國(guó)著名的融合通信論壇CTI調(diào)查結(jié)果顯示[2]：87%電信企業(yè)考慮將WebRTC融入產(chǎn)品戰(zhàn)略，86.9%的受訪(fǎng)者表示W(wǎng)ebRTC對(duì)于他們的整體產(chǎn)品戰(zhàn)略而言具有十分重要的意義，49%的受訪(fǎng)者打算在未來(lái)1年內(nèi)部署WebRTC解決方案。

WebRTC由Google收購(gòu)的Global IP Solution公司開(kāi)發(fā)，并由Google在2010年向外開(kāi)放，目前已成為實(shí)時(shí)通信的技術(shù)熱點(diǎn)，在W3C和IETF都成立了WebRTC相關(guān)的標(biāo)準(zhǔn)組，并得到業(yè)界越來(lái)越多廠商的支持。

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

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

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

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

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

（5）開(kāi)發(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é)定義客戶(hù)端側(cè)Javascript API，這些應(yīng)用編程接口（API）用于幫助Web應(yīng)用完成Web瀏覽器之間點(diǎn)對(duì)點(diǎn)或點(diǎn)對(duì)多點(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類(lèi)API，分別用來(lái)完成媒體流的獲取、點(diǎn)到點(diǎn)的媒體、NAT/防火墻穿越連接的協(xié)商、瀏覽器之間音視頻流之外的數(shù)據(jù)傳輸。3類(lèi)API中，Network Stream API和RTCPeerConnection API比較成熟，DataChannel API則是新增加的特性，目前的應(yīng)用還不太廣泛。

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

在WebRTC技術(shù)的運(yùn)用上，瀏覽器廠商Google、Mozilla，VoIP中間件平臺(tái)Mobicents[3]（目前已被Redhat收購(gòu)）、通信廠商Livecome[4]以及一些Web即時(shí)通信服務(wù)開(kāi)發(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)營(yíng)商與解決方案提供商將WebRTC作為傳統(tǒng)音視頻業(yè)務(wù)中的一個(gè)新的接入方式，如傳統(tǒng)呼叫中心增加瀏覽器方式的接聽(tīng)、傳統(tǒng)會(huì)控系統(tǒng)增加瀏覽器終端等。

該模式重點(diǎn)解決WebRTC技術(shù)與傳統(tǒng)應(yīng)用架構(gòu)之間的差異和兼容問(wèn)題：在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)勢(shì)：

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

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

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

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

利用WebRTC標(biāo)準(zhǔn)接口，開(kāi)發(fā)輕量級(jí)Web視頻通話(huà)、Web音視頻會(huì)議中心是WebRTC的典型應(yīng)用場(chǎng)景。業(yè)界比較有代表性的原型包括Mobicents SIP Servlet[5]、Conversat.io[6]（現(xiàn)更名為T(mén)alky.io）、Chatdemo[7]等。

這種場(chǎng)景中，各原型在應(yīng)用架構(gòu)上基本上都采用了“去中心化”的設(shè)計(jì)思路：將多方之間的媒體協(xié)商過(guò)程分解成多個(gè)端到端的協(xié)商過(guò)程，傳統(tǒng)上由媒體服務(wù)器來(lái)完成的功能都轉(zhuǎn)移到了客戶(hù)端瀏覽器側(cè)。

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

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

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

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

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

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

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

與改進(jìn)

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

問(wèn)題

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

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

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

·端到端直傳大量媒體流的上傳下載帶來(lái)巨大的帶寬消耗。不僅增加了用戶(hù)使用服務(wù)的成本，對(duì)用戶(hù)體驗(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)境可能會(huì)出現(xiàn)異常。

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

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

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

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

（1）客戶(hù)端側(cè)

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

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

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

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

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

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

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

·用戶(hù)通過(guò)客戶(hù)端瀏覽器訪(fǎng)問(wèn)Web服務(wù)器提供的服務(wù)。

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

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

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

·建立起多方通信過(guò)程。

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

（1）HTML5 WebSocket技術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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

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

HTML5和WebRTC技術(shù)和標(biāo)準(zhǔn)正走向成熟、快速普及，傳統(tǒng)的IM、桌面共享、電子白板、音視頻會(huì)議錄制等將進(jìn)一步朝Web化的方向發(fā)展，并將最終融合到一個(gè)完整的基于Web的統(tǒng)一通信系統(tǒng)當(dāng)中。屆時(shí)，用戶(hù)基于瀏覽器就可以進(jìn)行全方位的溝通與交流，人際交互將變得更加簡(jiǎ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攻擊檢測(cè) [J]. 計(jì)算機(jī)技術(shù)與發(fā)展， 2009，11：151-154.