WebRTC會成主流嗎？衆包CDN時代到了！

時間 2019-11-15

原文原文鏈接

內容來源：2017年6月24日，梨享計算前端工程師謝庭在「騰訊Web前端大會 TFC 2017」進行《基於WebRTC的P2P-CND流媒體加速》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。
閱讀字數： 4311 用時: 6分鐘

嘉賓演講視頻地址：t.cn/RCIMlWnjavascript

PPT地址：t.cn/Rp9hZ7R前端

WebRTC的誕生背景

咱們知道如今實時視頻通訊很廣泛，基於FaceTime和Skype等視頻通話工具，用戶能夠很方便地與他人進行視頻對話。開發者們爲了將用戶體驗優化到極致，經過大量的技術手段保障視頻質量，好比減小丟包、斷網恢復、即時響應用戶網絡變化等等。實時音視頻通訊對開發者的技術要求比較高，並且專利持有公司向開發者徵收受權費，並構築起巨大的技術壁壘。另外一方面，對用戶來講，須要去額外安裝相應的插件或者應用程序，下降了用戶體驗，並且還有被捆綁流氓軟件的風險。這時候一種叫WebRTC的技術應運而生了。

在講WebRTC以前，咱們先回顧一下Web通訊的演化歷史。在AJAX出現以前，也就是05年以前，若是須要更新內容，必須重載整個網頁頁面。AJAX出現以後，經過在後臺與服務器進行少許數據交換，AJAX 可使網頁實現異步更新。但AJAX不能與服務器進行雙工通訊，所以服務器沒法主動推消息給瀏覽器，只能經過瀏覽器進行輪詢。Websocket的出現使這個局面獲得改觀，瀏覽器與服務器能進行全雙工通訊。無論是AJAX仍是Websocket，都須要將數據發送給服務端。爲了在兩個用戶間傳送數據，開發者須要購買服務器網絡，這方面的成本是很是龐大的。由谷歌支持的一項新技術——WebRTC完全改變了這個局面。WebRTC是Web Real-Time Communication的縮寫，實現了瀏覽器之間直接的實時通信，而再也不須要服務器中轉，谷歌致力於讓其成爲HTML5的標準之一，目前大部分瀏覽器也已經支持。java

WebRTC與P2P的結合

12年穀歌的chrome瀏覽器正式原生支持WebRTC，web開發者只須要幾行javascript代碼就能夠開發出豐富的實時多媒體應用，而用戶也無需安裝插件，直接打開瀏覽器就能夠與對方實時聊天。這時候有些嗅覺敏銳的開發者開始利用WebRTC的數據通道技術作P2P流媒體，例如國外一家公司叫作peer5。咱們公司的創始人Alan在騰訊工做的時候也投入到這方面的研究，但失望的發現用WebRTC作P2P流媒體還有一些問題難以解決，好比用戶在線的時間並不穩定，當用戶關閉頁面，WebRTC的數據通道也就關閉了。隨後在13年和14年，Firefox和Opera也相繼宣佈支持WebRTC。這時Alan提出一個大膽的設想，既然瀏覽器作種不穩定，那麼把相同的協議實如今路由器和NAS中呢？咱們都知道路由器是24小時開啓的，但大部分時間是處於閒置狀態，若是能把這些計算能力和網絡帶寬利用起來，這樣至關於千家萬戶都是節點，你的鄰居甚至你本身也許就在爲你看視頻提供加速，想一想都是很酷的事情！所以咱們提出了衆包CDN的概念，而且申請了專利。15年，騰訊的X5瀏覽器內核和微信也提供了支持，同年，咱們梨享計算也正式宣佈成立。git

可能你們會有疑問，WebRTC未來真的會成爲一種主流技術嗎？咱們用事實說話，看看各大瀏覽器的支持狀況就知道了。從圖中能夠看出，大部分瀏覽器都已支持WebRTC，包括chrome、firefox和opera，微軟的edge瀏覽器部分支持WebRTC。另外，蘋果也在近期的WWDC大會上宣佈safari11支持WebRTC。將來基於WebRTC的應用將愈來愈多，這是能夠確定的。github

WebRTC媒體會話原理

咱們假設如今有兩個瀏覽器A和B要創建WebRTC對等鏈接，對等鏈接就是兩個Web瀏覽器之間的直接媒體鏈接，若是A要主動聯繫B，須要先經過HTTP向信令服務器發送一個SDP，SDP能夠理解爲一個電腦名片，全稱是Session Description Protocol，會話描述協議，用於描述對等鏈接的媒體特徵。那麼信令服務器又是什麼呢？它就像一個紅娘，幫兩個互相不認識的人牽線。瀏覽器A發過來的SDP叫作offer，信令服務器將其傳給瀏覽器B，後者收到後迴應一個SDP對象，叫作answer，也經過信令服務器中轉給A。交換完SDP後，兩個對等端就開始嘗試ICE打洞，打洞成功後開始協商密鑰，以後就能夠開始安全的媒體或數據會話了。web

