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

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

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

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

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

紅點(diǎn)的第一個(gè)版本

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

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

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

Pc 平臺(tái)因?yàn)橛?flash 對(duì)富媒體的支持，我們產(chǎn)品要求的多媒體形式都有成熟解決方案，比如基于 tcp 的 rtmp 協(xié)議，這是 adobe 公司推出的流媒體協(xié)議，等等。 iOS 平臺(tái)上，蘋(píng)果大力推廣 HLS 作為他的標(biāo)準(zhǔn)格式，所以在 iOS 平臺(tái)上也沒(méi)有太多問(wèn)題。

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

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

這是我們第一版產(chǎn)品的架構(gòu)。客戶端使用 tcp 協(xié)議上傳 mp3 流，這里對(duì)照可選的還有 http 和 udp 兩種，不過(guò)這兩種的研發(fā)成本都較 tcp 高一些。我們這個(gè)版本的后臺(tái)服務(wù)是一個(gè)單機(jī)的服務(wù)，支持接收 mp3 流的上傳和 http mp3 流分發(fā)，同時(shí)能夠本地落盤(pán)生成 HLS 切片和文件列表。HLS 通過(guò) nginx 反向代理，對(duì)外提供分發(fā)服務(wù)。

歷史回聽(tīng)

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

多人語(yǔ)音

然后我們產(chǎn)品功能做了一次大的更新。我們需要實(shí)現(xiàn)多人語(yǔ)音功能，支持 iOS 和安卓?jī)蓚€(gè)平臺(tái)的錄音和播放。這里的多人語(yǔ)音是一個(gè)語(yǔ)音會(huì)議的能力，比如像 yy 語(yǔ)音，qtalk 這樣的，能夠多人實(shí)時(shí)會(huì)話的產(chǎn)品功能。

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

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

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

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

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

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

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

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

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

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

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

Live555 是 c++ 實(shí)現(xiàn)的，支持 rtp、rtcp 、rtsp、 sip 的開(kāi)源服務(wù)器。

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

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

音頻格式

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

第一版多媒體接入節(jié)點(diǎn)設(shè)計(jì)

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

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

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

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

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

視頻

多人語(yǔ)音之后我們?cè)黾恿艘曨l功能。視頻功能的要求也是一個(gè)會(huì)議的場(chǎng)景，需要延遲盡可能低。我們?yōu)閰f(xié)議增加了重傳能力，前向糾錯(cuò)能力和選擇重傳算法。增加了私有協(xié)議轉(zhuǎn) RTMP 流的服務(wù)，和一套音視頻同步的機(jī)制。轉(zhuǎn)成 RTMP 標(biāo)準(zhǔn)輸出以后，通過(guò) CDN 支持 web 的播放。下面我們?cè)敿?xì)的看一下每一個(gè)技術(shù)點(diǎn)和架構(gòu)選擇。

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

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

音視頻同步這部分我們采用以音頻為主時(shí)間線的方案。是因?yàn)槿硕鷮?duì)聲音更敏感，而對(duì)畫(huà)面容忍度較高。

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

以上就是我們?cè)诘a(chǎn)品過(guò)程中的技術(shù)架構(gòu)變遷。

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