摘要：文紅點聯合創始人王宇航我今天分享的主題，是以實時連接場景為目標的一些技術架構探索。主要是關于紅點在產品研發過程中，我們的技術選擇，架構變化，還有這個過程中，我們的一些考慮。紅點的第一個版本紅點的第一個版本功能比較簡單。

文 | 紅點聯合創始人 王宇航

我今天分享的主題，是以實時連接場景為目標的一些技術架構探索。主要是關于紅點在產品研發過程中，我們的技術選擇，架構變化，還有這個過程中，我們的一些考慮。

有很多科幻的作品，描述人類突破自然界對時間、空間的客觀限制，去做一些事情。互聯網在很多方面已經對我們的這種能力有了一個很強的補充，比如我們每個人都可以用微信，可以實時的與不同地域的人們對話。但是我們覺得這個能力還可以進一步提高，尤其在多人的場景。

我們希望在互聯網上能夠進一步提高信息的傳輸效率，進一步降低信息的傳輸延遲，去讓一些線上的多人場景，有更好的體驗。這是我們技術迭代的初衷，所以在后面的內容里大家可以看到，我們很多的技術選擇跟這一點有很大關系。

紅點的第一個版本

紅點的第一個版本功能比較簡單。我們當時要做一款手機端可以錄音，網頁端可以播放的直播產品。手機端只支持 iOS 就可以了，但是要能夠全平臺播放。對這個版本迭代的要求是能夠快速上線，提供服務。

這個功能需求中，首要的問題是調研各個平臺的 web 頁面支持哪些音頻直播格式。大家在圖上可以看到調研結果，但是這個不是我們當時就使用的方案，這是我們花了一段時間通過線上實際運行的情況，總結的一個方案。

這里我們只列了兩個格式，HLS，這是蘋果主力推廣的手機網頁直播格式 Http Live Streaming，這個格式實際上是一個多媒體的播放列表，這個列表要求最少有三個文件，每個文件是一個獨立的多媒體文件，通過在播放端循環更新文件列表，依次將最新的多媒體文件插入本地播放列表，順序播放，來實現直播的效果，這個格式做直播的延遲在 8 秒以上會比較穩定，也就是每個文件的時長應該在 2 秒以上；另一個格式是 Http mp3 流，這個流是一個直播的流，不是我們平時經常見到的 mp3 點播的格式。

Pc 平臺因為有 flash 對富媒體的支持，我們產品要求的多媒體形式都有成熟解決方案，比如基于 tcp 的 rtmp 協議，這是 adobe 公司推出的流媒體協議，等等。 iOS 平臺上，蘋果大力推廣 HLS 作為他的標準格式，所以在 iOS 平臺上也沒有太多問題。

但是在安卓平臺上情況并不理想?？赡荛_發過需要運行在安卓平臺上的 native 應用或者 H5 頁面的朋友可能會了解，由于安卓廠商種類繁多，各自又存在脫離安卓標準修改 rom 的情況，安卓平臺對多媒體的兼容性有很大問題。我們對 HLS 調研的情況最夸張的時候，復雜度是瀏覽器種類 設備種類 安卓系統版本 *安卓 Rom 種類。我們自己做的小樣本調研結果是，大約一半的安卓瀏覽器，包括應用內的 webview，無法正確播放HLS格式的直播。但是對于 Http mp3 流這種音頻直播格式，效果就好很多，支持的比例在 90% 以上。

我們最初的全平臺使用的是 HLS 方案，然后逐步過渡到， PC 網頁和 iOS 使用 HLS 方案，安卓使用 http mp3 流的方案。

這是我們第一版產品的架構?？蛻舳耸褂?tcp 協議上傳 mp3 流，這里對照可選的還有 http 和 udp 兩種，不過這兩種的研發成本都較 tcp 高一些。我們這個版本的后臺服務是一個單機的服務，支持接收 mp3 流的上傳和 http mp3 流分發，同時能夠本地落盤生成 HLS 切片和文件列表。HLS 通過 nginx 反向代理，對外提供分發服務。

歷史回聽

接著我們對這個版本做了一次功能迭代，這次功能迭代我們主要增加了音頻直播的歷史回聽。所以我們增加了新的后臺服務，用于將直播結束后生成的歷史多媒體文件上傳到 UPYUN 上面。這個功能的主體部分我們是依靠 UPYUN 來完成的，這節省了我們大量的成本、時間和精力。大家都知道創業團隊很多時候就是在跟時間和成本賽跑，所以能夠直接使用成熟的第三方服務，是非常有幫助的。

多人語音

然后我們產品功能做了一次大的更新。我們需要實現多人語音功能，支持 iOS 和安卓兩個平臺的錄音和播放。這里的多人語音是一個語音會議的能力，比如像 yy 語音，qtalk 這樣的，能夠多人實時會話的產品功能。

這個功能引入了這幾個技術點，大家可以看到。首先是混音，混音就是將多路聲音混為一路聲音。這是我們播放能力帶來的衍生需求。在 flash 里面，播放多路聲音是沒問題的，就是同時下載多路流，然后播放就行了，但是在手機 H5 頁面里，沒有這個能力。手機 H5 頁面只允許同時播放一路聲音，這就要求我們必須在后臺實現多路轉一路這個功能，然后才能支持手機 H5 的播放。

