直播問答技術分析

一、產品背景

一直以來，競技類答題遊戲對人們都極具吸引力，從《開心辭典》《幸運52》《一站到底》在電視上火爆多年就能看出來。而直播答題APP將在線答題、知識付費、直播互動等眾多火爆元素連結在一起，或成為2018年第一個風口。

對於內容平台來說，這種直播答題分錢的模式未來可能成為很多內容產品的一個插件，因為它可以幫助平台用低價換高流量。用少量的獎金拉新促活且有相對較高的留存率，同時，這種直播問答模式本身就是一個廣告媒體的截至。這樣看來，顯然直接分錢給用戶比砸錢做推廣要更高效，更靠譜。

二、場景功能點分析

如上圖所示，直播競答場景包含了直播、問題互動以及其他業務功能，從這些功能點出發，我們可以發現直播競答的痛點也非常清晰：

1. 問答與直播同步難

直播延遲往往在3~10s，問答信令的傳輸則幾乎實時。進行直播時，必須保障問答與直播同步，否則體驗較差。部分友商通過實時音視頻進行直播競答，除了費用高之外，實時音視頻與高並發的場景本身適配性較差，萬人的直播活動往往有服務癱瘓的風險。

2. 直播前處理複雜

直播競答場景下，主播端需要做一些前處理，如片頭片花、主播的美顏等，這些前處理對於普通開發者而言會消耗較多的時間，無法快速上線。

3. 高並發下黑屏卡頓

直播競答是一種短時間內吸納大量用戶的引流方式，有高並發、訪問集中的特徵。對於直播服務、消息服務都有較高的性能要求。

三、技術實現分析

主講人通過推流客戶端進行推流。將音頻流和視頻流推至直播服務，需要進行答題時，通過主播端的操作將問答控制信令傳輸給IM服務。觀眾和答題者的客戶端中集成播放SDK和IM SDK，同步進行拉流和答題。由業務伺服器進行答題數據的匯總並回傳給終端用戶。回傳的控制信令也由主持人發起，通過直播鏈路和IM鏈路同步傳輸。

1、視頻模塊

1）流暢性和清晰度定義

觀眾在觀看直播或者與主播進行互動直播的過程中，對音視頻流暢性和清晰度的感受可以通過視頻幀率、視頻PSNR（或SSIM）分值、音頻MOS分值等客觀參數指標來表徵。越高的視頻幀率帶來的視頻流暢性越高，越高的視頻PSNR（或SSIM）分值帶來的視頻清晰度越高，越高的音頻MOS分值帶來的音頻流暢性和清晰度越高。

那麼，如何通過提高網路QoS技術改善網路質量，從而提高上述的客觀指標呢？下面我們就單向直播和互動直播分別進行介紹。

2）單向直播的流暢性和清晰度

這裡的單向直播特指通過RTMP/TCP協議將音視頻流推送到CDN，然後觀眾拉流觀看的一種直播方式。

眾所周知，TCP是一個面向連接的傳輸層協議，協議本身保證了傳輸的可靠性。通過調用開源框架librtmp，開發者可以非常容易的實現RTMP推流服務。然而，在網路出現丟包和抖動的時候，TCP的擁塞控制策略會限制推流端的發送碼率，使得觀眾端出現突發的拉流卡頓，影響音視頻的流暢性。

通常情況下，應對網路丟包的策略有前向錯誤隱藏（FEC）、音頻RED冗餘、重傳等，應對網路帶寬受限有音視頻的自適應碼率調節策略。考慮到TCP協議的特殊性，我們無法設計靈活的重傳和自適應碼率調節策略，數據發送的多少和頻率完全由TCP協議本身控制。這種情況下，我們可以做的是及時有效的檢測網路可用帶寬，並調節音視頻編碼器的輸出碼率，做到碼率自適應。

具體的實現方法是，通過平台（ios、Android或者Windows）相關的TCP socket介面獲取網路信息，感知網路擁塞，估算得到可用帶寬，及時調節音視頻編碼器的設置碼率，防止音視頻卡頓發生，保證流暢性。

