WebRTC直播現狀

現在使用WebRTC技術的公司越來越多了，如果你密切關注直播領域的話，你會(huì)發(fā)現一個很有趣的變化，随著(zhe)直播業務的增長(cháng)，傳統的流媒體由于延時大不能(néng)滿足于各種(zhǒng)應用場景的需求，一些可替代性的解決方案紛紛登場，而WebRTC是這(zhè)些技術解決方案中的佼佼者。目前很多數的公司使用WebRTC做直播的架構圖是采用圖1中的結構：

圖1

如何使用WebRTC來做直播？

通常推流端使用WebRTC將(jiāng)本地視頻上傳到流媒體服務器端，然後(hòu)在服務端將(jiāng)WebRTC的流轉碼成(chéng)RTMP，HLS，MPEG-DASH等，再通過(guò)傳統的流媒體通道(dào)進(jìn)行直播分發(fā)。

這(zhè)個架構還(hái)是借助傳統直播的方案，隻是利用了WebRTC的特性將(jiāng)推流端到服務端之間的流傳進(jìn)行優化，這(zhè)樣(yàng)做的最大問題是服務端的性能(néng)消耗和直播分發(fā)的延時，我們知道(dào)類似HLS這(zhè)樣(yàng)的協議通常延時在15s+。

随著(zhe)應用場景對(duì)于實時性要求的提高，上面(miàn)的架構無疑還(hái)是無法滿足需求的。通過(guò)anyRTC的運營數據和市場需求分析來看，更多的需求方希望看到更低延時的視頻流，以幫助他們完成(chéng)更加豐富的場景需求。

而當前這(zhè)種(zhǒng)架構不能(néng)勝任實時直播的工作，因爲在傳統直播架構中緩存，分片等設計方式保障了直播的流暢性，但是卻犧牲了直播的實時性。

WebRTC能(néng)做什麼(me)

由于傳統直播方案無法應對(duì)低延時直播場景，這(zhè)就是爲什麼(me)需要一個全新的直播架構，當然低延時和實時性是必需的。但是由于一個協議的标準化和實施需要很長(cháng)時間，因此目前最佳的可選方案就是WebRTC，今年(2018年6月)WebRTC 1.0規範正式發(fā)布，各大廠商均表現出很高的積極性，而且現在大多數浏覽器中已經(jīng)原生支持，這(zhè)對(duì)WebRTC未來更加廣泛的應用打下了非常夯實的基礎。

圖2

圖2是WebRTC做直播的架構，所有的流媒體都(dōu)會(huì)走WebRTC通道(dào)，這(zhè)樣(yàng)可以保證整個流媒體從推流端到觀看端的每個環節都(dōu)能(néng)使用WebRTC的特性。

當然使用WebRTC做直播有很多難點需要攻克，廣播服務器需要具備大容量，大并發(fā)，低延時，可動态伸縮，可災備等一些列高級特性，而不僅僅是簡單的媒體流轉發(fā)。

要做到這(zhè)些，我們需要一個完全不同的服務器架構來實現WebRTC流媒體的轉發(fā)，這(zhè)與當今市場上的一些方案（開(kāi)源和商業方案）有所不同。因爲現有的方案服務器上的WebRTC實現幾乎是背靠背的實現——它們在服務端對(duì)每個連接模拟一個完整的客戶端來接收或轉發(fā)WebRTC的媒體流。這(zhè)樣(yàng)實現沒(méi)有問題，但是它很難應對(duì)上千、幾萬或數百萬的大并發(fā)連接。

anyRTC如何實現

anyRTC一直主推WebRTC技術方案對(duì)原有的直播系統進(jìn)行升級改造。anyRTC采用的是微服務分離架構，流媒體服務隻對(duì)信令和媒體包進(jìn)行轉發(fā)，這(zhè)些我們定義爲輕任務；而類似媒體處理、編解碼等重任務由單獨的業務服務進(jìn)行處理。

同時服務端之間的流分發(fā)如何保障低延時，單機最大容量，系統容災，媒體流過(guò)防火牆，跨國(guó)分發(fā)流，流路徑跟蹤等等一些列問題也需要考慮。由于篇幅有限這(zhè)些問題我們將(jiāng)在後(hòu)續的文章中再做詳細讨論。

結語

那麼(me)直播爲什麼(me)不使用WebRTC呢，其中的緣由很多，可能(néng)是覺得WebRTC方案還(hái)不夠成(chéng)熟，可能(néng)是因爲技術難度較高實現較複雜，可能(néng)是因爲需求不迫切，可能(néng)你認爲這(zhè)本身就是僞命題，也有可能(néng)是因爲你還(hái)不知道(dào)。無論因爲什麼(me)原因，WebRTC近幾年的發(fā)展勢頭都(dōu)是不能(néng)夠忽略的，不久的將(jiāng)來WebRTC會(huì)在更多場景中廣泛應用，而不僅僅是直播行業。