淘寶楊寬：淘寶直播低延遲架構演進和實踐

本文根據楊寬（阿里巴巴淘系技術 音視頻技術專家）於 2021 年 6 月 26 日舉辦的 ECUG Meetup 第 1 期 | 2021 音視頻技術最佳實踐·杭州站上的分享整理而成。本文長達 5500 餘字，主要結構以下：- 傳統直播技術痛點- 低延遲架構演進- 互動體驗升級- 關鍵技術獲取「講師完整版 PPT」 ，請添加 ECUG 小助手微信（微信ID：ECUGCON）並備註「ECUG PPT」。其他講師的分享也將於後續陸續放出，敬請期待。

---

如下爲分享正文：

 

你們下午好！首先自我介紹一下，工做以來主要是在音視頻相關領域，安防監控，互動直播、CDN 等，目前在淘寶作直播低延遲架構和 QoS 相關工做。 

 

1、傳統直播技術痛點

 

你們看，這是線上的一些直播場景。第一張圖主要是服飾的場景，下面有觀衆與主播的評論交互。在傳統直播的場景下，可能觀衆看的是 5-10 秒之後的畫面，當觀衆評論提問的時候，主播可能已經不介紹這款商品了，因此會有一個延遲的 Gap，交流就比較困難。第二個場景是珠寶的場景，介紹完鐲子之後可能會換下一款，可是觀衆可能看的仍是上一款鐲子。第三個是寵物直播場景。 傳統直播的主要痛點有三個： 

• 第一，延遲高，5-10 秒的延遲；
• 第二，主播和觀衆互動不及時；
• 第三，直播和連麥場景切換複雜。

 

---

2、低延遲架構演進 

 

這是傳統的一個直播架構。中間是 CDN 的分發網絡，最左邊是自建的 SFU 和 MCU 集羣。最右邊是支持的一些系統，好比說日誌、監控、配置、調度，最下面的圖是推拉流的 SDK。最上面是一個直播中心，有截圖，轉碼，錄製，切片等服務。 傳統的直播分發網絡是一個樹狀的結構。由於直播的量很大，樹型結構分發能夠控制成本。上行協議主要是 RTMP/WebRTC/私有 RTC，推到自建集羣，而後經過 rtmp 推到 CDN。下行協議主要是 HTTP-FLV/RTMP/HLS。 

 

這是咱們和 CDN 共建作的低延遲直播架構的改造，改造的點主要是 CDN 和觀衆播放器之間採用了 RTC 相關的技術，把延遲從 7 秒降到 1.5 秒左右。在業務上不只延遲下降了，方便觀衆和主播間的交流。並且在線上分行業AB顯示，在促進電商成交轉化方面也取得了不錯的效果。 

 

這個架構大概是咱們 2019 年開始和 CDN，視頻雲,  企業智能，XG 實驗室共建的架構，也是目前正在開始大規模使用的。能夠看到，中間 CDN 框架那邊所有走的是 RTC 的鏈路，再也不是樹型的結構，是去中心化的架構。L1 和 L1 之間能夠互通。若是 L1 和 L1 之間的通訊有問題，能夠走 L2 中轉。MCU 合流服務能夠像客戶端同樣直接鏈接到 RTC 的網絡上，把須要處理的流拉下來，處理完以後再從新推給 RTC 網絡。 主播經過 RTC 能夠和網絡直接通訊，若是須要它作一些實時流的處理的話，好比說加一些 AI 的特效，能夠經過實時流處理，處理完以後直接推給 RTC 整個網絡。觀衆也是經過 RTC 鏈路直接和這張網交互。 整個全鏈路 RTC 架構有幾個比較好的點。它是一個直播、通話、連麥、會議共用的一張網。不一樣的業務高峯使用的時間段不同。好比說直播，通常晚上觀看的人數比較多。會議基本上是白天開會。這樣不一樣業務就能夠錯峯地使用這張網。 由於 CDN 通常是根據天天峯值帶寬來計費，這樣白天能夠跑通話會議的業務，晚上會有一些直播的帶寬上來。經過錯峯，不一樣的業務錯峯來下降總體的成本。雙向實時通訊這塊兒，由於 RTC 既能夠推流也能夠拉流，在同一個連接裏能夠走多路流，這是不限制的。好比說，推一路流，拉十路流，都是能夠的。 

 

---

 3、互動體驗升級 