3）互動直播的流暢性和清晰度

這裡的互動直播特指連麥者通過RTP/UDP協議將音視頻流推送到中轉伺服器，進行混流後再通過RTMP/TCP協議推送到CDN，然後觀眾拉流觀看的直播方式。

UDP不同於TCP，協議本身不關心數據是否及時可靠到達對端，只是完成「發送」的操作。由此，我們可以採用種類繁多的技術手段保證UDP協議數據的可靠達到。例如：前向錯誤隱藏（FEC）、音頻RED冗餘、重傳等策略。根據網路狀況和媒體數據的不同，我們採取相應的策略。

• 帶寬估計

帶寬估計的作用是準確的獲得當前的可用網路帶寬，進而指導音視頻編碼器的帶寬分配，使得實際發送碼率不超過可用帶寬，從而不會引起延時增加和丟包。常用的帶寬估計方法包括根據丟包或者延遲變化估計帶寬，Google的WebRTC中就包含了完整的帶寬估計方法，值得大家學習借鑒。

• 錯誤隱藏

當接收端收到的音視頻數據已經發生了丟失，我們該如何恢複數據呢？從音視頻解碼的角度看，可以通過視頻（音頻）前一幀或者多幀數據恢復丟失的數據。然而，常用的視頻錯誤隱藏方法往往會對恢復的圖像造成馬賽克現象，錯誤隱藏的效果不佳。所以大多數情況不採用這類錯誤隱藏技術，而是解碼之前會判斷一幀數據是否完整，完整的數據才會被送入解碼器，不完整的數據直接丟棄。音頻領域的錯誤隱藏是另一種情況，音頻的錯誤隱藏技術要普遍優於視頻的錯誤隱藏，流行的音頻壓縮標準Opus、iLBC、iSAC/SILK等，都含有自己的PLC（Packet Loss Concealment）模塊，解碼器在檢測到丟幀的時候會自動進行錯誤隱藏，實際效果還可以接受。

• 前向糾錯

前向糾錯技術相當於在發送端多發一部分數據，這部分數據可能是原始數據的複本，也可能是多份原始數據相互計算的結果。如果原始數據在傳輸過程中發生了丟失，那麼這部分冗餘數據就可以發揮作用，幫助恢復丟失的原始數據。當然了，這種策略犧牲的是有限的網路帶寬。

視頻數據區別於音頻數據的一個特點是，視頻的數據包較大，一般情況會接近MTU大小，同時觀眾對視頻數據的端到端延遲不如音頻數據敏感。因此可以採用數目較大的FEC分組進行前向糾錯。而音頻數據包較小，數據包頭在整個數據包中的佔比相對視頻要高出很多，所以進行RED冗餘能夠使多個音頻包復用同一個包頭，提高數據利用率。另一方面，如果音頻數據採用FEC進行前向糾錯，勢必會增加延遲，影響通話體驗。

因此，視頻數據較適宜採用FEC技術進行前向糾錯，音頻數據較適宜採用RED技術進行冗餘操作。

• 重傳

除了前向糾錯技術，在網路RTT較小的時候，我們也可以向發送端請求網路中丟失的數據包，這就是重傳技術。這個技術適用於網路RTT較小的情況，相比於FEC和RED，重傳可以大幅提高帶寬利用率，做到「丟哪個包要哪個包」，有針對性的重傳丟失的數據包。

考慮到觀眾對音頻數據的敏感性，除非網路RTT很小，否則音頻一般不採用重傳技術。視頻較多採用重傳技術進行錯誤恢復，根據重傳請求數據的不同又分為I幀請求和數據包請求。

I幀請求是當接收端無法繼續解碼，而且發送端的GOP長度又很長的時候，需要及時請求發送端發送I幀，使得接收端根據這個I幀可以儘快恢復顯示。數據包請求則是根據丟失的數據包，向發送端有針對性的請求，這種情況下發送端需要緩存已經發出去的數據包，以備後續接收端的請求。