然后是音頻格式。 Mp3 格式并不適用于低延遲場景， mp3的編碼延遲在 200ms 左右，這在音頻編碼中是特別高的。并且 mp3 這個格式本身是上下文相關的，也就是說一段聲音的編解碼依賴上一段或者下一段，這個特點也不適用于音頻會議這種功能需求。所以我們需要選擇一個新的音頻格式。

下一個是網絡協議，我第一版使用 tcp 的傳輸格式，但是基于 tcp 的協議有一個很嚴重的問題，就是無法改變擁塞控制策略。Tcp 在遇到有丟包的情況時，會有非常嚴重的懲罰，影響傳輸效率，這也是語音通話不能容忍的，需要使用基于 udp 的協議來傳輸音頻數據。

還有一個我沒有列在上面的，是 AEC，也就是回聲消除。什么是回聲消除呢，這個場景特別好理解。就是我們打電話的時候，如果我們打開免提，如果電話的回聲消除做的不好，就會出現非常刺耳的尖叫聲音，這個聲音叫嘯叫。這是由于設備本身的錄音中包含了這個設備自己播放的聲音，如果不能在錄音中把自己播放的這部分去掉，就會出現循環，也就沒法使用了。這個點我們在產品體驗上規避了一下，我們要求安卓用戶必須帶耳機才可以使用多人語音功能， iOS 因為蘋果提供系統支持，效果非常好，所以在 iOS 上沒有這個問題。

相關項目與方案

右邊是一些相關的項目和方案。

FFmpeg 是業界最流行的多媒體處理框架和多媒體處理工具集。它有一套成熟的多媒體處理架構，包括從采集到編解碼，格式轉換等一系列處理需求。它還整合了大部分音視頻格式的封裝與解析工具，音視頻編解碼器，公共的工具函數，還有視頻后期的效果處理等功能服務。支持命令行使用，也支持作為函數庫使用。

WebRTC 實現了基于網頁的視頻會議，標準是 WHATWG 協議，目的是通過瀏覽器提供簡單的 javascript 就可以達到實時通訊能力。它的音視頻處理部分源自于 google 收購的一家ip 解決方案服務商 Global IP Solutions，這個引擎是這個公司的核心技術之一。 它包括音視頻的采集、編解碼、網絡傳輸、顯示等功能，并且還支持跨平臺： windows，linux ，mac， android 都可以使用。

其中有兩個模塊對語音會話有顯著作用， NetEQ 和 aecm 。NetEQ 是自適應抖動控制算法以及語音包丟失隱藏算法。使其能夠快速且高解析度地適應動態的網絡環境，確保音質優美且緩沖延遲最小。 NetEQ 對聲音的優化一般是通過減慢部分音頻的播放速率，或者加快部分音頻的播放速率，以及使用音頻編解碼自身的特性恢復丟包，等幾個策略綜合調節實際的播放效果。

Aecm 是 aec for mobile 的意思，是專門為移動端優化的回聲消除算法。這個模塊本身的功能沒問題，但是在安卓上，由于設備種類的問題，每個設備仍然需要自行適配這個模塊的一些參數。其中一個最重要的參數是播放到采集的延遲，這個延遲是指從調用 API播放原始聲音數據，到這段聲音數據被手機采集，通過手機的錄制回調返回給程序，期間的間隔時長。這個時間參數對回聲消除的效果影響是最大的。

Rtp、rtcp 是 rfc 標準的音視頻傳輸協議。其中 rtp 是針對互聯網上多媒體數據流的一個傳輸協議， rtcp 是負責管理傳輸質量在當前應用進程之間交換控制信息的協議。一般實際使用需要兩種協議共同配合。 Rtp 可以是基于 udp 的也可以是基于 tcp 的。Webrtc 的網絡傳輸就是基于 rtp、rtcp 的。

Live555 是 c++ 實現的，支持 rtp、rtcp 、rtsp、 sip 的開源服務器。

我們自己重點對比了自研的方案和基于 webrtc 二次開發的方案。我們自己對自研工作的評估是這樣的，我們需要實現的協議最小功能集合包括兩個點，一是協議要支持應用層的會話管理，二是協議要支持傳輸數據的排序。支持這兩個點的功能，就可以初步實現多人語音了，不過效果還有很大提升空間。這個方案的實現成本可以接受，但是在未來面對協議擴展等問題時，存在一定的風險。

Webrtc 是成熟框架，有 google 支持，并且是跨平臺項目。但是 Webrtc 是客戶端項目，沒有配套的成熟服務器，只有用于 p2p 的配對開源項目。同時， webrtc 并非只實現了 rtp、 rtcp 協議的基本格式，它里面增加了一些擴展字段，用于支持前向糾錯和流控，也就是擁塞控制。這就需要我們自己對照他的協議，實現一個配套的服務，并且要給出分布式方案。所以雖然 webrtc 有完整的多媒體處理流程，但是整體的使用成本還是很高，所以我們最后選擇了自研的方案。

