騰訊視頻P2P帶寬節省率持續提高之路

要想提高P2P帶寬節省率，最直接的方式固然是壓縮CDN帶寬，但簡單粗暴的減小CDN下載勢必會帶來播放體驗問題。騰訊視頻數據傳輸研發高級工程師嚴華梁在LiveVideoStackCon 2019深圳的演講中詳細介紹了騰訊視頻針對P2P帶寬節省的最新探索與實踐。

文 / 嚴華梁

整理 / LiveVideoStack

PART1/P2P技術項目背景

P2P其實是利用用戶之間互相分享視頻的數據，來減小從CDN下載數據的量，從而達到帶寬節省的效果。

通常狀況下，在使用P2P進行帶寬節省的基礎上，服務所需帶寬的計算公式如上圖所示：帶寬 = 播放量平均碼率 *平均播放時長(1-P2P帶寬節省率)。觀看視頻的用戶除了從平臺服務器上調用數據，還會從其餘用戶那裏來調用數據。

騰訊視頻業務在過去幾年迎來了高速的發展，用戶規模不斷提升，不管是播放量仍是視頻平均碼率都有明顯的提高。此時擺在咱們面前的一大挑戰就是：如何持續提高P2P帶寬節省率，並作到CDN帶寬成本保持較少增加？

上圖展示了咱們提高P2P帶寬節省率的思路。結合以前的帶寬計算公式咱們可知，若是須要下降CDN的帶寬成本，最簡單粗暴的方式就是減小CDN的下載，但這樣會帶來諸如卡頓的音視頻體驗問題。咱們的思路是首先系統性地優化P2P網絡的傳輸效率。因爲P2P網絡是一個對端網絡，所以須要從下載端與上傳端兩個方面綜合看待該項命題。那麼在完成對P2P的系統優化以後，在此基礎上咱們還須要考慮更少的CDN下載，接下來咱們就分階段思考如何實現這一目標。

PART2/如何提高P2P帶寬節省率？

若想實現更快的P2P下載，須要作的第一件事情即是傳輸協議的優化。衆所周知，在TCP中存在一個慢啓動閾值，爲了優化擁塞控制算法咱們須要對慢啓動閾值進行動態設定，算法策略其實就是經典的ssthresh=max(BDP, cwndα/10)。在此基礎之上咱們又引入兩個策略：丟包避免與丟包過濾。丟包避免從下降丟包率入手，也就是最近RTT大於rttMin+(rttMax-rttMin) β/100，cwnd不增長；丟包過濾從提升吞吐率入手，也就是最近RTT小於rttMin+(rttMax-rttMin)* γ/100， cwnd不退避。上圖展現了咱們自研的P2P擁塞控制算法與TCP Cubic的對比結果，紅線表明TCP Cubic而藍色則表明咱們自研的P2P CC。從數據中能夠看到當出現網絡抖動時，TCP Cubic對丟包和時延比較敏感，滑動窗口抖動很是劇烈，而P2P CC則相對平穩許多。

TCP的擁塞控制儘管已經演化多年，但仍舊存在較多問題。這告訴咱們一個道理：沒有一種擁塞控制算法可以適應全部的業務場景或者說網絡場景。所以咱們但願經過結合應用場景來實現個性化的擁塞控制。

所謂的個性化擁塞控制其實就是依據播放時間線進行差別化傳輸。如上圖所示，播放時間線從播放點開始梳理，播放點日後開始讀取數據。那麼離播放點越近的數據則會被優先讀取到，即優先級較高。因而在這一區間段內咱們採用比較激進的擁塞控制參數，儘量保證傳輸的效率而損失一部分丟包重傳的優化；在距離播放點較遠的區段內，採用另一種策略—— 優先考慮丟包率和重傳率並下降吞吐率。上圖展現的是新舊算法P2P下載速度的對比，咱們能夠看到相對於固定閾值的舊算法，新算法尤爲是在FAST與MEDIUM檔有明顯提高。在網絡下載效率方面，優化後的總體重複下載率較以前有很是明顯的提高。

解決完擁塞控制的相關命題，接下來面對的是如何進行有效選種並高效利用。最關鍵的一點即是如何評估種子的質量。

這裏咱們引入一套完整的基於QoS的選種淘汰機制：第一項考察的指標是數據完整度，例如在PC客戶端的磁盤內存在一些緩存，PC客戶端上的數據相對更加完整，這樣即可在整個視頻播放的過程當中提供更高質量的上傳數據；第二項考察的指標爲是否斷連；第三項是數據接收成功率，其中包括丟包率；最後一項指標是被凍結次數，也就是當鏈接上一個比較好的種子以後，對上傳效率的影響是積極的。但若是進行一次數據交互以後對端提供的反饋信令結果是忙碌，那麼多是由於種子質量出色而鏈接的對象有些多。在這種狀況下，該時間段內負載已經達到較爲滿負荷的狀態，有可能超過了硬件可承載的水平。當有新的請求過來時，會反饋忙碌的狀態，從而控制下載請求。但因爲該種子質量出色，所以服務器會選擇對該鏈路進行凍結處理，暫時不向該端請求數據傳輸，並保留對接的端口，待該端再也不忙碌以後繼續請求下載數據。

