隨著光纖入戶的普及和電腦性能的不斷提升，觀眾對直播的需求越來越高。常用的流媒體協議HLS雖已被廣泛用于PC和手機終端的音視頻服務，但在使用中仍然存在一些不足。我們邀請到嗶哩嗶哩彈幕視頻網直播技術部的姜軍老師，介紹基于HLS的直播P2P以及研發過程中他們遇到的挑戰及未來規劃。

大家好，我是嗶哩嗶哩彈幕視頻網直播技術部的姜軍，今天主要介紹基于HLS的P2P。HLS是比較早的技術，全稱是HTTP Live Streaming，字面意思是利用HTTP進行播放直播。

在開發過程中或者是網絡搭建過程中，它可以大限度利用以前靜態文件的CDN服務，部署過程比較方便；但缺點是延時大，首幀加載慢。我們在工程化部署服務的時候會有各種方式來緩解問題。

前半部分介紹HLS的內容，后半部分介紹基于HLS的P2P。因為HLS是基于短文件的，一個個文件進行分片傳輸，所以比較容易開發基于HLS的P2P。

今天的分享分為六個方面——引言、HLS直播、HLS直播的優化、直播P2P、直播P2P的挑戰、去中心化協作。

#01 引言

首先是引言部分。

目前用戶對高清直播的需求越來越強烈，電腦性能的提升讓以前卡頓的視頻可以流暢播放，內容平臺可以提供更高清的視頻，發揮硬件性能，得到更好的觀看體驗。

直播畫質的提升對編解碼器性能和寬帶成本提出了更高的要求，畫面和聲音越清晰，需要傳輸的數據越多。目前網絡成本一直處于很高的水平（按照帶寬計算費用），如果為每個用戶提供高質量內容，那帶寬的成本是非常大的。

嗶哩嗶哩直播現在采用HLS傳輸和P2P相結合的方式，提升了服務器帶寬的利用效率（本來一倍量的帶寬給一倍量的人看，那么現在一倍量的帶寬可以給兩倍甚至三倍的人看，在相同的帶寬壓力下可以服務更多觀眾）。

嗶哩嗶哩現在可以將分享率（指上傳下載比）只有100%的時候將節省率做到70%，這70%是用戶量不論多少表現相似。

#02 HLS篇

首先向大家介紹前半部分——HLS。

2.1.什么是HLS——HTTP Live Streaming

HLS全稱是HTTP Live Streaming，字面意思是用HTTP做直播，HLS有很多版本。大家見到比較多的是舊版本的HLS，也就是一個m3u8的文件其中包含很多小的TS文件的列表。其實m3u8這樣的東西很多。

從上一個年代就開始使用電腦的人比較熟知，因為那時的音樂播放器的文件列表格式是“.m3u”。m3u8其實是同樣的，它作為播放列表，隨著時間的推移里面的項越來越多，因為隨著直播進行、內容總時長是不斷增加的。

隨著新項的添加，舊項會被移除，和隊列一樣。HLS的播放列表里就會保持最后一小段時間內容的文件列表，于是客戶端一邊輪詢m3u8文件的變化，一邊下載小分片進行播放。

因為傳統的MP4文件結構所限，所有的索引放在一起、所有的數據放在一起，播放的時候兩者缺一不可，但得到完整數據之前無法拿到完整的索引。在這種情況下，傳統MP4文件雖然可以做到邊下邊播，卻無法實現直播。

為了做到直播，MP4文件需要進行分段（0.5s或者1s為組），分完之后一邊傳給服務器，一邊服務器傳給用戶這樣進行直播。HLSv7是將分開后的數據塊獨立成小文件放在列表中，然后不斷更新m3u8的播放列表。

左圖是傳統MP4。和分段MP4的不同，傳統MP4文件是一個大的索引，數據塊只有一大個；而分段MP4文件每一小塊都有索引和與其對應的數據塊。把這樣一個分段MP4文件再切成一個個小文件之后，配上一個m3u8文件就可以變成HLS的流。

2.2.為什么用HLS