音頻格式

這兩幅圖是幾種音頻格式特性的對比，兩幅圖來自 opus 的官網，左圖縱軸表示壓縮的效果，橫軸表示支持的采樣率，右圖的縱軸是編解碼的延遲，編解碼延遲是指輸入一定時長的音頻數據到輸出壓縮后對應的音頻幀的時間間隔，橫軸是碼率。 Opus 壓縮后的實際效果是否真的在數值上這么出色，我們沒做詳細的測評，但是我們對比了 ilbc 和 opus 對音樂壓縮的效果， opus 在人聲以外的場景仍然非常出色，并且編解碼延遲也的確是如圖中表示的這樣，所以我們多人語音采用的音頻格式是 opus 編碼。

第一版多媒體接入節點設計

這里左圖是多人語音上傳分發功能的多媒體服務節點結構。每個節點由三個模塊組成。 Room 模塊實現房間對多媒體數據的廣播；同時會將本地用戶上傳的數據轉交給 Master 模塊；Master 會將本地的上傳數據同步給其他節點的 Slave 模塊；Slave 模塊是與 Master 配對的接收數據同步的模塊。這個節點結構是同構的，每個節點的程序本身都一樣，在部署的時候只有配置不同。

這要求整個服務內部節點之間必須是全連通的組織方式，每兩個節點之間都需要有一個數據同步的鏈路。這種架構的好處是研發、運維成本很低，可以很容易的實現一定程度的可靠性和可用性。對于宕機節點，可以直接將這個點從服務列表中摘除，受影響的用戶會自動由于本地網絡失敗，選擇其他節點的服務。這個架構的問題在于，無法跨機房部署。由于是全連通的組織形式，如果跨機房，會導致機房間存在大量可能影響服務質量的數據鏈路，難以做網絡優化。

這是多人語音功能的架構。其中 codec 服務是 ffmpeg 的網絡封裝，方便橫向擴展。 Http mp3 流和 HLS 切片的輸入是混音服務的輸出。對 web 全平臺通過 CDN 分發。

多媒體接入節點重構

這個版本上線以后，接著我們對多媒體服務節點做了一次重構。從全連通的組織形式改成樹形組織形式。每個服務節點由兩個模塊組成， Room 模塊實現對房間用戶的廣播， Client 模塊是 Room 配對的客戶端，用于實現節點間的數據節點。每個節點有一個唯一的 ID，通過 ID 判斷數據的同步是否會產生數據回路。當需要跨機房部署的時候，只需要多個機房能夠共同通過同一個根節點進行數據同步即可完成整個功能。節點間我們增加 etcd 提供服務協調能力，etcd 是 golang 版本的類 zookeeper 服務。

視頻

多人語音之后我們增加了視頻功能。視頻功能的要求也是一個會議的場景，需要延遲盡可能低。我們為協議增加了重傳能力，前向糾錯能力和選擇重傳算法。增加了私有協議轉 RTMP 流的服務，和一套音視頻同步的機制。轉成 RTMP 標準輸出以后，通過 CDN 支持 web 的播放。下面我們詳細的看一下每一個技術點和架構選擇。

H264格式的視頻有三種幀，I 幀 P 幀和 B 幀，其中 I幀可以獨立解碼顯示，但是 P 幀和 B 幀都直接或者間接依賴最近的 I 幀。所以如果 I 幀存在數據丟失，會造成大片持久的馬賽克，這個在視頻體驗上是不能容忍的，所以重傳在這里是必要的。 FEC，也就是前向糾錯，是對重傳的一種補充，通過增加數據傳輸過程中的冗余比例，實現丟包恢復。

我們采用的是多項式方程的方案，這個方案可以自由調節冗余的比例和尺度。 Webrtc 中采用的冗余算法是異或的方案，異或的方案只能容忍一個數據包的丟失，無法處理連續丟失。選擇重傳算法要求數據重傳要有時間限制和長度限制，這個算法本身是提高重傳效率，提高網絡利用率。

音視頻同步這部分我們采用以音頻為主時間線的方案。是因為人耳對聲音更敏感，而對畫面容忍度較高。

混流這部分我們實際采用的是客戶端混流的方案。這里涉及到音視頻復用，就是在服務器將音視頻做好時間同步，再通過一個數據鏈路發送到客戶端，或者在客戶端做音視頻復用，兩個方案。由于服務器的復用處理會引入額外延遲，我們最終選擇音頻與視頻，采用平行的系統提供上傳與分發服務。這也帶來了一個產品上額外的好處，就是當畫面卡頓時，可以很容易的選擇只播放聲音，停止播放視頻畫面。

以上就是我們在迭代產品過程中的技術架構變遷。

本文整理自 紅點直播聯合創始人 王宇航 于 11 月 28 日在 “UPYUN 架構與運維大會·北京站” 上的主題演講。
查看&下載本次大會全部講師的演講 SLIDES 及現場視頻，請訪問：http://opentalk.upyun.com/show/issue/29