主頁（http://www.130131.com）：直播為什么不使用WebRTC？

視頻直播的興起對于WebRTC來說是一次很好的機遇。 自2015年以來直播行業(yè)增長了3 ~ 5倍，這是一個很驚人的增長速度，但如何將WebRTC和直播聯(lián)系到一起，這并不是一個老生常談的問題，在這里anyRTC可以給你一個可選擇的解決方案。

WebRTC直播現(xiàn)狀

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

圖1

如何使用WebRTC來做直播？

通常推流端使用WebRTC將本地視頻上傳到流媒體服務器端，然后在服務端將WebRTC的流轉碼成RTMP，HLS，MPEG-DASH等，再通過傳統(tǒng)的流媒體通道進行直播分發(fā)。

這個架構還是借助傳統(tǒng)直播的方案，只是利用了WebRTC的特性將推流端到服務端之間的流傳進行優(yōu)化，這樣做的最大問題是服務端的性能消耗和直播分發(fā)的延時，我們知道類似HLS這樣的協(xié)議通常延時在15s+。

隨著應用場景對于實時性要求的提高，上面的架構無疑還是無法滿足需求的。通過anyrtc的運營數(shù)據(jù)和市場需求分析來看，更多的需求方希望看到更低延時的視頻流，以幫助他們完成更加豐富的場景需求。

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

WebRTC能做什么

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

圖2

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

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

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

anyRTC如何實現(xiàn)

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

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

結語

那么直播為什么不使用WebRTC呢，其中的緣由很多，可能是覺得WebRTC方案還不夠成熟，可能是因為技術難度較高實現(xiàn)較復雜，可能是因為需求不迫切，可能你認為這本身就是偽命題，也有可能是因為你還不知道。無論因為什么原因，WebRTC近幾年的發(fā)展勢頭都是不能夠忽略的，不久的將來WebRTC會在更多場景中廣泛應用，而不僅僅是直播行業(yè)。