隨著光纖入戶的普及和電腦性能的不斷提升，觀眾對(duì)直播的需求越來(lái)越高。常用的流媒體協(xié)議HLS雖已被廣泛用于PC和手機(jī)終端的音視頻服務(wù)，但在使用中仍然存在一些不足。我們邀請(qǐng)到嗶哩嗶哩彈幕視頻網(wǎng)直播技術(shù)部的姜軍老師，介紹基于HLS的直播P2P以及研發(fā)過(guò)程中他們遇到的挑戰(zhàn)及未來(lái)規(guī)劃。

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

在開發(fā)過(guò)程中或者是網(wǎng)絡(luò)搭建過(guò)程中，它可以大限度利用以前靜態(tài)文件的CDN服務(wù)，部署過(guò)程比較方便；但缺點(diǎn)是延時(shí)大，首幀加載慢。我們?cè)诠こ袒渴鸱?wù)的時(shí)候會(huì)有各種方式來(lái)緩解問(wèn)題。

前半部分介紹HLS的內(nèi)容，后半部分介紹基于HLS的P2P。因?yàn)镠LS是基于短文件的，一個(gè)個(gè)文件進(jìn)行分片傳輸，所以比較容易開發(fā)基于HLS的P2P。

今天的分享分為六個(gè)方面——引言、HLS直播、HLS直播的優(yōu)化、直播P2P、直播P2P的挑戰(zhàn)、去中心化協(xié)作。

#01 引言

首先是引言部分。

目前用戶對(duì)高清直播的需求越來(lái)越強(qiáng)烈，電腦性能的提升讓以前卡頓的視頻可以流暢播放，內(nèi)容平臺(tái)可以提供更高清的視頻，發(fā)揮硬件性能，得到更好的觀看體驗(yàn)。

直播畫質(zhì)的提升對(duì)編解碼器性能和寬帶成本提出了更高的要求，畫面和聲音越清晰，需要傳輸?shù)臄?shù)據(jù)越多。目前網(wǎng)絡(luò)成本一直處于很高的水平（按照帶寬計(jì)算費(fèi)用），如果為每個(gè)用戶提供高質(zhì)量?jī)?nèi)容，那帶寬的成本是非常大的。

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

嗶哩嗶哩現(xiàn)在可以將分享率（指上傳下載比）只有100%的時(shí)候?qū)⒐?jié)省率做到70%，這70%是用戶量不論多少表現(xiàn)相似。

#02 HLS篇

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

2.1.什么是HLS——HTTP Live Streaming

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

從上一個(gè)年代就開始使用電腦的人比較熟知，因?yàn)槟菚r(shí)的音樂(lè)播放器的文件列表格式是“.m3u”。m3u8其實(shí)是同樣的，它作為播放列表，隨著時(shí)間的推移里面的項(xiàng)越來(lái)越多，因?yàn)殡S著直播進(jìn)行、內(nèi)容總時(shí)長(zhǎng)是不斷增加的。

隨著新項(xiàng)的添加，舊項(xiàng)會(huì)被移除，和隊(duì)列一樣。HLS的播放列表里就會(huì)保持最后一小段時(shí)間內(nèi)容的文件列表，于是客戶端一邊輪詢m3u8文件的變化，一邊下載小分片進(jìn)行播放。

因?yàn)閭鹘y(tǒng)的MP4文件結(jié)構(gòu)所限，所有的索引放在一起、所有的數(shù)據(jù)放在一起，播放的時(shí)候兩者缺一不可，但得到完整數(shù)據(jù)之前無(wú)法拿到完整的索引。在這種情況下，傳統(tǒng)MP4文件雖然可以做到邊下邊播，卻無(wú)法實(shí)現(xiàn)直播。

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

左圖是傳統(tǒng)MP4。和分段MP4的不同，傳統(tǒng)MP4文件是一個(gè)大的索引，數(shù)據(jù)塊只有一大個(gè)；而分段MP4文件每一小塊都有索引和與其對(duì)應(yīng)的數(shù)據(jù)塊。把這樣一個(gè)分段MP4文件再切成一個(gè)個(gè)小文件之后，配上一個(gè)m3u8文件就可以變成HLS的流。

2.2.為什么用HLS