CDN部署更容易：HLS的CDN部署比較容易，因為它基于文件傳輸而不是長流傳輸，這樣的話傳統的靜態文件CDN只要經過少量修改，對cache進行配置，就能夠實現支持HLS直播。

清晰度的動態切換：因為HLS是一個個短文件而沒有長流，因為長流比較難做清晰度切換的原因是從一個清晰度切到另一個清晰度時，我們難以知道剛才的位置所在，這種seek操作對服務器端開發難度比較大；但如果全是小文件的話，只要小文件能一個個在不同清晰度間對齊，那么切換清晰度就會很容易。

容易支持實時回看：在使用HLS的情況下，如果將分片文件的過期時間設置比較長，那么當用戶進入直播間較遲、又想看早一些的內容，客戶端就可以把舊的分片文件提供給該用戶看。

原生支持移動版Safari：Safari和其它瀏覽器不同的是它在移動端沒有Media Source Extension組件；也就是說如果不是Safari的video標簽直接支持的流，那就無法播放。

原生支持H.265，AV1等新編碼：HLS依托MP4結構，可以原生支持H.265，AV1，而不是通過一些民間的hack協議去做的，目前線上用的最多的FLV，因為各個新協議都是通過不停地hack來追加的，所以各種工具系統的原生支持比較差。

比如我想要Flv支持H.265，發現現有的軟件系統都不支持，那就必須一個個改造過去；如果不同的廠商hack方式不同，那么這些系統之間就無法互相集成。

2.3.HLS直播的優化

我們主要從三個方面進行優化：

使用fMP4替代TS：大部分瀏覽器不能原生支持TS流，但能夠支持CMAF的長流，所以我們就根據新HLS協議，把里面的TS換成HLSv7里CMAF的格式，這樣數據拿下來之后直接送給瀏覽器，瀏覽器可以直接播放，中間不需要JavaScript腳本進行大規模處理，可以減少瀏覽器的CPU消耗，對用戶來說電腦不容易卡。

非關鍵幀切割：關鍵幀是用來起播的，起播之后，剩下的數據可以不以關鍵幀為邊界往瀏覽器里送，這樣切割長度就可以比較小（比如0.5s或1s一個片），傳輸延遲也可以降低。以前的HLS，因為每個分片要從關鍵幀開始，不然會黑屏；如果能支持非關鍵幀切割，延遲問題就能隨之解決。

多文件合并：分片文件可以邊下邊播，，你會發現圖片右邊劃分的還是init分片、001、002，實際上在這里面001還可以細分為更小分片（001.2、001.3），這種更小的分片可以作為同一個文件傳輸。

也就是說一個文件里可能不只有一個分片（指一個moof和mdat的組合），對于這種文件來說就可以邊下邊播（比如一個文件為1s，可以分為三個0.33s的小分片。

那么文件只要下載前1/3就可以直接送給瀏覽器，瀏覽器開始播放畫面），可以提高用戶體驗：因為在文件下好之前，畫面就可以全部出來，不會出現用戶進入直播間很久卻沒加載出畫面的情況。

#03 P2P篇

我們做HLS的一個主要目的實際上是開發P2P。因為HLS小文件分片的傳輸方式是比較適合開發P2P的：小文件是天然切割好的分片單位，也就是可以以文件為單位在用戶之間交換數據。

P2P篇分為三部分來介紹：直播P2P、直播P2P的挑戰，最關鍵的去中心化協作。

3.1.直播P2P

P2P實際上流程比較簡單，它跟傳統直播比起來實際就多了一個用戶之間的數據交換，P2P相關的邏輯在很多年之前就一直存在，從BitTorrent到電騾都是基于P2P進行數據傳輸的，相關概念這里我直接套用當年的解釋。

比如P2P過程中網絡中的Peer概念，它代表整個P2P網絡的對等節點，他們之間會互相傳輸數據；提供數據和接受數據的角色分別為Seeder和Leecher，他們都可以算作Peer。在我們設計的P2P網絡中，Seeder和Leecher是混合的，也就是一個用戶既做Seeder又做Leecher，然后互相交換數據。

