騰訊雲低延時直播系統架構設計與弱網優化實踐

「直播帶貨」多是2020年最具表明性的詞彙之一，那麼傳統電商該如何融合直播系統，直播過程如何保障用戶的最佳觀看體驗？本文由騰訊雲資深架構師何書照在LiveVideoStack線上分享中的內容整理而成，詳解了大規模、低延時電商直播系統架構設計以及電商直播的難點、技術挑戰與突破。

文 / 何書照

整理 / LiveVideoStack

直播回放：

http://scrmtech.gensee.com/webcast/site/vod/play-6ced83f94af24094b6d8329948addb09

本次主要爲你們分享最近騰訊雲在低延時電商直播系統架構的設計與弱網優化實踐。

• 電商直播的難點、挑戰與技術突破

• 大規模、低延時電商直播系統架構設計

• 低延時直播系統弱網優化與互動連麥實踐

 電商直播的難點、挑戰與技術突破

電商直播主要分爲兩種：其一，當前直播或短視頻公司正在擁抱電商，其面臨的挑戰並不是直播相關技術，反而是電商系統的設計架構。其二，線下電商類客戶正在接觸直播，擁抱疫情期間出現的新形勢，其面臨的挑戰是如何將直播引入到電商系統中。

電商直播實際上是「電商+直播」的過程，直播過程是實時的流媒體，該流媒體強烈依賴從主播端到觀衆端的整條鏈路，整條鏈路中任何一個環節出問題，均可能致使用戶沒法搶購商品、轉化率下降。

 大規模、低延時電商直播系統架構設計

標準的電商系統的設計流程有7步：瀏覽產品 → 拍下訂單 → 支付商品 → 查看訂單 → 查看物流 → 確認收貨 → 退貨流程。

 

如上圖所示有三個模塊：便捷入口和渠道；快捷、交互、專家導購、購物體驗；更好服務的支持。我認爲直播屬於第二模塊的直播導購。

 

電商直播最近成爲熱點，一方面是疫情緣由；另外一方面，之前的頁面式或貨架式的電商，是客戶經過發現需求尋找不一樣的產品，再決定是否購買。隨着新技術的逐漸引入，這個過程須要更加切合用戶需求，而電商直播符合該趨勢。趨勢在於有一個專業導購，幫你匹配痛點，替代用戶進行貨比三家等購物時廣泛的痛點，也就是將線下在商場中的體驗搬到線上。

 

從個人觀察來看，電商直播領域剛剛開始，由於目前電商直播的模式剛剛興起，你們開始探討其中的一些體驗、互動甚至試穿等，將來還有很大的發展空間，電商直播將會是一個比較火熱的趨勢。

若要在現有的直播技術基礎上作好電商直播，首先須要瞭解業界的直播架構是怎樣的。如上圖，業界端到端的直播架構主要分爲四部分，總體的直播流程是：主播端和源站經過推流SDK或開源工具，經過RTMP協議推流到流媒體處理中心（一箇中心節點或中心機房），其中會進行不少處理，後經過CDN進行分發，最後觀衆端經過SDK或者Web頁面的H5觀看直播。

 

經過圖中的四大接入流程，將直播融入電商，最重要的接入流程是主播端和觀衆端。主播端須要經過APP進行宏觀的定製開發，將之前的電商系統結合到直播系統中，進行界面的互動，而且集成一些SDK等的推流支持。最重要的是觀衆體驗要好，讓觀衆經過直播引發購買慾直至下單。所以，觀衆端須要將當前電商能力與音視頻領域的技術能力良好結合。

 

另外直播後臺須要與電商後臺互通，作到人、貨、主播間的管理良好匹配，當出現大規模秒殺時，能夠及時更新數據。

如圖是根據近期的客戶需求整理的流程以及工做量

 

• 主播端 的工做量主要在產品和UI側，須要設計比較好的產品，產生較好的用戶體驗。剩餘的技術工做能夠基於原有系統迭代，根據雲上的直播SDK接口很容易接入。
• 服務端 的挑戰是研發能力，是在電商能力基礎上快速迭代直播CDN能力。因爲能力所有云化，所以集成工做很簡單，其次須要作的是對房間和用戶的管理。騰訊雲有不少DSMO可直接使用，集成工做完成後，再與電商系統相結合便可。
• 用戶端 主要將商品相關和UI能力複用。

 

對於產品評估，我的認爲方向有兩方面：一是產品和UI側，根據能力設計體驗。二是技術調研，即主播端、服務端、用戶端平行開發利用雲的能力。

 低延時直播系統弱網優化與互動連麥實踐

圖中架構省略了某些直播過程當中須要關注的、須要處理的點

 

