馮迅：YY多媒體實時傳輸系統演進

本文來自YY基礎架構部負責人馮迅在LiveVideoStackCon 2017上的分享，並由LiveVideoStack社群整理而成。馮迅重點介紹了，YY直播平臺的架構演進，包括技術棧選擇權衡，自建網路與採購CDN協作等。

文 / 馮迅

整理 / LiveVideoStack

大家好，我是馮迅，目前在歡聚時代（YY）主要負責音視訊傳輸系統和音視訊直播後端系統。今天想與大家分享的是YY的媒體實時傳輸系統與優化實踐。YY是一家專注於打造專業直播平臺與直播內容的網際網路公司，業務主要涵蓋了BGC、UGC與其背後的多樣性玩法等領域。

本次分享內容主要分為以下幾個方面：

1、實時可靠傳輸的重要性

2、不實時、不可靠的影響因素

3、直播傳輸網路架構演變

4、實時、可靠性優化

5、與CDN結合案例

1、實時可靠傳輸的重要性

想必大家都看過《新聞聯播》，其中可以明顯注意到的現象是直播間主播與現場記者連線交流時會出現不同程度的延遲；隨著網際網路技術的飛速發展，對於手機視訊直播而言，消費者不再滿足於單純的直播視訊觀看，而是追求更多新鮮、有趣的玩法。包括YY一直在嘗試的“歡樂籃球”或“陪你玩兒”、“一起玩兒”在內，隨著直播場景的不斷延伸，這些衍生直播玩法越來越強調互動性，其對網路實時傳輸的可靠性也提出了更高的要求。

2、不實時、不可靠的影響因素

對於實時性傳輸的探索，通常我們會關注以下三個關鍵指標：時延、丟包和時延抖動。由於所處網路環境的複雜多樣，實時性傳輸受到不穩定網路干擾的可能性非常大，甚至於在某個時刻也許會出現連續丟包導致時延驟增，持續一兩秒後恢復正常的現象；在生活中，Wi-Fi可以說是無處不在，但當我們在覆蓋Wi-Fi的房間中走動或有強雷干擾時，Wi-Fi訊號就會變得非常不穩定；除此之外，無論是在核心網還是接入網都需要面對的問題是：網路擁塞——由於鏈路的頻寬或路由節點的效能無法滿足要求導致的網路擁塞會逐漸增大RDT的時延，最終導致丟包。在YY的實際運營中我們經常會發現，即使某兩個機房之間的傳輸質量很好，但在某兩個伺服器或某些IP段間卻會出現不定時的丟包。其實這並不代表兩個機房間的傳輸質量變差或者頻寬下降，而是由於運營商或中間的路由結點施行的一些如防火牆或流控等策略，這些策略會將部分重要的資料包隨機丟掉。這種隨機性丟包對業務邏輯處理造成的影響主要體現在有效媒體流的接收延時增大，而時延的不確定增長與縮短的情況如果經常出現，就可將其稱為時延抖動。

上圖展示的是YY網路的傳輸架構圖。我們可以看到，從客戶端APP通過有線與無線網路選擇就近的運營商，之後接入到YY的分發系統再到最終的觀眾端，整體的網路路徑比較長並且在包括無線鏈路、運營商接入節點等核心骨幹網的整條路徑任何地方都有可能出現丟包。面對更加複雜的廣域網環境，我們該如何解決這種不實時性和不可靠性？我認為從端到端的思想出發，不能完全依賴某個演算法或重傳機制，而是需要一個系統性的解決方法。

3、直播傳輸網路架構演變

3.1 演進前

首先，瞭解一下YY傳輸網路的演變過程。最初YY的核心網是基於廣域網自建的一層虛擬網路，其中包括對A端到B端的可行路由進行探測的智慧路由探測系統。資料從主播端接入的邊緣節點，傳遞到中間的轉發節點再到觀眾端的邊緣節點，這整個過程需要考慮兩個關鍵點：1、邊緣節點對包括主播和觀眾在內所有使用者的處理策略是相同的，並不存在任何的區別。2、在業務邏輯上系統認為觀眾和主播的使用者屬性是相同的，因而在傳輸上也有一套統一的傳輸策略與機制。得益於我們在其中進行的許多優化，這套系統直到一兩年前也能穩定執行。當然隨著2016年直播行業的火熱，直播被賦予了更多創新玩法，特別是像剛剛說的歡樂鬥、歡樂籃球等，都是以一個互動性非常強的業務場景為基礎。如果不升級傳輸網路，那麼就意味著能夠承載這種強互動直播的網路，其複雜性會非常之高，現有網路已無法從容應對直播消費升級與使用者對直播產品的需求。結合由產品痛點作出的必要分析，我們對傳輸網路的架構進行了演進與升級。