分享率是指上行和下載的比率，在以前的BT軟件中這個概念是很常見的。BT軟件有一個功能是數據下載完成后，還要繼續做一段時間的種子才能停止，停止條件是分享率達到一個值（比如下載1G數據，分享率設置為1.5，意味著上行量到1.5G數據時就可以停止任務）。

我們現在是CDN和P2P混合使用，于是有了“節省率”這個概念，字面上是P2P下載占總下載比例的多少，比如P2P占了70%數據量，CDN占了30%，那么節省率就是70%。

P2P下載流程如圖所示，從每個分片開始下載到交付數據給播放器，其中包括了三個節點，這些節點有的可以跳過。

一開始下載種子數據，種子數據是指直接從CDN獲取、然后提供給其他用戶的數據，舉一個例子，比如我現在有4個用戶，他們互相組成小網絡，每個用戶都可以從服務器中下載1/4部分，當用戶下載完4個數據之后，服務器吐出的上行量實際上只有一倍，一個文件吐了4次每次四分之一，只是QPS會多一些。

用戶拿到各自數據之后，之間互相交換后就可以擁有完整數據。也有一種意外情況，4個用戶中有人下載了與別人相同的分片，這就導致整個網絡中有數據缺失，那么就要在P2P數據交換完成之后，從服務器補充缺失數據，最后交付給瀏覽器。

因為這套P2P基于純HLS，所以服務器不需要特殊適配。整個流程就是“下載種子數據、交換、下載缺失數據、交付”。標準的HLS完全可以滿足這套流程的正常運行。而一個片段文件的單個分片的下載，依靠HTTP的Range即可滿足，所以文件CDN頁不需要專門改造，正常可用地支持靜態文件下載，能支持Range，就能為這套P2P方案提供服務。

無需要可不下載種子數據。剛才舉例說的4個用戶交換數據的情況是因為只有4個用戶。但如果有六個用戶，就可以出現這樣一種情況：6個用戶中有的人不從CDN下載數據，只從P2P網絡下載，我們現在這套協議支持數據從P2P網絡來再回到P2P網絡里去，整個過程是幫別人倒手數據，但自己手頭上也就有這部分數據了，這樣效率比較高。

P2P交換數據彈性時長。P2P時間過短，分享率無法上升，因為用戶之間交換數據需要一定時間。如果用戶播放器緩沖的數據比較多，可以給P2P留有更多時間進行交換，這樣時長可以調整，在保證分享率和節省率的條件下，做到用戶體驗較好，延時不會變長。

數據完整時不需要補缺。圖中下載缺失數據的節點，在當獲取到完整數據時可以直接跳過。

3.2.直播P2P的挑戰

P2P的挑戰主要有三方面：

實時性要求高。因為現在做的是直播，而不是下載完成后觀看。BT用戶可以把文件掛在后臺慢慢下載一兩天，完成后再觀看。直播如果是下載完成再觀看的話就丟失了它本身的意義。實時性要求高是指下載速度必須大于播放器消費速度。

直播間進出頻繁。用戶進出直播間頻繁會導致P2P網絡需要不斷調整。剛才說到我們的這套流程和我在網上看到的別人的方案不太一樣是指，網上的流程是把不同用戶進行分組，組內用戶互相連接、根據服務器調度的任務進行計劃的數據交換；

那么如果大量用戶頻繁進出直播間，分組變化劇烈，還要考慮用戶間的連接成功率，調度是極大的挑戰，不易達到穩定態，P2P的節省率就會受到影響。

網絡環境復雜。還是剛才的例子，有4個人連成小網絡，但這4個人的上行下載速度和數據傳輸速度不一定相同。可能A到B網絡傳輸好，C到D網絡傳輸差，但B到C又很好，這都是不一定的，還有可能是A到B差，但是B到A快。

網絡環境復雜，由服務器分配任務，決定誰應該下載什么，給誰傳輸數據，那么服務器這邊就會有非常多每個用戶的狀態數據，還要隨著用戶實時變化，如此大量數據下進行調度，這個難度非常大。