隨着智能路由器的普及，NAT類型被限制得愈來愈嚴格，P2P想找到一個質量出色的種子併成功鏈接的機率愈來愈低、難度愈來愈大，所以設計這樣的保護機制能夠確保種子物盡其用。

選種以後面臨的問題是選片。在P2P傳輸中，一個流媒體文件會被作切片處理，從而更充分地利用UDP進行傳輸。UDP自己發送一個數據包會受MTU的影響，例如以64K爲一片，切片一段文件，並以不一樣顏色表示若干個文件片斷的下載狀態。每一片應當分配給哪個種子來實現P2P下載？這是咱們在選片算法當中須要考慮的問題。

結合時間線，咱們提出了一個被稱爲集中式協同選片算法的策略。按照時間軸進行梳理，離播放點近的數據是即將被播放的，下載優先級最高。這裏的「集中式」就是指集中下載優先級高的數據，從而保證總體播放的流暢。「協同」則是指多個種子對優先級高的某一區域數據進行協同下載，例如前面幾片分配給一個種子，後面幾片分配給另一個種子。若是簡單粗暴地讓64K數據直接向某一個種子提出下載請求，那麼一旦該種子下線或對應的網絡中斷，那麼64K的數據至關於被總體丟包，假如丟包的數據處於距離播放點較近的位置，短期內又沒法高效地下載，就會出現播放的中斷。

爲了作到集中式協同下載，咱們引入了兩個隊列：可下載塊隊列與正在下載塊隊列。在P2P中，經過種子之間的位圖交換，咱們能夠獲知應當下載哪些塊，這即是可下載塊隊列。正在下載塊隊列的大小是相對固定的，也就是說對於任何一個種子，若是在選片時發現正在下載的塊沒有完整下載完畢，那麼就會優先下載這一部分。例如一個種子開始下載，此時系統發現其餘種子超時，那麼系統不會從新下載別的分片而是繼續下載該種子後面的分片，從而利用這種集中式協同的思路，儘量完整地下載某一塊數據。咱們知道UDP的數據傳輸沒有TCP那樣嚴格依賴順序，而集中式協同的設計主要是爲了按順序儘量快地將距離播放點比較近的數據下載下來，從而實現P2P下載效率與播放體驗的精準平衡。

全平臺的視頻介質統一相當重要，你們知道廣播電視行業須要牌照，這樣影視做品才能在TV端合法上線。但騰訊沒有這方面的牌照資質，所以咱們須要尋求外部牌照方合做。而第三方合做就存在一個問題：對方會要求在TV端播放時必須顯示牌照方的水印，而不能顯示騰訊視頻本身的水印。

通常狀況下，水印會被直接編碼在原視頻數據當中，稱爲「硬水印」。爲了作到全平臺統一，咱們則使用了軟水印技術，也就是將視頻內容與水印分開。同一個視頻內容在不一樣的平臺上，介質徹底同樣而水印顯示則根據場景改變，從而知足不一樣場景的水印需求。

咱們構建了一套系統性的種子質量提高方案：在第一層，系統會對一些無效的種子作過濾處理，這裏的「無效種子」更多的是指在一些限制條件下對種子的篩選擇優，如ISP過濾（以免對運營商網絡不友好的跨運營商傳輸）、NAT類型過濾（常規手段實現NAT穿透較爲困難，咱們會盡量選用對稱型以減小在穿透方面的損耗）、平臺過濾（更多考慮移動端，由於移動端存在運營商網絡的限制）、鏈接數過濾。

結束第一層過濾以後，咱們會根據一些屬性，使用多屬性權重打分決策算法對其進行處理。這裏的屬性主要有在線時長（可否提供穩定的在線上傳）、上傳能力（如100M、200M帶寬等）、NAT類型與地域就近。完成加權打分以後，咱們會對種子進行一個質量等級的劃分。隨後優先返回評分較高的種子，這樣可充分改善客戶端的種子建連與下載效率。

爲實現更多的P2P上傳，咱們還需優化上傳控制。在P2P網絡傳輸的早期，例如你們在大學時可能用過BT下載，若是宿舍裏面有一我的正在進行BT下載，那麼其餘人可能連常規的互聯網訪問都沒法正常進行。也就是說若是控制很差P2P的上傳過程，實際上會對TCP的ACK等普通網絡傳輸過程帶來不利影響，所以咱們但願實現更加出色的上傳控制。這裏的優化借鑑了類BBR的思路，也就是經過週期性地動態測速，對每一個P2P信道實時計算上行帶寬累加，並做爲限速值進行上傳動態限速控制，限速機制採用TCP中勻速發送的機制，從而下降瞬時大數據包對網絡傳輸鏈路的衝擊。