如上圖爲騰訊雲直播架構，主播端經過SDK推流到上行接入點的數據中心，在數據中心進行相關處理後，進行轉碼，再利用CDN三級回源架構，經過用戶被動觸發進行拉流。騰訊雲的設計宗旨是不作無謂的浪費，只有當觀衆須要某一條數據流，發起拉流轉碼時，再轉碼。

圍繞整個騰訊雲直播架構進行拆分，上行分爲三種方式：

1. 最經常使用的經過RTMP推流方式推到雲端。
2. 經過RTMP拉流的方式，擁有本身的上行源站。
3. 經過HLS拉流方式，上行推到騰訊雲，騰訊雲處理加速以後經過協議分發。

最經常使用的是經過HTTP-FLV協議分發；經過HLS協議分發大多用在Web端或長視頻的處理，較少的使用RTMP協議處理。

 

 

主要看下行進行對應協議的選擇，若關心延時問題，則正常狀況下會選擇RTMP上行推流，端到端的延時可控制在2-5秒，下行通常選擇HTTP-FLV協議，其時延在2-5秒之間，缺點是Web端的兼容問題稍差。

 

Web端較爲經常使用的是HLS協議，基於HTTP切片，集合一段時間的數據進行，其不足是若切片大小不一致會形成總體延時較大，通常在10秒以上。RTP協議是目前的終極優化方案，其延時可達到100毫秒如下，大部分連麥是使用這種方式進行。

騰訊雲直播架構中的延時分爲三部分：

1. 主播端的採集、預處理、編碼、發送以及上行的網絡等推流端引入的延時；
2. 雲處理部分產生的延時，包括鏈路延時、轉碼引入的延時、不一樣的協議引入的延時不一樣，映射爲上行-轉碼-下行；
3. 下行的接收端與網絡強相關，映射爲接收-解碼-後處理-展現，都會產生相應延時。

對以上產生延時的點進行分析，以發現可優化部分。

 

低延時直播主要的優化方向和技術方向：

1. 上行或者下行通常基於原有的CDN架構進行正常優化；
2. Quic相較於HTTP/2更好一點，Quic優化的效果很明顯；
3. 使用WebRTC進行優化。

 

將來隨着5G甚至6G技術的發展，對於直播方面的優化方向會更多……

 

 

直播主要的質量監控和評測方式有如下6點：卡頓率、時延、開播失敗率、首幀時間、視頻幀率、視頻碼率，前四項，就能夠反映出本場直播的質量問題。

 

 

在未進行低延時優化以前的CDN上出現卡頓，如圖爲卡頓的斷定路徑，首先須要關注出現卡頓的狀況，若房間全部用戶都出現卡頓仍是部分用戶卡頓。

 

所有用戶卡頓的狀況則須要檢查上行過程，上行卡頓會致使整個房間都卡頓，首先進行同頻對比，其次確認上行推流的幀率、碼率是否正常，檢查流暢度，這些經過騰訊雲的後臺能夠獲取。

 

部分用戶卡頓的狀況須要檢測下行拉流狀況，根據用戶檢查其回源狀況，經過檢查拉流節點或者檢查用戶的卡頓日誌。

 

 

對於卡頓的優化，主播推流端須要進行的工做是：

• 網絡診斷：選用質量好的網絡
• 設置合理的參數：編碼設置，如幀率設置爲15以上。
• GOP設置爲合理的值。大型秀場或電商類直播通常設置爲1-2秒。

 

用戶端須要進行的工做：

• 查看CPU使用率，CPU被佔用較大，會出現卡頓
• 使用適合的碼率幀率對應使用的網絡環境
• 對於軟解碼建議開啓硬件加速
• 播放緩衝調整，可將播放端的緩衝加大，當網絡延時比較大時，可使用足夠的緩存消除卡頓 
• 網絡狀況診斷，進行網絡狀況較差，建議切換等提示
• 動態調整播放碼率：當正常使用HLS拉流，能夠與多種碼率匹配，使用FLV拉流，騰訊雲SDK能夠無縫切換碼率。

 

以上各類工做狀況均可以經過騰訊雲的後臺進行狀態查詢。

 

 

對於標準直播的延時，經過CDN的時延優化一樣分爲兩部分：

 

主播推流端：

• 網絡診斷：選用質量好的網絡
• GOP設置爲合理的值，若全部GOP值，延時也會縮小相應倍數，但同時會出現卡頓率變大的問題，所以須要設置合理的值。通常推薦爲1-2秒左右。
• 調整buffer，特別在OBS推流時，是自適應buffer，另外SDK的buffer也須要進行適配。
• 服務器避免轉碼，選擇中等碼率直接推流。

 

用戶播放端：