我們的P2P協議是基于WebRTC DataChannel的傳輸。DataChannel非常靈活，不需要視頻通道那樣傳輸完整視頻數據。意味著每個用戶只要有上行帶寬，離設定的“限制值”還有一定額度，就可以“供血”。因為用的是RTC標準協議，這套方案除了在瀏覽器里跑之外，還可以在手機端或是電腦的原生客戶端里跑。

這樣的好處是，手機和電腦情況不同，如果手機只能與手機互相連接，手機的網絡穩定程度又通常比較差，那手機端的節省率會比較差；如果能夠將兩個網絡利用在一起，允許手機和電腦互相連接，就可以提高網絡的運行效率。

P2P協議是設計成異步、重疊的實現。類似一個傳輸通道可以并發多個正在進行的傳輸請求存在，舉個例子有點像HTTP/2，P2P協議是發出一個請求后不用等到回復就可以發送下一個。

Peer自發查詢+下載，搶占+重試的實現。“自發查詢”是指用戶下載數據時不需要知道誰有數據，而是向大家廣播查詢下載進度，等確認對方持有想要的數據后，才發起下載。

這不是由服務器調度的，而是用戶之間自己調度。“搶占+重試”是指下載數據時，假設一個文件分為十個塊，現在要下載第一個塊就要發送請求下載，這時第一個塊相當于一個任務。

但用戶情況多變，發送請求后可能斷開連接，那么第一個塊此時下載失敗，就要再找其他人嘗試。“搶占”就是廣播查詢時，誰先返回說有第一個塊，就先找誰下載。這樣才能夠保證較高的傳輸效率。如果我先拿到第一個塊的數據，就可以再把它給其他人，進行二級傳遞、三級傳遞，提高利用率。

上傳均勻分布。現在設定為每一個用戶上行不能大于下載，比如下載了1兆數據，上行量不能大于1兆。上行太高的話，會影響正常上網，使用戶網絡卡，影響其它軟件的使用，另外如果我是用戶看到上下行速度不對等，下載數據少，上傳數據多，心里會不愉快，就會進行投訴，這也是不好的影響。

3.3.分布式調度

現在P2P的任務分配不需要中心服務器進行任務下發。雖然用戶會連一個服務器（因為WebRTC整個連接流程必須需要服務器參與）只是在服務器參與連接建立階段之后，不進行任務下發。連接后所做的事情由用戶而不是服務器決定。

一邊傳輸一邊調整。回到4個用戶連成的小網絡的例子，他們從服務器下載4個不同的部分并進行數據交換時，傳輸效率最高。極端來說，P2P是服務器只要給一倍的數據就可以滿足所有直播間所有用戶的需求。這當然幾乎不可能實現。

我們需要使用調整算法盡可能使服務器數據能夠少傳輸一點。在有P2P參與的情況下，服務器傳輸的數據里重復的越少，總數據量也就越少；

如果傳輸重復數據，服務器的帶寬利用率就會低。一邊傳輸一邊調整的“調整”是指4個用戶可以下載文件的不同部分，但因為用戶的進進出出，斷開之后可能有新用戶進來，新用戶進來之后不知道做什么，我們就需要一種算法來幫助新用戶決定下載文件的哪個部分。

我們采取的算法就是市場調整算法。

這是市場供求關系的仿制，把每個文件分成4份，每份獨立計算節省率與分享率，來計算供需關系。當供應數據方供應量有限時，作為用戶就會發現在P2P網絡中下載數據非常困難。

此時我就會認為市場中這個數據塊很緊缺，按照調度算法現在應該補缺，比如用戶發現某個范圍數據無法從P2P網絡獲取，那他就會變為從服務器中下載數據然后供給P2P網絡解決緊缺問題。也有供大于求的情況（服務器重復吐數據），比如有很多用戶直接從服務器下載第一個分片，

那這樣的話其實意味著分享率很低：因為大家都要求服務器給同樣的數據，而這塊數據因為下載的人多，通過P2P網絡來滿足是更優的。供大于求的情況下，有的用戶就會由SDK內部算法，變為這部分數據就不從CDN下載，而是從別人那邊獲取的狀態。