對於客戶端來講，經過信道鏈接不一樣種子，咱們這裏測量的是不一樣信道的帶寬狀況，並累加做爲總體上傳的限速值。上圖右側可視化圖表展現了動態測速方案的效果，咱們能夠看出其總體波動均勻集中。用戶在使用客戶端訪問服務時可能會同時進行一些其餘的上網行爲，例如看視頻時點擊某個網頁。測速圖表中的「PC空閒時間」就是指用戶未使用鼠標、鍵盤的時間，若是偵測到鼠標、鍵盤使用，那麼咱們則認爲用戶在訪問互聯網其餘服務。根據測速結果咱們能夠看到，隨着空閒時間不斷增長，動態測速呈現一個緩慢上升的趨勢，也就是說動態測速能夠感知並自適應用戶其餘訪問互聯網的行爲，並確保視頻服務的可用。

在完成對P2P下載與上傳的優化以後，咱們還需實現更少的CDN下載。咱們所作的第一件事就是優化http下載，對此咱們並未採用過於高深莫測的算法，而更多采用的是策略優化+擁塞控制優化（QUIC、BBR）。

策略上的優化，整體思想實際上是多元——第一項是MSS也就是IP直出和域名兜底。IP直出是爲了減小DNS解析所帶來的耗時，域名兜底則主要是爲了適應運營商的切換，如用戶從中國電信的Wi-Fi網絡切換到中國聯通的4G移動網絡，此時原電信服務器的IP須要切換至聯通服務器下的IP之上，咱們會對域名進行解析並實現兜底。

第二項是多IP競速鏈接，以前IP直出決定了有多個IP待選，這裏咱們使用了多IP競速鏈接以提升速度。

第三項是多連接加速，如今你們提到比較多的一個是MP TCP，也就是實現WiFi網卡與運營商網卡的組合加速。

在策略優化的基礎上，咱們進行了擁塞控制優化，如使用QUIC、BBR等。

若想實現更少的CDN下載，除了優化http，必不可少的一項舉措是合理利用CDN資源。

結合業務特性，咱們進行了系統調度的優化：首先嚐試深度整合業務，例如用戶訪問騰訊視頻，若是是非會員那麼會在正片開始以前看到一段時間較長的廣告。在廣告播放期間系統就可利用P2P網絡預先下載正片數據，在此期間CDN並未被使用。除此以外在播放專輯畫面時，若是專輯中上一集即將播放結束，那麼下一集便可開始預加載。固然還有一種狀況是用戶退出當前正片以後，可能須要從新點擊打開重複觀看，此時系統會對播放點數據作緩存處理，從而實現當用戶想要再次打開觀看時，系統可快速從本地加載數據並快速開始播放。

固然，若是是會員無廣告的狀況，爲了保證播放體驗咱們仍是會優先選擇CDN下載數據，從而保證快速啓動播放。在這裏咱們構建了一套網絡預測模型，結合歷史下載速度、實時下載速度與當前視頻碼率綜合作出決策，判斷啓動播放究竟須要多長時間，並儘量下降CDN的下載時長。例如當用戶使用光纖網絡時，因爲網絡帶寬資源充裕，下載速度較高，即使沒有P2P，CDN也可快速下載所需數據並實現快速啓動播放。

除以上兩點以外，咱們還會從用戶行爲入手。上圖右側圖線是咱們與香港中文大學進行的聯合研究的結果：不一樣的媒體類型如電影、電視劇、綜藝等，其視頻用戶中斷播放的位置也不盡相同。對於不一樣類型的視頻用戶在某一個時間段離開的機率不一樣，且存在必定規律。經過數據分析咱們能夠基於此在下載的時長控制方面進行一些針對性處理。

實現更少CDN下載的最後一點是多源體系建設。因爲CDN價格高昂，所以咱們應當科學調配內容與承載網絡類型之間的關係，從而實現產品服務與成本控制的精準平衡。

上圖左側展現了CDN的大概拓撲結構，從上到下依次是距離用戶比較遠的服務器、城市或社區的機房、家用路由器與用戶終端，與用戶之間的距離由遠及近。隨着5G時代的到來，你們常常提到的一個詞是移動邊緣計算也就是MEC，將來5G基站便可承擔一部分機房的角色。你們老是強調5G技術的高帶寬低延時，若是將來咱們的視頻內容直接下沉到基站，藉助5G網絡訪問就可達到相似於局域網的效果，其所能達到的速度是驚人的。若是CDN距離用戶較遠，那麼自己就存在一個傳輸鏈路上的損耗；咱們嘗試儘量縮短用戶與內容之間的距離，進一步突破互聯網傳輸技術對用戶體驗的桎梏。

PART3/總結

P2P節省率=P2P帶寬/ (P2P帶寬 + CDN帶寬)， 要想提高P2P帶寬節省率，最直接的方式固然是直接壓縮CDN帶寬，如減小CDN下載；可是簡單粗暴的減小CDN下載勢必會帶來播放體驗問題，因此咱們的思路是先優化P2P網絡， 在P2P網絡優化下載的效率和穩定性提高以後，再來合理的減小CDN下載。