WebRTC直播現狀

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

圖1

如何使用WebRTC來做直播？

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

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

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

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

WebRTC能做什么

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

圖2

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

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

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

anyRTC如何實現

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

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

結語

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