“直播帶貨”可能是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三級回源架構，通過用戶被動觸發進行拉流。騰訊云的設計宗旨是不做無謂的浪費，只有當觀眾需要某一條數據流，發起拉流轉碼時，再轉碼。

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

最常用的通過RTMP推流方式推到云端。

通過RTMP拉流的方式，擁有自己的上行源站。

通過HLS拉流方式，上行推到騰訊云，騰訊云處理加速之后通過協議分發。

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

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

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

騰訊云直播架構中的延時分為三部分：

主播端的采集、預處理、編碼、發送以及上行的網絡等推流端引入的延時；

云處理部分產生的延時，包括鏈路延時、轉碼引入的延時、不同的協議引入的延時不同，映射為上行-轉碼-下行；

下行的接收端與網絡強相關，映射為接收-解碼-后處理-展示，都會產生相應延時。

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

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

上行或者下行一般基于原有的CDN架構進行正常優化；

Quic相較于HTTP/2更好一點，Quic優化的效果很明顯；

使用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毫秒左右。

總結

以上是生活随笔為你收集整理的腾讯云低延时直播系统架构设计与弱网优化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。