CDN部署更容易：HLS的CDN部署比較容易，因?yàn)樗谖募鬏敹皇情L(zhǎng)流傳輸，這樣的話傳統(tǒng)的靜態(tài)文件CDN只要經(jīng)過(guò)少量修改，對(duì)cache進(jìn)行配置，就能夠?qū)崿F(xiàn)支持HLS直播。

清晰度的動(dòng)態(tài)切換：因?yàn)镠LS是一個(gè)個(gè)短文件而沒(méi)有長(zhǎng)流，因?yàn)殚L(zhǎng)流比較難做清晰度切換的原因是從一個(gè)清晰度切到另一個(gè)清晰度時(shí)，我們難以知道剛才的位置所在，這種seek操作對(duì)服務(wù)器端開發(fā)難度比較大；但如果全是小文件的話，只要小文件能一個(gè)個(gè)在不同清晰度間對(duì)齊，那么切換清晰度就會(huì)很容易。

容易支持實(shí)時(shí)回看：在使用HLS的情況下，如果將分片文件的過(guò)期時(shí)間設(shè)置比較長(zhǎng)，那么當(dāng)用戶進(jìn)入直播間較遲、又想看早一些的內(nèi)容，客戶端就可以把舊的分片文件提供給該用戶看。

原生支持移動(dòng)版Safari：Safari和其它瀏覽器不同的是它在移動(dòng)端沒(méi)有Media Source Extension組件；也就是說(shuō)如果不是Safari的video標(biāo)簽直接支持的流，那就無(wú)法播放。

原生支持H.265，AV1等新編碼：HLS依托MP4結(jié)構(gòu)，可以原生支持H.265，AV1，而不是通過(guò)一些民間的hack協(xié)議去做的，目前線上用的最多的FLV，因?yàn)楦鱾€(gè)新協(xié)議都是通過(guò)不停地hack來(lái)追加的，所以各種工具系統(tǒng)的原生支持比較差。

比如我想要Flv支持H.265，發(fā)現(xiàn)現(xiàn)有的軟件系統(tǒng)都不支持，那就必須一個(gè)個(gè)改造過(guò)去；如果不同的廠商hack方式不同，那么這些系統(tǒng)之間就無(wú)法互相集成。

2.3.HLS直播的優(yōu)化

我們主要從三個(gè)方面進(jìn)行優(yōu)化：

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

非關(guān)鍵幀切割：關(guān)鍵幀是用來(lái)起播的，起播之后，剩下的數(shù)據(jù)可以不以關(guān)鍵幀為邊界往瀏覽器里送，這樣切割長(zhǎng)度就可以比較小（比如0.5s或1s一個(gè)片），傳輸延遲也可以降低。以前的HLS，因?yàn)槊總€(gè)分片要從關(guān)鍵幀開始，不然會(huì)黑屏；如果能支持非關(guān)鍵幀切割，延遲問(wèn)題就能隨之解決。

多文件合并：分片文件可以邊下邊播，，你會(huì)發(fā)現(xiàn)圖片右邊劃分的還是init分片、001、002，實(shí)際上在這里面001還可以細(xì)分為更小分片（001.2、001.3），這種更小的分片可以作為同一個(gè)文件傳輸。

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

那么文件只要下載前1/3就可以直接送給瀏覽器，瀏覽器開始播放畫面），可以提高用戶體驗(yàn)：因?yàn)樵谖募潞弥埃嬅婢涂梢匀砍鰜?lái)，不會(huì)出現(xiàn)用戶進(jìn)入直播間很久卻沒(méi)加載出畫面的情況。

#03 P2P篇

我們做HLS的一個(gè)主要目的實(shí)際上是開發(fā)P2P。因?yàn)镠LS小文件分片的傳輸方式是比較適合開發(fā)P2P的：小文件是天然切割好的分片單位，也就是可以以文件為單位在用戶之間交換數(shù)據(jù)。

P2P篇分為三部分來(lái)介紹：直播P2P、直播P2P的挑戰(zhàn)，最關(guān)鍵的去中心化協(xié)作。

3.1.直播P2P

P2P實(shí)際上流程比較簡(jiǎn)單，它跟傳統(tǒng)直播比起來(lái)實(shí)際就多了一個(gè)用戶之間的數(shù)據(jù)交換，P2P相關(guān)的邏輯在很多年之前就一直存在，從BitTorrent到電騾都是基于P2P進(jìn)行數(shù)據(jù)傳輸?shù)模嚓P(guān)概念這里我直接套用當(dāng)年的解釋。

