低延時的P2P HLS直播技術實踐

本文根據4月21日OSC源創會·武漢站的現場分享爲藍本，從新整理。 如下是演講內容：

近幾年，隨着直播、短視頻等視頻領域對帶寬要求的提高以及CDN行業競爭的加重，不少CDN公司開始往P2P-CDN方向發展。P2P-CDN在下降成本和加速視頻業務方面一直是很是優秀的解決方案。

今天就以HLS協議作一個切入點，講解一下又拍雲的P2P-CDN項目——PrismCDN。

直播P2P-CDN一般用於傳輸FLV協議的視頻，又拍云爲何研發支持HLS傳輸協議的P2P-CDN呢？由於有客戶使用了Web播放器，他們不想用FLV協議。爲了知足客戶的需求，又拍雲PrismCDN對P2P-CDN作了HLS適配，讓其可以支持HLS協議。

首先看一下HLS和HLS+。雖然HLS已經被普遍使用，可是它平均延時在10秒-30秒，存在延時高的缺點。HLS+技術經過在CDN邊緣節點對視頻進行切片、轉封裝，使延遲下降到4秒。目前，又拍雲PrismCDN已經全面支持HLS+服務。

P2P-CDN支持HLS實現原理

以PrismCDN爲例，目前的作法是P2P-CDN須要作一個P2P下載器的SDK，再經過P2P協議下載數據，同時藉助CDN服務器補充數據下載，獲得中間結果—FLV數據流。接着在SDK本地作轉封裝，轉成M3U8和TS數據流，最後在local IP地址127.0.0.1上面提供HTTP服務，最終使播放器能夠訪問HLS數據流。

PrismCDN支持HLS協議的方式與HLS+下降延時的方式類似，HLS+是在CDN邊緣節點切片，而PrismCDN則是在客戶端本地完成切片以及傳輸FLV數據流。

P2P HLS的思路和HLS+是同樣的，把每一個TS片段切的很小，TARGETDURATION製成1秒，作到端對端延時4秒。

高效低價，獨特直播架構下的祕密

上面主要講解了HLS協議本地轉封裝，相較於P2P-CDN而言，最關鍵的數據流的傳輸方式。

首先主播經過RTMP協議將直播流推送到CDN服務器上，CDN服務器會即時推送數據流的二十分之一到光貓、路由器、機頂盒等霧節點。再由霧節點將數據轉發到SDK的下載器裏。下載器再向CDN服務器補數據，最終拼成FLV流。

PrismCDN數據傳輸關鍵點在於依靠光貓、路由器等霧節點的上行能力來提供CDN帶寬，從而減小CDN服務器補數據流。將大部分數據經過霧節點轉發，最終達到節約成本的目的。

獨特直播模型造就低延時

與其餘P2P產品相比，又拍雲PrismCDN最大的特色是低延時。

P2P直播已有多年曆史。早在2004年時，在網絡電視直播應用中就已經使用P2P技術，把部分電視臺信號放到互聯網上面來直播。可是受限於技術，那時的P2P直播延時至關大。

爲何2004年的P2P直播延遲會至關大呢？

這是由於當時的直播格式數據流從最頂層的播放節點和CDN下載數據，再逐層下發到各個下層節點。這種直播樹結構將數據一路下灌，形成了很是大的延時。

又拍雲PrismCDN不須要構建一棵直播樹，只需一層直播模型，就能夠達到P2P佔量比較高的效果。在一層模型中作到端到端延時在3秒內。在這樣的延時下，目前市面上直播的業務，如遊戲直播、秀場直播，均可以用PrismCDN來實現。

總結一下，PrismCDN低延時技術主要是在數據傳輸模型上進行了簡化。

90%分享率成就低延時、低成本特性

PrismCDN節點分享比例在90%以上，提高分享比例的關鍵是在於引進了第三方設備來供應數據。相比傳統直播樹，PrismCDN不存在「是播放者，纔是供應者」的侷限。好比有一萬個併發播放者的話，傳統直播樹的結構是沒法支持在播放的同時，分享帶寬給其它用戶，尤爲是在數據壓力比較高的時候。而PrismCDN增長了大量的第三方設備數量，提升上行帶寬供應量，下降CDN節點壓力，從而提升節點分享比例。

PrismCDN可以提高流暢度的關鍵在UDP協議。UDP協議與TCP協議相比，優化空間更大。實測中，咱們讓一部分節點用TCP來運行，另一部分節點用UDP來運行。相較於TCP，UDP能夠提高5%的流暢度。

在霧節點選擇方面，藉助智能調度系統，就近選擇節點，解決運營商之間的互聯互通問題，避免跨運營商的狀況發生。

多種測試肯定最合適參數

又拍雲PrismCDN中低延時、高分享率以及流暢性這些指標很是重要。可是這些指標中好幾個是互相矛盾的，好比說分享率和流暢性，如何在提升分享率的同時提高流暢性？咱們在開發的過程中就在調整這些參數，經過線上系統大規模AB測試不斷尋找合適的參數，找到合適的時間點補數據，用多少節點傳輸數據，用多少冗餘節點等。

將來發展

除了P2PHLS以外，又拍雲還在研發WebP2P，這裏面會用到WebRTC、DataChannel、MSE、Webassembly等技術。咱們去銷售P2P產品的時候，市場上確實會有一些阻力，由於客戶可能會不大信任SDK的P2P產品，包括它的升級和分發渠道，以及出了問題之後如何回滾。可是用WebP2P來作，客戶會比較放心了，萬一P2P系統有問題，能夠快速回滾到老版本去。