基於直播場景的互動體檢，主要對兩大部分進行了升級。 第一點，提升互動效率。消費者經過直播間和直播交流的時候，原來老的系統觀衆看到的畫面是 5-10 秒前的畫面，因此主播和觀衆互動的時候時間點是對不上的。升級之後的延遲優化爲 1 秒左右，使消費者和主播互動更及時。 第二點，指標優化。從延遲上說，能夠作到 1 秒之內，在通話會議場景能夠作到 200 毫秒左右。秒開率相對於原有的傳統直播系統能提高 32%，卡頓率下降 79%，卡頓 vv 下降 44%。 

 

這裏要講一下互動連麥直播原來的架構和目前架構的區別。 能夠看到，原來的架構主播是經過 RTC 自建集羣來轉發 RTC 的流，保證低延遲，而後連麥。觀衆是經過 CDN 來拉流觀看，中間走的是 rtmp 鏈路。若是是主播和主播之間的連麥，基本上是主播本身拉到對方的流，而後合流推到 CDN，而後再分發給觀衆看，這樣的一個流程。若是是主播和觀衆連麥，觀衆原本是在 CDN 這條鏈路上。在傳統的鏈路上，中間有一個延遲差，這個延遲差大概是 6-7 秒左右。經過 RTC 發起連麥的時候，經過 RTC 來連到自建集羣，而後和主播互相通訊的時候，畫面是有延遲差的，這樣體驗就很是很差，有一些等待切換的邏輯在裏面。 

在新架構下，能夠作到自建集羣和 CDN 是徹底融合爲一體。也就是說，CDN 內部也是走的全鏈路 RTC，不論是主播和主播的通訊，仍是觀衆和主播的通訊，徹底走的是 RTC 的鏈路。RTC 鏈路能夠經過一些傳輸優化保障，還有一些其餘技術的優化，可以保障它全部的體驗是統一的，好比說延遲、卡頓、流暢性等等。 下面是一個 MCU，就是合流服務器。若是主播或者說觀衆的設備是低端機的話，它的性能不太好，因此須要經過 MCU 來合流，這個合流服務器也是相似於客戶端的方式來接入這張網。而後經過把流拉下來，合完以後再推出去，由於咱們延遲優化的很低，基本上能作到無感的切換。 

這個架構模糊了觀衆、主播以及其餘一些服務的角色。做爲 RTC 的這張網來講，其實都是一個統一的接入者角色，既能夠推流，也能夠拉流。協議的話，都統一爲私有的 RTC 協議。咱們 RTC 的私有協議能夠作到一個 RTT 就能夠快速地拉流建連。場景這塊兒，目前直播場景、連麥場景、會議場景以及通話場景，能夠作到無縫切換。經過配置系統，針對不一樣的場景會啓用不一樣的策略。 

還有一個好處是，從自建集羣加 CDN 統一爲了一個集羣，節省了自建集羣的成本。總體的延遲也是比較低的。業務融合網絡，剛纔介紹了一部分，不一樣的業務能夠跑在同一張網上，由於業務主要使用的時間段不同，咱們能夠經過錯峯使用來下降總體的帶寬成本。 

---

4、關鍵技術 

 

咱們這邊和 CDN 是共建的關係。RTC Module 提供 RTC 相關的核心處理能力，以模塊化的方式嵌入到系統。 內部的模塊大概有如下這些：RTP/RTCP、BWE、QOS、PACE、PACKER、trickle/jitter、frame buffer、SRTP、setting 等等。BWE，主要是一些擁塞控制算法，QOS 這塊會有一些 QOS 的策略，像重傳，SVC，FEC 以及大小流相關的。trickle/jitter 主要做用是去抖和組幀。PACKER，有一些場景須要從視頻幀或者音頻幀打包成 RTP 格式。SRTP 主要是提供加解密的模塊。目前支持 grtn 私有協議和 webrtc 標準協議的交互。 在管理層，主要是有如下四種：

- 回調管理

- 訂閱管理

- session 管理

- 推拉流管理 

回調管理在系統和 RTC 核心處理層之間，經過一些回調函數來處理它們之間的交互，作到這兩層之間的隔離。 

 

基礎能力總結一下，主要是五點： 

第一，多協議的框架。支持 webrtc、grtn 協議。經過 grtn 私有協議接入的話，能夠保證總體接入效果。還有其餘一些私有擴展功能，比 webrtc 標準的交互效率會高不少。rtmp 和 http-flv 在這塊兒上也是支持的。

第二，音視頻 Pub/Sub 原子能力，方便使用擴展。