比如P2P過(guò)程中網(wǎng)絡(luò)中的Peer概念，它代表整個(gè)P2P網(wǎng)絡(luò)的對(duì)等節(jié)點(diǎn)，他們之間會(huì)互相傳輸數(shù)據(jù)；提供數(shù)據(jù)和接受數(shù)據(jù)的角色分別為Seeder和Leecher，他們都可以算作Peer。在我們?cè)O(shè)計(jì)的P2P網(wǎng)絡(luò)中，Seeder和Leecher是混合的，也就是一個(gè)用戶既做Seeder又做Leecher，然后互相交換數(shù)據(jù)。

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

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

P2P下載流程如圖所示，從每個(gè)分片開始下載到交付數(shù)據(jù)給播放器，其中包括了三個(gè)節(jié)點(diǎn)，這些節(jié)點(diǎn)有的可以跳過(guò)。

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

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

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

無(wú)需要可不下載種子數(shù)據(jù)。剛才舉例說(shuō)的4個(gè)用戶交換數(shù)據(jù)的情況是因?yàn)橹挥?個(gè)用戶。但如果有六個(gè)用戶，就可以出現(xiàn)這樣一種情況：6個(gè)用戶中有的人不從CDN下載數(shù)據(jù)，只從P2P網(wǎng)絡(luò)下載，我們現(xiàn)在這套協(xié)議支持?jǐn)?shù)據(jù)從P2P網(wǎng)絡(luò)來(lái)再回到P2P網(wǎng)絡(luò)里去，整個(gè)過(guò)程是幫別人倒手?jǐn)?shù)據(jù)，但自己手頭上也就有這部分?jǐn)?shù)據(jù)了，這樣效率比較高。

P2P交換數(shù)據(jù)彈性時(shí)長(zhǎng)。P2P時(shí)間過(guò)短，分享率無(wú)法上升，因?yàn)橛脩糁g交換數(shù)據(jù)需要一定時(shí)間。如果用戶播放器緩沖的數(shù)據(jù)比較多，可以給P2P留有更多時(shí)間進(jìn)行交換，這樣時(shí)長(zhǎng)可以調(diào)整，在保證分享率和節(jié)省率的條件下，做到用戶體驗(yàn)較好，延時(shí)不會(huì)變長(zhǎng)。

數(shù)據(jù)完整時(shí)不需要補(bǔ)缺。圖中下載缺失數(shù)據(jù)的節(jié)點(diǎn)，在當(dāng)獲取到完整數(shù)據(jù)時(shí)可以直接跳過(guò)。

3.2.直播P2P的挑戰(zhàn)

P2P的挑戰(zhàn)主要有三方面：

實(shí)時(shí)性要求高。因?yàn)楝F(xiàn)在做的是直播，而不是下載完成后觀看。BT用戶可以把文件掛在后臺(tái)慢慢下載一兩天，完成后再觀看。直播如果是下載完成再觀看的話就丟失了它本身的意義。實(shí)時(shí)性要求高是指下載速度必須大于播放器消費(fèi)速度。

直播間進(jìn)出頻繁。用戶進(jìn)出直播間頻繁會(huì)導(dǎo)致P2P網(wǎng)絡(luò)需要不斷調(diào)整。剛才說(shuō)到我們的這套流程和我在網(wǎng)上看到的別人的方案不太一樣是指，網(wǎng)上的流程是把不同用戶進(jìn)行分組，組內(nèi)用戶互相連接、根據(jù)服務(wù)器調(diào)度的任務(wù)進(jìn)行計(jì)劃的數(shù)據(jù)交換；

那么如果大量用戶頻繁進(jìn)出直播間，分組變化劇烈，還要考慮用戶間的連接成功率，調(diào)度是極大的挑戰(zhàn)，不易達(dá)到穩(wěn)定態(tài)，P2P的節(jié)省率就會(huì)受到影響。

網(wǎng)絡(luò)環(huán)境復(fù)雜。還是剛才的例子，有4個(gè)人連成小網(wǎng)絡(luò)，但這4個(gè)人的上行下載速度和數(shù)據(jù)傳輸速度不一定相同。可能A到B網(wǎng)絡(luò)傳輸好，C到D網(wǎng)絡(luò)傳輸差，但B到C又很好，這都是不一定的，還有可能是A到B差，但是B到A快。