ICE打洞原理

因爲IPv4提供的IP資源有限，IPv6尚未推廣開來，大部分網絡設備還處於內網中，須要經過NAT設備來與外部internet鏈接。NAT全稱Network Address Translation，網絡地址轉換，裝有NAT軟件的路由器叫作NAT路由器，它至少有一個有效的外部全球IP地址。這樣，全部使用本地地址的主機在和外界通訊時，都要在NAT路由器上將其本地地址轉換成全球IP地址，才能和因特網鏈接。當兩個對等端處於不一樣的局域網中時，須要先知道對方的公網IP和端口。這時候能夠先向STUN服務器發送測試數據包，後者作出響應，指示其在測試數據包中監測到的IP地址，此地址將成爲潛在的候選地址返回。拿到候選地址的瀏覽器將其經過信令服務器發送給對等端，對等端也進行一樣的操做，以後雙方用全部獲得的候選地址嘗試鏈接，若是都沒有成功的狀況下，會用TURN服務器來做爲中轉服務器，TURN服務器是在全部替代方案都無效的狀況下才有采起的，由於成本比較高昂。爲了加速通話創建時間，有一個叫trickle ice的方案，其思想是客戶端一邊收集candidate一邊發送給對方，好比local candidate 不須要經過stun獲取直接就能夠發起，這下降了了連通性檢測完成的時間。算法

WebRTC數據通道

接下來介紹一個比較重要的概念——WebRTC data channel。咱們基於WebRTC來作P2P流媒體，實際上就是用的data channel能力。那麼data channel究竟是什麼呢？雖然有關WebRTC的宣傳主要側重於它對於實時音視頻通信的支持，但設計師一直都但願它也支持實時數據傳輸。相比Websocket和HTTP，數據通道支持流量大、延遲低的鏈接，具備穩定可靠等優勢。並且data channel的接口和websocket同樣，也是經過send來發送數據，經過ommessage來接收數據。那麼如何對data channel數據傳輸的可靠性進行控制呢？經過剛纔所講的dataChannelOptions這個javascript對象，可讓data channel在UDP或者TCP的優點之間進行切換，好比讓數據傳輸得更加穩定可靠，或者傳輸得更快。其中有幾個比較重要的字段：ordered：設置數據的接受是否須要按照發送時的順序，maxRetransmitTime：設置數據發送失敗時，多久從新發送，maxRetransmits：設置數據發送失敗時，最多重發次數。主要是配置ordered，當設置爲true時數據通道表現更像TCP，false時表現更像UDP。chrome

梨享計算與WebRTC

此外，咱們公司一直對WebRTC標準化保持着關注並貢獻力量。在去年，咱們在研發過程當中發現有一個第三方的webrtc協議棧能與chrome瀏覽器進行通信，但沒法與firefox通信，經過對比SDP發現firefox有一處實現與標準規範不一致。因而咱們與firefox開發團隊取得聯繫，提交了咱們的修改建議，最初他們認爲沒有問題，但最終仍是採納了咱們的建議，對sdp進行了修改。這也算是咱們對推動webrtc標準化作出的一點點貢獻。另外，咱們也一直與騰訊瀏覽器內核團隊保持着聯繫，爭取WebRTC技術以及本次分享的上層的P2P-CDN加速協議獲得全面的支持。瀏覽器

WebRTC與P2P流媒體