第三，Data Channel 單獨 Pub/Sub 管理，業務靈活定製。Data Channel 目前主要應用在控制信令和一些雲遊戲的場景。好比說觀衆和主播會經過 Data Channel 通道發一些控制信令，控制一些攝像機的動做或者說遊戲里人物的控制。設計的時候也考慮了它的靈活性，也是提供單獨的 Pub/Sub 的能力，能夠單獨使用。也就是說，若是在一個 URL 下只單獨作一個數據的通道，這也是沒問題的。Data Channel 通道的特色，咱們會提供單獨的傳輸保障。延遲能夠控制在全國範圍內大概 100-200 毫秒左右。若是是同一地域的話，基本上是一個 RTT。線上的話，平均大概的 RTT 是 20 毫秒左右。 還有一個運營場景是一些直播間的消息，若是經過傳統的消息系統基本上是秒級訂閱，或者是推拉的模式。咱們如今能夠作到百毫秒延遲之內。業務這塊能夠靈活定製，好比說能夠單獨掛消息通道的服務器，經過這個服務器各個端能夠單獨訂閱這個消息通道。作一些業務的活動，還有一些實時消息的下發，能夠作單獨的靈活定製。

第四，媒體和信令通道統一，可靠信令。信令咱們會保證它的可靠到達。你們都知道，UDP 在公網上是很容易丟的，因此咱們有一些保證它快速可達的策略，會有一些快速的重傳邏輯以及冗餘的邏輯。

第五，全網靈活切流能力，Url/Stream 級別。你們都知道，連麥的場景下，主播推直播間的流，他和別人連麥的時候，原來的方式是走 RTC 的自建集羣，RTC 自建集羣會處理切流的動做。由於全部的主播流都會走自建集羣，他在切流的時候，由於數據源可控，能夠作到切流的時候不會影響後面全部的播放。在全鏈路 RTC 的時候，實際上是一個分佈式的系統，主播和主播要連麥的時候，接入點不一樣，總體是分佈式的系統，切流能力就會保證他在切換過程當中，可以保證全網的觀衆在同一時刻切到合流的畫面。能夠作到 Url 和 Stream 級別，也就是說不一樣的 Stream 也能夠自由切換。 

傳統的直播鏈路中間是走 TCP，由於 TCP 在內核層，系統會提供一些策略，定製優化很難。咱們如今用全鏈路 RTC，用的是 UDP，UDP 是不可靠的。全鏈路 QoS 策略這塊就顯得很重要。 音視頻系統有一個特色，從採集到前處理到編碼，到傳輸而後到解碼、渲染，實際上是一個串行的過程，中間任何一個環節有問題都會影響總體的體驗。指標的話，有成功率、卡頓率、秒開、延遲等等一系列指標。 場景有直播、連麥、通話、會議，會議也要作，去作直播電商內部多人的互動。咱們作 QoS 要考慮多場景，要考慮 RTC 總體的傳輸鏈路，還有一些核心指標的優化。 

目前用到的算法，主要是BBR 和 GCC 算法。這兩個算法最開始是從 WebRTC 模塊化拿來使用。後來咱們幾乎重寫、重構了，提高了性能。而且針對直播的場景，深度定製優化。直播強調吞吐量，和會議場景的算法強調流暢仍是有些區別的。 

另外，咱們會針對不一樣的算法，在不一樣的業務場景去作大規模的AB。根據數據系統蒐集上來的不一樣指標、延遲等，來動態調整它的參數，不斷優化改進。帶寬分配算法，好比說服務器有音頻 帶寬、重傳帶寬、視頻帶寬，還有 SVC 的一些分層帶寬，還有小流。這些帶寬怎麼分配，在什麼樣的場景下用什麼樣的策略，帶寬分配算法要解決這些問題。 策略控制這塊兒，主要有 FEC、ARQ、SVC 等等。RED 是爲了保證音頻的低延遲，JitterBuffer 也作了一些優化，Pacer 也針對直播大的吞吐量作了改進。好比說咱們會作用多包發送的策略，以及中間鏈路的總體改進，還有 NetEq、延遲控制等等。 

 

分階段延遲優化我大體說一下。 作延遲優化的話，若是隻是一個簡單的場景，好比說一些數據量比較少的場景，這是比較簡單的，可是咱們的用戶量，包括主播的用戶量、觀衆的用戶量，天天上億的觀看，如何保證全網平均延遲降下來，這個挑戰是很大的。 延遲這塊咱們是這麼思考的：直播系統主要分爲推流端和播放器，中間走的是傳輸網絡，須要針對每一個階段單獨優化。