根據供求關系做實時調整，最后收斂到供需平衡。變為正好有這么多用戶下載數據傳輸給別人，而傳輸的數據正好是別人所需要的，不存在多下載或缺數據的情況。

現在這套算法在網上跑的時候，（曲線圖顯示跑出線上實際數據的實測效果）曲線代表節省率，可以看到比較接近75%，隨著用戶數上升下降，虛線波動率不會很大，橫軸的幾個凹陷是在凌晨4點左右，那時用戶量太少不在考慮范圍內，我們主要提升用戶量大時的節省率。

用戶量急劇上升或下降的時候，節省率依然是保持穩定的，尖尖的幾條線代表帶寬（同時也就是人數的變化趨勢），隨著帶寬變化，節省率變化也不太大。

可以看出節省率對人數變化不敏感，因為內部是通過市場調節算法收斂到平衡。然后是可以適應復雜網絡環境，這套供求關系在用戶手上有數據時分為兩種情況，一個是上行帶寬好，數據能夠發送出去。

另一個是上行帶寬不好，數據不能發送出去。如果由服務器調節，服務器還要考慮用戶帶寬的情況，調節算法會非常復雜；通過自適應調節方式，當用戶手上有數據但不能發送時，其他人會認為這塊數據還是緊缺的。

3.4.其他相關結果

其他相關結果有兩方面。

第一是實時參數下發，市場調節算法中有許多小參數進行控制，如果能夠看到參數的實時調整結果，調整效率會比較高，調整起來也會比較方便，最終拿到一套最優的參數集合。

第二是QPS，之前提到用戶會使用Range請求文件下載。在我們上線之前最擔心的是用Range請求服務端會導致服務端的QPS非常高，但現在跑起來看效果發現有的P2P網絡傳輸的QPS與關閉P2P幾乎等同，在90%和110%之間來回波動，90%是指開著P2P時QPS反而更低，而110%是指開著P2P，QPS會高10%左右。

目前帶寬最高線上數據跑起來可以達到110%，平時在100%左右波動，凌晨節省率比較低的同時QPS也比較低。也就是說在這套系統下，可以認為QPS和純跑HLS幾乎等同。

3.5.未來研究方向

現在的算法雖然已經在線上跑了，但還有許多方面需要進行優化：

縮短算法收斂耗時：算法收斂內部測試需要大概30s-60s達到供需平衡，雖然看起來時間短，但在用戶進出頻繁情況下，網絡很難達到最優情況，所以分享率一直在70%波動。

我認為有優化的空間是之前有一個頻道直播了探月衛星發射，和娛樂直播不同的是，觀眾進入直播間后會一直等到衛星發射完成才會退出，也就是用戶在直播間的時間會很長。算法跑到了收斂，那次的分享率達到了80%。但用戶進出頻繁是常態，還是需要優化算法收斂時間從而達到更好的效果。

縮短P2P環節彈性時長：剛才說道，播放器的緩沖時間長短可以調節P2P的使用時間，雖然可以提高P2P的分享率和節省率，但是壞處是P2P數據交換節點的耗時越長，用戶看到的數據越延遲，這會降低用戶的體驗，要把延遲降到接近不開P2P的情況才是更好的方向。

優化數據塊路由：是指數據塊通過什么方式和線路從服務器到用戶端。現在整個通過“搶占”來傳輸數據，導致有的用戶一直處于“饑餓”狀態，如果服務器能夠干涉一點，通過算法將尾端用戶拉到前面，這樣會提升網絡分享率。

提升分配效率，下調分享率限制：雖然我們的分享率已經調整為上傳不大于下載，但是用戶在任務管理器或是網絡監測器中發現數據在跑的其實還會有點不愉快，如果再壓一壓上行速率，也可以提升用戶體驗。體驗不一定只包括網頁是否流暢，業務是否可用，可能還包括用戶在各個監控看到的服務跑起來占用的資源。

以上是我分享的內容，謝謝！

編輯：jq