網(wǎng)絡(luò)環(huán)境復(fù)雜，由服務(wù)器分配任務(wù)，決定誰(shuí)應(yīng)該下載什么，給誰(shuí)傳輸數(shù)據(jù)，那么服務(wù)器這邊就會(huì)有非常多每個(gè)用戶的狀態(tài)數(shù)據(jù)，還要隨著用戶實(shí)時(shí)變化，如此大量數(shù)據(jù)下進(jìn)行調(diào)度，這個(gè)難度非常大。

我們的P2P協(xié)議是基于WebRTC DataChannel的傳輸。DataChannel非常靈活，不需要視頻通道那樣傳輸完整視頻數(shù)據(jù)。意味著每個(gè)用戶只要有上行帶寬，離設(shè)定的“限制值”還有一定額度，就可以“供血”。因?yàn)橛玫氖荝TC標(biāo)準(zhǔn)協(xié)議，這套方案除了在瀏覽器里跑之外，還可以在手機(jī)端或是電腦的原生客戶端里跑。

這樣的好處是，手機(jī)和電腦情況不同，如果手機(jī)只能與手機(jī)互相連接，手機(jī)的網(wǎng)絡(luò)穩(wěn)定程度又通常比較差，那手機(jī)端的節(jié)省率會(huì)比較差；如果能夠?qū)蓚€(gè)網(wǎng)絡(luò)利用在一起，允許手機(jī)和電腦互相連接，就可以提高網(wǎng)絡(luò)的運(yùn)行效率。

P2P協(xié)議是設(shè)計(jì)成異步、重疊的實(shí)現(xiàn)。類似一個(gè)傳輸通道可以并發(fā)多個(gè)正在進(jìn)行的傳輸請(qǐng)求存在，舉個(gè)例子有點(diǎn)像HTTP/2，P2P協(xié)議是發(fā)出一個(gè)請(qǐng)求后不用等到回復(fù)就可以發(fā)送下一個(gè)。

Peer自發(fā)查詢+下載，搶占+重試的實(shí)現(xiàn)。“自發(fā)查詢”是指用戶下載數(shù)據(jù)時(shí)不需要知道誰(shuí)有數(shù)據(jù)，而是向大家廣播查詢下載進(jìn)度，等確認(rèn)對(duì)方持有想要的數(shù)據(jù)后，才發(fā)起下載。

這不是由服務(wù)器調(diào)度的，而是用戶之間自己調(diào)度。“搶占+重試”是指下載數(shù)據(jù)時(shí)，假設(shè)一個(gè)文件分為十個(gè)塊，現(xiàn)在要下載第一個(gè)塊就要發(fā)送請(qǐng)求下載，這時(shí)第一個(gè)塊相當(dāng)于一個(gè)任務(wù)。

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

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

3.3.分布式調(diào)度

現(xiàn)在P2P的任務(wù)分配不需要中心服務(wù)器進(jìn)行任務(wù)下發(fā)。雖然用戶會(huì)連一個(gè)服務(wù)器（因?yàn)閃ebRTC整個(gè)連接流程必須需要服務(wù)器參與）只是在服務(wù)器參與連接建立階段之后，不進(jìn)行任務(wù)下發(fā)。連接后所做的事情由用戶而不是服務(wù)器決定。

一邊傳輸一邊調(diào)整。回到4個(gè)用戶連成的小網(wǎng)絡(luò)的例子，他們從服務(wù)器下載4個(gè)不同的部分并進(jìn)行數(shù)據(jù)交換時(shí)，傳輸效率最高。極端來(lái)說(shuō)，P2P是服務(wù)器只要給一倍的數(shù)據(jù)就可以滿足所有直播間所有用戶的需求。這當(dāng)然幾乎不可能實(shí)現(xiàn)。

我們需要使用調(diào)整算法盡可能使服務(wù)器數(shù)據(jù)能夠少傳輸一點(diǎn)。在有P2P參與的情況下，服務(wù)器傳輸?shù)臄?shù)據(jù)里重復(fù)的越少，總數(shù)據(jù)量也就越少；