把WebRTC的data channel搞清楚後，咱們就能夠用用它來作P2P流媒體了。這方面已經有國外大神開發的知名開源項目：WebTorrent，在github上有1萬多顆星。WebTorrent是一個開源的基於WebRTC 和BT協議的js框架，徹底用javascript編寫，能夠同時運行於 Node.js 和瀏覽器，因爲基於WebRTC，所以WebTorrent不須要安裝任何插件，就能夠跑在瀏覽器上。同時支持Chrome, Firefox 和 Opera瀏覽器。可是因爲是基於BT協議，因此是一種pull-based的算法，這種算法是一種隨機抓取的策略，隨機抓取其它節點的buffer，但這樣會存在一個問題：抓取的buffer不必定是目前須要的，也不必定是其餘節點須要的，並且還會浪費下行帶寬和其它節點的上行帶寬，所以同時形成了「帶寬飢餓」和「內容飢餓」問題。下面介紹一種改進版的pull-based算法——FirstAid算法。FirstAid是基於窗口滑動的，每隔一段時間觸發一次窗口滑動，每一個窗口又能夠分紅三段：urgent、normal和prefetch，urgent顧名思義，是離播放時間最近的buffer，因此優先級別最高，normal和prefetch優先級遞減。當父節點爲子節點傳輸buffer時，會優先知足urgent級別的要求，而暫停normal級別的，因此最緊迫的需求會優先獲得知足，當子節點的urgent需求獲得知足後，須要回過頭來彌補他的競爭對手的需求，以達到一種互惠互利的狀態。和剛纔pull-based算法思想截然相反的是push-based算法，其中比較有表明性的是FashMesh算法，由港科大的學者提出來的一種P2P算法。FashMesh是基於一種叫Streaming Mesh的算法，將源節點的數據流分紅多個子流，經過多棵生成樹構成mesh來源源不斷的傳輸給子節點，這種算法的優點是延遲低，帶寬利用率高。Fast Mesh還能夠根據每一個子節點的上行帶寬來動態的調整網絡拓撲結構，讓上行帶寬大的節點更加接近源節點，從而充分利用網絡的現有能力。根據一項對比試驗，FastMesh多是目前衆多P2P算法中效果最好的。但這個算法也有缺點，當節點進入或離開網絡時，都須要從新調整拓撲結構，所以不適合節點變化較大的狀況。安全

咱們自行研發的算法——Push-Pull算法則綜合了push-based和pull-based兩種算法的優點，用pull的方式從父節點獲取優先級最高的buffer，由父節點以push的方式爲其提供後續的buffer。另外，咱們的算法混合HTTP、HTTPS、WebRTC、Websocket等多種協議，在優先保證用戶體驗的前提下最大化P2P率。通過測試，Push-Pull算法具有低延遲、高帶寬利用率、高P2P率、對網絡拓撲結構變化魯棒性強等優點。

PearPlayer

PearPlayer（梨享播放器，github地址：https://github.com/PearInc/PearPlayer.js）是徹底用JavaScript寫的開源HTML5流媒體播放框架，實現了融合HTTP（包含HTTPS、HTTP2）、WebRTC的多協議、多源、低延遲、高帶寬利用率的無插件Web端流媒體加速能力。基於H5的MSE技術(Media Source Extension)未來自多個源節點的Buffer分塊餵給播放器，再加上精心設計的算法來達到最優的調度策略及對各類異常狀況的處理，Pear Player能在保證用戶流暢視頻體驗的前提下最大化P2P率。

集成咱們的PearPlayer.js也很是簡單，只須要短短几行代碼，把咱們的js文件引入到script標籤中，並把video的id還有token做爲參數傳給咱們提供的函數中便可。Demo演示地址：qq.webrtc.win/watch，如下是demo截圖。

除了播放器外，咱們還開發了支持多協議、多源、混合P2P-CDN的下載器PearDownloader，可用於高清圖、壓縮包、軟件發佈或升級包、音樂、文檔等大文件下載或在線服務的場景（github地址：github.com/PearInc/Pea…），Demo演示地址：qq.webrtc.win/download。

霧計算

最後，講一下霧計算有關的內容。霧計算與雲計算有什麼區別呢？雲在天空飄浮，高高在上，高不可攀；數據中心距離終端用戶較遠，用戶消息須要通過若干跳纔可以到達。而霧是貼近地面的雲，是現實可及，就在你我身邊。霧計算並不是由性能強大的服務器組成，而是由性能較弱、更爲分散但離用戶更近的各種計算設備組成，例如智能路由器、網絡存儲設備等。霧可以彌補雲的不足，並和雲相互配合，協同工做。咱們Pear公司一直在踐行霧計算的理念，經過與國內知名的路由器、NAS廠商合做，咱們擁有海量可持續穩定提供服務的節點。大部分帶寬、存儲、計算資源經過衆包方式收集自終端用戶穩定在線的邊緣設備，服務能力覆蓋所有地域、全部運營商、每處網絡邊緣。咱們自研的調度系統能夠動態、實時的感知和調度，讓數據傳輸距離儘量接近「零跳」。

相對於傳統的模式，咱們能夠說是站在共享經濟的風口上。咱們知道傳統的CDN廠商會先以批發價從ISP買進帶寬，而後再以零售價賣給CP，CP買入帶寬後進行內容分發，爲終端用戶提供CDN服務。咱們與硬件廠商合做，在其設備中植入咱們的軟件，從而在千家萬戶擁有了分佈普遍的節點。CP廠商和傳統CDN廠商從咱們這裏買入帶寬，咱們將其內容分發到各個節點中，持有設備的用戶在提升其計算資源和帶寬資源的同時，也會獲得咱們的返利，BGP機房、ISP骨幹網的壓力也得以緩解，從而實現多贏局面。