售前電話
135-3656-7657
售前電話 : 135-3656-7657
疫情期間,WebRTC發(fā)揮了至關重要的作用,讓所有人都保持聯(lián)系,許多人對它的工作原理和所做的技術決定感到驚訝和困惑。這次演講旨在為這些決定提供一些歷史背景,希望能減少關于這些決定的困惑。一下一起看看WebRTC一路走過的歷程。
關于WebRTC API和協(xié)議的發(fā)展歷程中有許多小故事,正如所有的web開發(fā)人員在第一次遇到WebRTC時都會問很多的為什么。許多答案實際上與歷史有關,并且不同人的看法是存在偏差的,所以本次演講只是一些關于本人對WebRTC標準化過程中所做出的選擇的看法。
誰參與了WebRTC的發(fā)展歷程
谷歌、思科、愛立信、微軟、Mozilla和Voxeo都參與了WebRTC的發(fā)展歷程,W3C和IETF組織也提供了一定的支持。
為什么WebRTC的發(fā)展歷程如此之長
lib webRTC是在2011年開源的,人們困惑其發(fā)展歷程所經(jīng)歷的時間之久,困惑的一方的原因是,WebRTC的構建基礎早就具備,例如google早就擁有了許多相關的知識產(chǎn)權,Cisco也擁有許多SIP相關的產(chǎn)品,表面上來說所有要使用的協(xié)議的RFC都已經(jīng)存在了,所以這就像一個組裝工作,把這些組件放在一起,18個月內就能完成。
但實際上,這種想法實質上等同于把電話放進瀏覽器。只要扔一個進去,網(wǎng)絡開發(fā)者就會使用它,這或許可以行得通,但是其和800電話模式(撥打電話的人不會被收費)或者skype相似,而本質上,這并沒有將其考慮為一個RTC問題。
為什么WebRTC是P2P
開始之初Skype是主要的競爭對手,在那個時間點,這是一個PTP協(xié)議,它被視為一個巨大的成功,并且是一個meshframework框架,就像網(wǎng)格覆蓋一樣;此外,參與這個過程標準化過程的大多數(shù)人都受到了SIP的影響,而SIP靈感源于P2P。所以WebRTC是P2P在當時來說似乎是一個自然的選擇。
為什么沒有標準的信號形式
當時有幾個原因,其中一個非常簡單的原因是,SIP、XMPP和H323之間的激烈競爭并沒有產(chǎn)生贏家;另一個更大的問題是網(wǎng)絡授權認證方面,網(wǎng)絡認證并不是一個簡單的事,其并不像SIP的認證,如果嘗試在瀏覽器中使用它,需要把一個SIP標識綁定到一個網(wǎng)絡會話上,并保持這種表,其結果會相當復雜。此外,管理這些綁定關系數(shù)據(jù)是困難的。將呼叫狀態(tài)綁定到Web應用狀態(tài)要容易得多,如果Web應用正在執(zhí)行調用控制,那么我們就到了希望Web應用參與核心控制的地步。
Why no standardised signalling?
為什么選擇端到端(DTLS/SRTP)
在當時,著名的斯諾登事件所揭示的網(wǎng)絡信息安全問題是主要原因。常規(guī)的SRTP/SDES授權被認為是實現(xiàn)過于困難而無法實際使用,所以選擇了使用Java實現(xiàn)DTLS/SRTP。
為什么選擇RTP
實際上這基本上是標準規(guī)則,由于許多原因,Adobe發(fā)展過程中的選擇太慢了,當他們展示的時候就有點落時了。并且IAX2只是一個信息性RFC,因此不適合RTC。
關于數(shù)據(jù)通道
為什么如此多的選擇模式
關于編解碼器
部分原因與當時其他應用的成功有關,由于Skype取得了巨大的成功,并且它已被開源,結合Opus,產(chǎn)生了一個開源代碼。視頻編解碼器的東西要復雜得多,沒有明顯的開源編解碼器可以被使用。許可證的原因推動了VP8的使用,而硬件性能問題則使得H.264被使用。
Why those codecs?
WebRTC的巨大成功