如果傳輸重復(fù)數(shù)據(jù)，服務(wù)器的帶寬利用率就會(huì)低。一邊傳輸一邊調(diào)整的“調(diào)整”是指4個(gè)用戶可以下載文件的不同部分，但因?yàn)橛脩舻倪M(jìn)進(jìn)出出，斷開之后可能有新用戶進(jìn)來(lái)，新用戶進(jìn)來(lái)之后不知道做什么，我們就需要一種算法來(lái)幫助新用戶決定下載文件的哪個(gè)部分。

我們采取的算法就是市場(chǎng)調(diào)整算法。

這是市場(chǎng)供求關(guān)系的仿制，把每個(gè)文件分成4份，每份獨(dú)立計(jì)算節(jié)省率與分享率，來(lái)計(jì)算供需關(guān)系。當(dāng)供應(yīng)數(shù)據(jù)方供應(yīng)量有限時(shí)，作為用戶就會(huì)發(fā)現(xiàn)在P2P網(wǎng)絡(luò)中下載數(shù)據(jù)非常困難。

此時(shí)我就會(huì)認(rèn)為市場(chǎng)中這個(gè)數(shù)據(jù)塊很緊缺，按照調(diào)度算法現(xiàn)在應(yīng)該補(bǔ)缺，比如用戶發(fā)現(xiàn)某個(gè)范圍數(shù)據(jù)無(wú)法從P2P網(wǎng)絡(luò)獲取，那他就會(huì)變?yōu)閺姆?wù)器中下載數(shù)據(jù)然后供給P2P網(wǎng)絡(luò)解決緊缺問(wèn)題。也有供大于求的情況（服務(wù)器重復(fù)吐數(shù)據(jù)），比如有很多用戶直接從服務(wù)器下載第一個(gè)分片，

那這樣的話其實(shí)意味著分享率很低：因?yàn)榇蠹叶家蠓?wù)器給同樣的數(shù)據(jù)，而這塊數(shù)據(jù)因?yàn)橄螺d的人多，通過(guò)P2P網(wǎng)絡(luò)來(lái)滿足是更優(yōu)的。供大于求的情況下，有的用戶就會(huì)由SDK內(nèi)部算法，變?yōu)檫@部分?jǐn)?shù)據(jù)就不從CDN下載，而是從別人那邊獲取的狀態(tài)。

根據(jù)供求關(guān)系做實(shí)時(shí)調(diào)整，最后收斂到供需平衡。變?yōu)檎糜羞@么多用戶下載數(shù)據(jù)傳輸給別人，而傳輸?shù)臄?shù)據(jù)正好是別人所需要的，不存在多下載或缺數(shù)據(jù)的情況。

現(xiàn)在這套算法在網(wǎng)上跑的時(shí)候，（曲線圖顯示跑出線上實(shí)際數(shù)據(jù)的實(shí)測(cè)效果）曲線代表節(jié)省率，可以看到比較接近75%，隨著用戶數(shù)上升下降，虛線波動(dòng)率不會(huì)很大，橫軸的幾個(gè)凹陷是在凌晨4點(diǎn)左右，那時(shí)用戶量太少不在考慮范圍內(nèi)，我們主要提升用戶量大時(shí)的節(jié)省率。

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

可以看出節(jié)省率對(duì)人數(shù)變化不敏感，因?yàn)閮?nèi)部是通過(guò)市場(chǎng)調(diào)節(jié)算法收斂到平衡。然后是可以適應(yīng)復(fù)雜網(wǎng)絡(luò)環(huán)境，這套供求關(guān)系在用戶手上有數(shù)據(jù)時(shí)分為兩種情況，一個(gè)是上行帶寬好，數(shù)據(jù)能夠發(fā)送出去。

另一個(gè)是上行帶寬不好，數(shù)據(jù)不能發(fā)送出去。如果由服務(wù)器調(diào)節(jié)，服務(wù)器還要考慮用戶帶寬的情況，調(diào)節(jié)算法會(huì)非常復(fù)雜；通過(guò)自適應(yīng)調(diào)節(jié)方式，當(dāng)用戶手上有數(shù)據(jù)但不能發(fā)送時(shí)，其他人會(huì)認(rèn)為這塊數(shù)據(jù)還是緊缺的。

3.4.其他相關(guān)結(jié)果

其他相關(guān)結(jié)果有兩方面。