傳輸網絡部分，在網絡比較好的狀況，延遲仍是比較可控的，若是網絡很差，會啓用一些 QoS 的策略。採集、前處理、編碼，編碼這塊又分硬編、軟編，還有一些自研的編碼器。 發送緩存，也會動態的有一些策略。接收側的話，延遲比較大的主要是接收緩存，接收緩存這塊兒，若是和上行的網絡之間有丟包、抖動，接收緩存都會動態調整，把整個延遲加上去，爲了對抗前面的一些問題。

解碼這塊，包括解碼速度、解碼緩存以及不一樣的解碼器，好比說硬解、軟解之類的。還有一些後處理，解碼數量後處理的一些算法處理延遲。最後是渲染的延遲。 不一樣的平臺是不同的，IOS、Android、PC。好比 IOS 平臺前處理、編碼是怎麼樣的，大體的延遲分佈是什麼樣的，都要有數據報表，在線上採集出來，去作針對性的優化。Android，PC 也是一樣的。 

每一個階段會有針對性的優化，好比說編碼這塊，咱們會和算法團隊一塊兒優化，也會分不一樣平臺進行編碼部分的處理。編碼這塊兒也會放在線上，根據數據埋點系統分不一樣的平臺，分不一樣的編碼器，不一樣的版本作展現。 第二點，中間鏈路部分，主要是應用一些 QoS 的策略。還有一些調度，調度是和 CDN 合做的。規劃出根據不一樣鏈路之間的網絡質量、成本，規劃出一條最短的傳輸路徑。是質量、成本的一個綜合策略。再加上 QoS 策略，保證傳輸的這塊的延遲。 第三點，用戶量比較大，會統計分析每一階段的大盤延遲分佈，天天都會不一樣的報表展現。 

 

數據系統部分主要介紹四個： 

第一，全鏈路跟蹤質量展現分析。根據這個系統能夠跟蹤每一條鏈路中間通過的每一跳的服務器，它們之間的鏈路情況是怎麼樣的，包括錯誤碼以及碼率，這是一個全鏈路的分析。從每一個用戶到主播這條鏈路，根據惟一的一個 ID 就能查到這條鏈路上每一跳的質量，這樣就能夠針對線上不一樣的問題進行詳細地分析。 

第二，分段延遲分析展現。這個系統會根據不一樣的平臺、不一樣的主播、不一樣的階段，好比說編碼、解碼、緩存、渲染、傳輸等階段延遲的狀況。 

第三，配置 AB 系統。不論是端上的推流端仍是播放器端，都有大量的配置，好比說一些時延性的算法，一些業務的策略，能夠作到根據不一樣的業務進行分析，對比效果。舉個例子，要證實一下咱們優化的延遲對電商成交有沒有正向效果。咱們會選好比珠寶類的一些直播，還有一些衣服類的直播等等，根據不一樣的行業去作 AB，到底提高效果是怎麼樣的。 

第四，RTC 質量大盤。針對不一樣的地域、不一樣的域名會有一個總體的質量展現。包括推流質量、拉流質量，以及一些中間鏈路的質量等等。 

以上是我今天的分享內容，謝謝你們！ 

---

關於七牛雲、ECUG 和 ECUG Meetup

七牛雲：七牛雲成立於 2011 年，做爲國內知名的雲計算及數據服務提供商，七牛雲持續在海量文件存儲、CDN 內容分發、視頻點播、互動直播及大規模異構數據的智能分析與處理等領域的核心技術進行深度投入，致力於以數據科技全面驅動數字化將來，賦能各行各業全面進入數據時代。

ECUG：全稱爲 Effective Cloud User Group（實效雲計算用戶組），成立於 2007 年的 CN Erlounge II，由許式偉發起，是科技領域不可或缺的高端前沿團體。做爲行業技術進步的一扇窗口，ECUG 匯聚衆多技術人，關注當下熱點技術與尖端實踐，共同引領行業技術的變革。

ECUG Meetup ：ECUG、七牛雲聯合打造的技術分享系列活動，定位於開發者以及技術從業者的線下聚會，目標是爲開發者打造一個高質量的學習與社交平臺，期待每一位參會者之間知識的共創、共建和相互影響，產生新知推進認知發展以及技術進步，經過交流促進行業共同進步，爲開發者以及技術從業者打造更好的交流平臺與發展空間。