2、聊天室模塊

1）聊天室架構應滿足哪些條件

高可用：任何一個節點故障都不應該引起服務不可用；

易擴展：具有水平擴展的特性，對不同量級的在線用戶數都有應變的能力；

高並發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達所有在線端的延時在毫秒級；

客戶端兼容性：新型的應用都是能同時跨多種設備實現消息互通的，比如網頁端，手機端和桌面端，甚至智能電視等。

2）設計架構

客戶端層

處理各種設備的兼容問題，包括對ios，Android，Windows， Web等各種開發平台的語言適配；消息通道的管理維護，包括移動設備上的弱網路管理，斷線重連等；保證數據安全，所有上行下行的數據包都需要加解密處理，規避數據泄露或中間人攻擊等各種安全風險。

網關接入層

管理大量客戶端連接，單個節點可以維護的客戶端數量在數十萬量級；處理不同類型客戶端的協議兼容，由於客戶端實現技術的多樣性，導致客戶端與網關之間底層的數據通信協議存在差異，需要由不同的接入網關做協議轉換；處理數據安全邏輯；跨網路的高可用邏輯，網路級別的主備(誰知道哪天網線會被藍翔的畢業生挖斷呢?)；廣播消息的高效下行分發，將收到的廣播消息分發到所有連接在本節點上的客戶端。

路由層

作為業務層接入的中轉，同時承擔負載均衡和高可用的作用，單個業務節點處理能力達到瓶頸時更方便的擴容，路由層使業務層擴容對前置網關層完全透明；當一個網路的業務集群出現網路故障時，可以切換到備用網路，保證服務可用性。

業務層

處理聊天室內的業務消息，一個集群內有眾多節點，節點角色相互對等，任何一個節點的故障會使整個集群的處理能力下降，但不會引起服務的中斷，因為其他節點可以繼續接管業務數據包的處理；業務集群同樣有多個網路環境的熱備，以應對可能出現的區域性網路故障。

3）難點在哪裡

客戶端多樣性

目前的應用都存在跨平台的需求，iOS、安卓和PC端，網頁端，甚至IOT物聯網設備，能連多少是多少，多多益善；但是不同開發平台之間的技術差異性極大，不是所有公司都有這麼全的全棧程序猿的；如果團隊開發的話單就客戶端開發人員就不是幾個人可以完成的。

數據安全的保證

當前的網路安全形勢異常複雜，開發應用時如果不在通信安全上花心思，那你的用戶就是在互聯網上裸奔；開發者需要針對不同的平台，不同的通信技術實現可靠的安全方案，避免用戶數據在傳輸過程中泄露，避免中間人攻擊等安全風險。

跨機房網路級的高可用方案

當機房網路出現故障時把責任推給市政施工隊或者「網路抽風」已經不流行了，用戶需要的是故障無感知。

所有環節的單點故障排除

任何硬體和軟體都存在故障的可能，我們無法避免應用罷工，那就需要隨時準備替補上場。

能應對任何用戶量級的需求

架構級做到水平擴展的能力，當用戶量增長時隨時可以通過堆伺服器來解決，而不是將架構推倒重來。

4）這麼難？怎麼做

技術發展到現在已經不流行重複造輪子了，因為輪子的結構越來越複雜，功能性和非功能性的指標要求越來越高；而我們的用戶卻不會再等我們了。當我們還在畫輪子的圖紙的時候，競爭對手可能已經把車子都造好，在路上跑了。雖然我們不是非得自己造輪子，但是了解如何完成一個完美的輪子的製作過程和質量標準卻是非常有必要的。

利益相關

我們團隊是做IM、直播技術的，底層架構都是做好的，開放給開發者sdk和api介面，開發者接入後就可以實現直播的功能。感興趣可以加我的qq3103607948 細聊。

推薦閱讀：