第一是實(shí)時(shí)參數(shù)下發(fā)，市場(chǎng)調(diào)節(jié)算法中有許多小參數(shù)進(jìn)行控制，如果能夠看到參數(shù)的實(shí)時(shí)調(diào)整結(jié)果，調(diào)整效率會(huì)比較高，調(diào)整起來(lái)也會(huì)比較方便，最終拿到一套最優(yōu)的參數(shù)集合。

第二是QPS，之前提到用戶會(huì)使用Range請(qǐng)求文件下載。在我們上線之前最擔(dān)心的是用Range請(qǐng)求服務(wù)端會(huì)導(dǎo)致服務(wù)端的QPS非常高，但現(xiàn)在跑起來(lái)看效果發(fā)現(xiàn)有的P2P網(wǎng)絡(luò)傳輸?shù)腝PS與關(guān)閉P2P幾乎等同，在90%和110%之間來(lái)回波動(dòng)，90%是指開著P2P時(shí)QPS反而更低，而110%是指開著P2P，QPS會(huì)高10%左右。

目前帶寬最高線上數(shù)據(jù)跑起來(lái)可以達(dá)到110%，平時(shí)在100%左右波動(dòng)，凌晨節(jié)省率比較低的同時(shí)QPS也比較低。也就是說(shuō)在這套系統(tǒng)下，可以認(rèn)為QPS和純跑HLS幾乎等同。

3.5.未來(lái)研究方向

現(xiàn)在的算法雖然已經(jīng)在線上跑了，但還有許多方面需要進(jìn)行優(yōu)化：

縮短算法收斂耗時(shí)：算法收斂?jī)?nèi)部測(cè)試需要大概30s-60s達(dá)到供需平衡，雖然看起來(lái)時(shí)間短，但在用戶進(jìn)出頻繁情況下，網(wǎng)絡(luò)很難達(dá)到最優(yōu)情況，所以分享率一直在70%波動(dòng)。

我認(rèn)為有優(yōu)化的空間是之前有一個(gè)頻道直播了探月衛(wèi)星發(fā)射，和娛樂(lè)直播不同的是，觀眾進(jìn)入直播間后會(huì)一直等到衛(wèi)星發(fā)射完成才會(huì)退出，也就是用戶在直播間的時(shí)間會(huì)很長(zhǎng)。算法跑到了收斂，那次的分享率達(dá)到了80%。但用戶進(jìn)出頻繁是常態(tài)，還是需要優(yōu)化算法收斂時(shí)間從而達(dá)到更好的效果。

縮短P2P環(huán)節(jié)彈性時(shí)長(zhǎng)：剛才說(shuō)道，播放器的緩沖時(shí)間長(zhǎng)短可以調(diào)節(jié)P2P的使用時(shí)間，雖然可以提高P2P的分享率和節(jié)省率，但是壞處是P2P數(shù)據(jù)交換節(jié)點(diǎn)的耗時(shí)越長(zhǎng)，用戶看到的數(shù)據(jù)越延遲，這會(huì)降低用戶的體驗(yàn)，要把延遲降到接近不開P2P的情況才是更好的方向。

優(yōu)化數(shù)據(jù)塊路由：是指數(shù)據(jù)塊通過(guò)什么方式和線路從服務(wù)器到用戶端。現(xiàn)在整個(gè)通過(guò)“搶占”來(lái)傳輸數(shù)據(jù)，導(dǎo)致有的用戶一直處于“饑餓”狀態(tài)，如果服務(wù)器能夠干涉一點(diǎn)，通過(guò)算法將尾端用戶拉到前面，這樣會(huì)提升網(wǎng)絡(luò)分享率。

提升分配效率，下調(diào)分享率限制：雖然我們的分享率已經(jīng)調(diào)整為上傳不大于下載，但是用戶在任務(wù)管理器或是網(wǎng)絡(luò)監(jiān)測(cè)器中發(fā)現(xiàn)數(shù)據(jù)在跑的其實(shí)還會(huì)有點(diǎn)不愉快，如果再壓一壓上行速率，也可以提升用戶體驗(yàn)。體驗(yàn)不一定只包括網(wǎng)頁(yè)是否流暢，業(yè)務(wù)是否可用，可能還包括用戶在各個(gè)監(jiān)控看到的服務(wù)跑起來(lái)占用的資源。

以上是我分享的內(nèi)容，謝謝！

編輯：jq