3.2 演進後

上圖為演進後的YY傳輸網路架構圖，主要由主播分發網路、觀眾分發網路、內容雲處理三部分組成。我們可以根據上行流判斷誰是主播，並將包括主播間互動在內的所有活動都集中於主播分發系統，而觀眾則是一個純粹的觀看視角；即使有與主播互動的需求，觀眾端對時延性的要求也並不苛刻，因此資料可通過內容雲進行一些必要處理，然後再分發給觀眾。從這裡我們可以看出，演進後的網路架構相對於演進前，更加簡潔清晰。

這裡需要強調的是主播系統與觀眾系統的差別：

對於主播系統而言，從業務邏輯上來說，如果是針對類似於視訊會議的直播需求，我們的方案是將所有支撐功能的元件集中在主播分發系統當中，使其僅專注解決傳輸問題，不需要在關鍵元件上進行調整即可應對多種直播情景；從傳輸層面上來看，主播對互動性的要求很高，那麼在傳輸策略上，不僅需要保證傳輸流的質量符合要求，更需要控制時延在一個可以接受的範圍中。

對於觀眾而言，如果觀看的視訊畫面出現了幾百毫秒至一秒的延時，觀眾感知到的體驗折扣會小於主播感知到的。因為觀眾觀看直播只是單向的資料傳輸，對於時延的要求相對於主播系統而言更加寬鬆，因此在傳輸策略上觀眾端與主播端存在一定差別，觀眾更需要的是，在保證視訊播放基本流暢的前提下音訊與畫面是否清晰等等。

4、 實時、可靠優化

YY在實時、可靠優化上的工作主要有以下四個方面：

• 接入選擇

• 傳輸策略

• 多路聚合

• 網路加速

4.1 接入選擇

YY在後臺有一套龐大的資料統計系統，對從使用者資料接入到最終輸出質量的整體傳輸過程進行統計與評價。

例如北京的使用者接入北京的伺服器往往會比接到廣州效果更高，我們根據一系列統計資料判斷使用者每一種接入方式的質量並擇優分配；即使我們會對使用者優先採用就近接入的方式，但當出現類似於覆蓋能力較弱的小型運營商未接入某地或接入質量不佳的情況，我們也會考慮讓使用者從異地接入；除此之外，針對就近接入的伺服器出現故障進而影響服務穩定的情況，除了就近接入策略，我們也會在一個分割槽中為使用者分配多個接入節點並提供一種自動鏈路質量勘測的監測機制，在使用者端判斷多個接入點的質量並進行動態選擇；除了以上優化，為使用者分配鏈路節點時我們也會參考大資料庫，例如同一個區域的使用者在某個時間段集中選擇哪種接入方式，根據大資料反映的結果隨時調整分配策略，在充分考慮接入點選擇性的前提下儘可能優化接入效果。

4.2 傳輸策略

1）ARQ&FEC&頻寬估計三者結合

傳輸上的優化主要是前向糾錯（FEC）與後向糾錯也就是重傳（ARQ）。前向糾錯類似於我們常用的FEC在控制時延上佔有一定優勢，而重傳（ARQ）應該屬於後向糾錯的一種，本身意味著加大時延。在實際應用中我們會結合自己的一些要求採取不同的傳輸策略，但僅有這兩種策略還遠遠不夠，有時出現丟包意味著資料量超過了頻寬的最大限制，而一味地重傳會明顯增大頻寬壓力使得鏈路環境變得更差，單純地使用ARQ或FEC都是不可取的，正確的方案是在結合二者時根據對頻寬的預估結果確定比重從而避免不斷改變傳輸策略令網路環境持續惡化。在實際實踐中時我們需要根據業務屬性、音視訊流量、音訊冗餘情況等作出最優調整。隨著對音視訊資訊量的要求越來越高，視訊的位元速率也會越來越大，我們會通過一些編碼技術上的優化在保證視訊清晰度的前提下降低位元速率，從而在提升傳輸效果與使用者體驗的同時控制成本。