• 緩存DNS解析的IP,或者並行解析DNS
• 異步鑑權，先播放再鑑權。通常的鑑權服務器是3D設計，先推流，在後臺進行鑑權，若鑑權失敗斷開後續推流便可。
• 播放緩衝合理設置：緩衝越大時延越長。若使用IGK或其餘開源播放器建議設置GB爲1秒內，網絡的catch按照用戶對時延的要求對應設置，通常爲1-4秒之間（若想要追求很是低的時延，例如RTMP連麥時延等，設置爲1秒之內便可）。
• 選擇性丟幀：丟幀的策略在CDN和播放端都會使用，在CDN側若發現用戶是一個慢速用戶，網絡情況不好的狀況下，CDN就會選擇性丟幀，一樣播放器也會選擇一樣策略，以下降延時播放。
• SDK的快速播放策略：網絡良好的狀況下，按照1.5倍播放速度進行緩衝，網絡情況下降時，再調整爲慢播放，平衡選擇，以下降延時、減小卡頓。

 

 

若使用騰訊雲的SDK推流，上行速率掉底了，可是編碼器的音視頻碼率沒變化，這時就會出現卡頓，出現數據的堆積，當數據堆積超出紅線以上，就說明會出現卡頓和延時的問題。

 

騰訊雲的SDK主要關注3個參數：網絡上行速率SPD、音視頻編碼時的VRA和ARA，正常狀況下，VAR+ARA=SPD

 

 

騰訊雲SDK的下行回調參數會更加豐富些，針對這些參數的調整能夠優化延時和卡頓的問題。

 

騰訊雲SDK對低門檻用戶提供三種模式：自動模式（根據網絡情況自動調整）、極速模式（不引入鏈路延時，Catch設置爲1秒左右）、流暢模式，在電商或秀場類的直播情景一般會選擇極速模式。

 

若對延時和卡頓有更高要求，還有兩種匹配的優化方案。其一是基於QUIC的方式優化，其二是基於WebRTC進行優化，騰訊雲目前已經支持QUIC加速，經過RTMP推流時加標誌便可經過QUIC方式推流，這種加速方式通常要基於極速模式，下行能夠經過QUIC或WebRTC加速。

 

 

目前主流模式是經過WebRTC進行加速，優勢是SDK變更較小。基於標準OBS協議推流，上行處理過程即使每個過程都進行延時的缺省，也會有3-10秒的延時。

 

若利用WebRTC策略，上行經過RTMP標準協議計入成功後，經過WebRTC下行處理，同時優化轉碼、CDN分發等，經過代理的方式直接通到SDK，當客戶端集成SDK或使用Chrome瀏覽器默認支持，延時能夠控制在1秒之內。

 

第二個優化策略是使用TRTC技術，連麥互動時經過WebRTC或RTC進行上行承接，基於UDP加速，經過WebRTC到最近的服務端與經過TRTC的客戶端到最近的服務端兩種策略的時延都很小，這種策略適用於主播與觀衆連麥或者多個主播間PK的場景。

 

在TRTC基於UDP模式下進行的數據分析，端到端的延時大概在350毫秒左右，其優化點關注在350毫秒以上的優化。

 

 

對於推流端延時的解決方案，通常在SDK中埋點，推流端總體耗時在100毫秒之內；採集數據耗時通常在30毫秒左右；預處理耗時在30毫秒左右，有特效的耗時高於無特效耗時；編碼耗時通常在50毫秒之內，低端機型耗時較高；推流端耗時較大的是jitter buffer。

 

對於網絡耗時，經過分析後，使用WebRTC技術能夠將整個網絡的耗時維持在50毫秒之內。

 

 

對於播放端的耗時通常在100毫秒之內。

• 播放的解碼耗時通常在20毫秒之內，也有5%左右的超過50毫秒；
• 渲染耗時通常在20毫秒之內，有特效的耗時高於無特效耗時；
• 在播放端影響較大的是網絡波動，引入的耗時是20-200毫秒不等。

 

 

圖中表格數據爲協議詳細對比，網絡質量波動時，播放延時不會愈來愈大，網絡恢復後延遲能夠及時恢復。

 

WebRTC技術的網絡控制和播放策略是流暢優先，弱網環境下依然能夠保障能播放，不會一直卡住。

 

 

在低延時直播領域，除了傳統直播和WebRTC直播兩個主要的優化方向以外，還有基於QUIC方式的優化。基於QUIC的模式，大部分應用於CDN下行。

 

在弱網條件下對打開和關閉QUIC兩種狀況下的卡頓率進行比較，能夠看出，打開QUIC比關閉QUIC的卡頓率稍好。現階段一些大型廠商，也都在進行QUIC相關的優化和測試。

 

 

一樣，對打開QUIC和關閉QUIC條件下的時延狀況進行對比，網絡穩定狀態下，打開QUIC時延能夠下降100毫秒左右。

本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。