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

文 | 紅點聯(lián)合創(chuàng)始人 王宇航

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

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

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

紅點的第一個版本

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

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

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

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

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

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

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

歷史回聽

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

多人語音

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

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

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

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

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

相關(guān)項目與方案

右邊是一些相關(guān)的項目和方案。

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

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

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

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

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

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

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

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

音頻格式

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

第一版多媒體接入節(jié)點設(shè)計

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

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

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

多媒體接入節(jié)點重構(gòu)

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

視頻

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

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

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

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

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

以上就是我們在迭代產(chǎn)品過程中的技術(shù)架構(gòu)變遷。

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