2）位元速率自適應

使用頻寬估計演算法估計網路兩端的頻寬範圍，再根據估計值指導後續視訊位元速率的調整，保證傳送的流量不會超過頻寬，儘可能避免丟包和擁塞的發生。有時即使降低頻寬也無法完全避免丟包的發生，或是在調整位元速率時需要考慮是否進行重傳與冗餘處理等，我們應該預留出足夠的資料空間，從而在發生特殊情況時能夠從容應對。

4.3 多路聚合

1）接入側聚合

接下來我將詳細介紹多路聚合過程。多路聚合主要用於接入端與核心網之間。有時大家會看到一些在山區或洞穴等無法獲得傳統有線或無線網路的環境中進行的直播，我們該如何應對這種苛刻的直播環境？在主播端我們整合了一套可提供多路無線接入功能的聚合YY MiFi方案，提供Wi-Fi與乙太網兩種接入介面。整套系統的原理類似於一個IP層下的多路UDP隧道，當一個TCP連線時,系統可通過多條不同網路傳輸路徑提升頻寬，當某個時間段出現傳輸質量不佳的情況時,可以在多個傳輸網路間實時切換保證傳輸穩定，資料傳輸至聚合閘道器後再被提取出TCP的原始內容。我們知道平時手機連線Wi-Fi時看到的IP是Wi-FI分配的內網IP，資料傳輸至運營商則使用公網IP，而聚合閘道器在資料的兩個方向上分別使用SNAT/DNAT進行不同IP轉換.。從客戶端發出若干個資料包，這些資料包的傳輸並不只是在一個通道上，而是根據不同通道質量好壞遵循多路選擇的策略，這套策略基於我們自主研發的一套演算法構建,目前在申請該演算法專利。經過實踐檢驗我們發現，採取上述措施可大大提高從主播或觀眾到接入伺服器之間資料傳輸的質量。

2）智慧分發網路

同樣，在智慧分發網路上我們也實現了多路路由機制。之前我提到YY在廣域網的基礎之上自建了一層虛擬網路也就是我們平時說的Overlay，這套網路的連線架構圖基於我們自主研發的一套由智慧路由監控系統。在接入節點側我們有一套選路演算法用於核心網不同節點之間的資料傳輸，假設我們為北京聯通到廣州電信兩個節點之間分配多條網路路徑，那麼資料傳輸時系統可能會擇優選擇一條鏈路傳輸資料，另外幾條則不傳輸或僅傳輸部分資料,也有很多人問為什麼不多條路徑一起傳輸冗餘資料更能保證質量？多路徑同時傳輸存在以下兩點問題：第一是隨著資料流的增多，節點的效能壓力會大大增加，效能壓力迫使伺服器的數量上升，繼而節點的分散程度就會增大，節點分散程度增大帶來的直接影響便是流量的加大，假設以前需要2個節點那麼現在則需要增加到4個才可滿足資料傳輸要求,當然,多路傳輸時,資料亂序導致的節點處理和延遲也需要考慮；第二是我們希望實現的是在保證傳輸質量不變的情況下儘可能降低傳輸成本，而在直播當中最昂貴的便是流量，流量增加一倍意味著成本的大幅提高。在智慧分發網路裡面，當面對類似於橫跨小運營商的情況，為其選擇一條質量比較高的鏈路即可解決不同運營商之間的跨網質量問題。

4.4 網路加速

1）TCP加速

首先介紹的是網路加速裡的TCP加速，想必大家不會對TCP加速感到陌生。我們從2015年開始探索TCP加速，因為類似於RTMP、HLS、FLV等都是基於TCP協議；由於TCP協議本身的一些擁塞演算法，在網路環境不佳時其對網路的退讓策略比較急進，這讓我們不得不尋找合適的解決方案。想要實現非常通用的TCP加速則需採用單向加速，雙向加速意味著對端的修改，這在TCP還未被人們所熟知的2015年是不現實並且難度較大的。基於當時的背景我們始終致力於TCP單向加速，主要運用在主播到分發網之間、邊緣節點到觀眾之間、核心網之間以及各個機房之間的加速。特別是在應對首屏秒開的情況，拉取上一個GOP資料流時，我們會通過使用TCP加速演算法對下行FLV或RTMP進行加速。YY基於Linux開發了上述一系列配套元件，我們知道在開發TCP加速時要麼與Google BBR相似，通過直接修改核心TCP協議機制程式碼，從而實現TCP加速，要麼就是在不修改核心的情況下通過擁塞演算法結合其他思路實現類似功能。對YY來說，修改核心涉及到的風險非常大，因而我們主要考慮的還是在核心模組中整合擁塞演算法等優化來實現TCP加速的效果，實踐的結果可以說符合大家的期待與需求。

2）報文傳送加速

接下來介紹的網路加速是報文傳送加速。因為網路直播本身是一個多窩的系統，這就意味著主播上傳的資料可能會發給成千上萬使用者，甚至發到某一端的一千、兩千個甚至更多的海量節點。報文傳送加速是一種常規的加速手段，如果通過UDP傳統的socket方式將資料傳送給一千人就需要呼叫系統至少上千次，每呼叫一次就意味著使用者態至核心態的切換。即使相對於TCP協議而言UDP協議的效能較高，但整個過程對效能的消耗依舊非常大。通過實驗我們發現，如果不經過加速就通過一個節點將資料轉發給幾百個使用者，那麼CPU將會嚴重超負荷運轉。我們該如何實現加速呢？首先需要做的是將核心態和使用者態通過記憶體共享方式打通，把資料包直接送至核心態中並隨之進行一次的系統呼叫，而此資料包在發給多端的過程中其內容是不改變的，改變的只是接收者。系統在把資料包送至核心態後，由核心進行多路轉發即可迅速成倍地提升效能。這裡是以傳送加速為例，而發生丟包或是網路擁塞除了鏈路頻寬以外還有一個很重要的因素就是中間節點的吞吐量效能處理，吞吐量也是決定一條鏈路頻寬能否提升的一個重要原因。

5、與CDN結合案例

大家可能會有一種感覺：YY的傳輸網路都是自己搭建的，為什麼不直接使用CDN呢？我們希望實現的是與CDN的深度融合，首先在布點方面，我們會考慮在部分邊遠地區或國外等布點成本比較高而CDN的覆蓋比較好的地區結合CDN解決一系列問題；其次在面對小運營商時，如果小運營商的問題可以用CDN妥善解決那麼我們也會採用；第三是我們會根據不同地區的CDN質量對佈網策略進行適當調整，如果某個區域CDN的質量具備明顯優勢，可以選擇讓其在質量上與我們佈網形成互補，最終呈現給使用者滿意的體驗。

我們期待通過YY在傳輸網路上的諸多改進與創新滿足網際網路直播的業務需求，為使用者帶來非凡的直播觀看體驗。

Q&A

Q1：MIFI多路聚合部分在IP層下實現的TCP加速具體是指什麼？

A：具體是指MiFi將整個TCP層封裝到IP層之上，MiFi決定使用運營商的哪條鏈路傳送資料至聚合閘道器，

通過多條傳輸路徑選擇提升TCP速度，這裡用到了“隧道”的技術。

Q2：在傳輸協議的選擇上是UDP還是TCP或是二者都有？

A：剛才沒有提到的是，我們的整個傳輸網路主要是基於UDP協議，TCP主要用於首屏秒開等需要快速拉取一定量資料的情景。例如當我們需要快速拉取視訊資料時可能剛好取到的是GOP幀中間的資料導致無法正常播放，這時往往需要獲取一個完整的GOP幀。最開始的這部分資料我們使用TCP進行快速拉取，後面整體依然採用的是UDP協議處理；另外TCP加速也可用於使用者使用FLV或RTMP觀看的單邊直播或主播使用RTMP推流的直播，都可以達到不錯的加速效果。

Q3:在網路加速部分是否考慮修改Linux核心?

A：不會，通訊行業在2010年左右提到一個使用者態驅動的方案，也就是打通使用者態和核心態直接通訊方式，把資料包直接丟進核心，需要做的只是在核心中新增一個模組而無需修改核心。修改核心意味著我們自己需要承擔核心變動背後的風險，這並不符合目前的要求。