關(guān)于CCtalk

CCtalk是滬江旗下的支持互動(dòng)教育平臺(tái)，它提供網(wǎng)師服務(wù)，支持老師簽約入駐，擁有基于云，大數(shù)據(jù)和AI的個(gè)性化課程推薦，同時(shí)也支持社群化學(xué)習(xí)，可以通過(guò)課前預(yù)習(xí)，課后答疑和視頻回放等來(lái)沉淀學(xué)習(xí)用戶(hù)，而且還有非常豐富的教學(xué)工具，包括實(shí)時(shí)多向音視頻服務(wù)，雙向白板，屏幕分享，講義，教學(xué)小工具等等。

今天我會(huì)從五個(gè)方面來(lái)給大家介紹：

1，主流直播方案介紹

2，客戶(hù)端AV引擎

3，服務(wù)端架構(gòu)演進(jìn)

4，錄制回顧以及旁路推流

5，高并發(fā)場(chǎng)景案例分析

1、主流直播方案

主流的直播方案，我把它分為四類(lèi)：RTMP，HTTP-FLV，HLS和RTP

下面介紹一下各自的特點(diǎn)：

1）RTMP

RTMP的優(yōu)點(diǎn)是CDN加速成熟，成本低，可用的開(kāi)源庫(kù)，以及開(kāi)源工具比較多，延遲一般在2到5秒。

2）HTTP-FLV

HTTP-FLV的原理是服務(wù)器在響應(yīng)HTTP請(qǐng)求時(shí)候，不返回Content-length字段，它使用HTTP協(xié)議來(lái)實(shí)現(xiàn)，不容易被防火墻攔截，延遲略低于RTMP，但都是秒級(jí)的。

3）HLS

HLS的優(yōu)點(diǎn)是CDN分發(fā)容易，成本低，可以在HTML5頁(yè)面中直接打開(kāi)觀看，但它延遲一般大于12秒。

4）RTP

RTP一般是各家自研，相比于傳統(tǒng)的直播方案來(lái)講，自研方案不支持CDN加速，且成本貴，延遲一般是200到800毫秒之間。

2、客戶(hù)端AV引擎

教育直播-CCtalk是基于RTP協(xié)議自主研發(fā)的，它的傳輸層支持UDP和TCP兩種方式，支持網(wǎng)師之間以及任意觀眾之間的連麥互動(dòng)，連麥延遲和觀眾延遲都是毫秒級(jí)的，同時(shí)它支持PPT，白板筆，答題卡，文字等多種不同形式的教學(xué)互動(dòng)。下面介紹CCtalk的軟件架構(gòu)圖：

從圖中可以看到，所有的客戶(hù)端與信令系統(tǒng)之間有一個(gè)TCP長(zhǎng)連接，來(lái)實(shí)現(xiàn)PPT、白板筆、答題卡、文字聊天等等教學(xué)相關(guān)的小工具；所有的用戶(hù)與媒體服務(wù)之間有一路TCP或UDP的連接，實(shí)現(xiàn)老師與學(xué)生之間的雙向?qū)崟r(shí)音視頻互動(dòng)，比如說(shuō)老師上課的時(shí)候，將產(chǎn)生的實(shí)時(shí)音視頻數(shù)據(jù)發(fā)送到媒體系統(tǒng)，媒體系統(tǒng)按照一定的路徑將媒體數(shù)據(jù)發(fā)送到學(xué)生端；如果學(xué)生端也上麥了，那么學(xué)生端產(chǎn)生的音視頻數(shù)據(jù)也會(huì)經(jīng)過(guò)媒體系統(tǒng)轉(zhuǎn)發(fā)到老師端，這樣就完成了一個(gè)教學(xué)場(chǎng)景下的雙向音視頻互動(dòng)。同時(shí)，媒體服務(wù)會(huì)旁路推流一路RTMP到CDN，學(xué)生端可以在HTML5網(wǎng)頁(yè)里直接觀看實(shí)時(shí)單向直播，這樣就滿(mǎn)足了在大型直播中網(wǎng)頁(yè)傳播的訴求。另外媒體服務(wù)器會(huì)將上課時(shí)產(chǎn)生的音視頻數(shù)據(jù)發(fā)送一路到錄制服務(wù)，同時(shí)信令系統(tǒng)會(huì)將上課時(shí)產(chǎn)生的PPT、白板筆以及文字聊天等內(nèi)容發(fā)送一份到錄制服務(wù)，錄制服務(wù)收到所有上課內(nèi)容后，將它們以元素的形式存儲(chǔ)下來(lái)，存儲(chǔ)下來(lái)的這個(gè)格式叫做OCS回顧，便于課后回顧。

因此教育直播架構(gòu)須具有的以下特性才能滿(mǎn)足需求：

而CCtalk就是這么一個(gè)支持多種教學(xué)工具的實(shí)時(shí)大規(guī)模并發(fā)教學(xué)平臺(tái)。在最開(kāi)始實(shí)現(xiàn)這個(gè)平臺(tái)的時(shí)候，我們采用了一些開(kāi)源方案，如webrtc，但后來(lái)發(fā)現(xiàn)直接使用開(kāi)源方案無(wú)法為完全滿(mǎn)足教育直播的需求，因此我們自研發(fā)了一套客戶(hù)端AV引擎：

下面我會(huì)針對(duì)引擎的網(wǎng)絡(luò)部分做一個(gè)簡(jiǎn)單的介紹，主要介紹用到的幾個(gè)關(guān)鍵的技術(shù)。首先思考一個(gè)問(wèn)題：當(dāng)客戶(hù)端在使用媒體引擎的服務(wù)時(shí)，需要做的第一件事是什么呢？

答：需要找一個(gè)網(wǎng)絡(luò)質(zhì)量較高的邊緣節(jié)點(diǎn)接入。

如上圖所示，假如我們有一百個(gè)邊緣節(jié)點(diǎn)，用戶(hù)需要從這一百個(gè)里面選一個(gè)到他的網(wǎng)絡(luò)質(zhì)量較高，那么該如何選擇呢？可能你首先想到的是DNS解析，但其實(shí)只靠DNS解析是不夠的，我們還需要一套自動(dòng)尋路機(jī)制，如下圖所示：

以小網(wǎng)絡(luò)為例，它的每次DNS解析的結(jié)果可能是變化的，我們無(wú)法保證它尋到的結(jié)果一定是最優(yōu)的。當(dāng)用戶(hù)接入到邊緣節(jié)點(diǎn)之后，在使用過(guò)程中，用戶(hù)的網(wǎng)絡(luò)在不斷變化的，因此我們還需要有一個(gè)動(dòng)態(tài)檢測(cè)的機(jī)制，如果引擎檢測(cè)到網(wǎng)絡(luò)波動(dòng)較大的情況，那么需要再次啟動(dòng)自動(dòng)尋路機(jī)制，再給它找一個(gè)網(wǎng)絡(luò)質(zhì)量較高的邊緣節(jié)點(diǎn)接入。此外，由于網(wǎng)絡(luò)一直在變化，為了適應(yīng)這種不斷變化的網(wǎng)絡(luò)，我們還需要一套擁塞控制機(jī)制，在這里我推薦Google的GCC擁塞控制算法：

這個(gè)擁塞控制可以分為發(fā)送端基于丟包的網(wǎng)絡(luò)估計(jì)，以及接收端基于延遲的網(wǎng)絡(luò)估計(jì)兩部分，總結(jié)下來(lái)，就是根據(jù)丟包率以及延遲控制發(fā)送端的碼率。除此之外，當(dāng)我們的碼率開(kāi)始降低的時(shí)候，是不能一直降低下去的，因?yàn)榇a率降低意味著音視頻質(zhì)量的下降。我們還需要另外一套補(bǔ)充機(jī)制，叫做消峰處理：

消峰處理的原理是將比較大的數(shù)據(jù)分成若干個(gè)包，在一定時(shí)間內(nèi)發(fā)送出去。但這會(huì)帶來(lái)延時(shí)的增大，因此需要控制發(fā)包的間隔大小。最后，當(dāng)數(shù)據(jù)在傳輸當(dāng)中由于誤碼等因素導(dǎo)致丟包時(shí)，我們還需要丟包重傳的機(jī)制來(lái)進(jìn)一步的提升網(wǎng)絡(luò)的質(zhì)量。總結(jié)下來(lái)，其實(shí)整個(gè)客戶(hù)端引擎的網(wǎng)絡(luò)部分，其實(shí)就是在做一件事：在實(shí)時(shí)性與質(zhì)量之間權(quán)衡，而且這個(gè)權(quán)衡具有一定的自適應(yīng)能力。

3、服務(wù)端架構(gòu)演進(jìn)

這張圖的上半部分在前面已經(jīng)介紹過(guò)了，就是客戶(hù)端的引擎部分，下半部分是對(duì)應(yīng)的媒體服務(wù)器的一些功能。最初的CCtalk服務(wù)系統(tǒng)是由第三方提供的，開(kāi)發(fā)簡(jiǎn)單，成本低，但確實(shí)存在一些問(wèn)題。后來(lái)我們自主研發(fā)了一套服務(wù)端體系，架構(gòu)如下：

這個(gè)架構(gòu)分為兩大部分：信令系統(tǒng)和媒體系統(tǒng)，整個(gè)架構(gòu)中的所有服務(wù)設(shè)計(jì)功能單一、結(jié)構(gòu)簡(jiǎn)單，并且所有節(jié)點(diǎn)支持線性擴(kuò)展，理論上它能承載的人數(shù)是沒(méi)有上限的，你只要加機(jī)器就可以了，所有的節(jié)點(diǎn)支持失效自動(dòng)轉(zhuǎn)移，這套系統(tǒng)我們用了很長(zhǎng)一段時(shí)間，但在使用的過(guò)程中還是發(fā)現(xiàn)了一些問(wèn)題，以媒體系統(tǒng)為例，首先一個(gè)是問(wèn)題是存在中心節(jié)點(diǎn)，這就意味著所有的數(shù)據(jù)都要先經(jīng)過(guò)代理節(jié)點(diǎn)轉(zhuǎn)發(fā)到中心節(jié)點(diǎn)，再發(fā)送到代理節(jié)點(diǎn)，最后發(fā)送到學(xué)生端，并且這個(gè)路徑是固定的，所有的數(shù)據(jù)都要走這么長(zhǎng)的路徑，此外，系統(tǒng)之間有一定的耦合。為了解決這些問(wèn)題，重新設(shè)計(jì)了新的媒體架構(gòu)：

首先，我們把信令系統(tǒng)與媒體系統(tǒng)之間解耦，也就是說(shuō)他們之間相關(guān)的操作如加入房間，建立房間，全部放在客戶(hù)端的AV引擎去實(shí)現(xiàn)；另外，我們?nèi)サ袅酥行墓?jié)點(diǎn)，加入了轉(zhuǎn)發(fā)節(jié)點(diǎn)的概念，所有的轉(zhuǎn)發(fā)節(jié)點(diǎn)都是對(duì)等的，并且轉(zhuǎn)發(fā)節(jié)點(diǎn)會(huì)將收到的音視頻數(shù)據(jù)通過(guò)一個(gè)智能尋路算法自動(dòng)找一條最優(yōu)的路徑。

整個(gè)媒體系統(tǒng)設(shè)計(jì)原則有兩點(diǎn)：一是盡最大的可能找一條最優(yōu)的路徑，將數(shù)據(jù)盡快的發(fā)送到對(duì)端；二是在服務(wù)出現(xiàn)問(wèn)題的時(shí)候，盡量的保證服務(wù)的可用性，并且讓用戶(hù)沒(méi)有感知。

4、錄制回顧以及旁路推流

下面講一下錄制回顧以及旁路推流，架構(gòu)如下：

具體如下，當(dāng) Server收到指令以及數(shù)據(jù)時(shí)，會(huì)將音視頻數(shù)據(jù)發(fā)送到服務(wù)端的音視頻引擎，服務(wù)端的音視頻引擎會(huì)對(duì)這些數(shù)據(jù)做一些處理，壓縮成一個(gè)大視頻，將大視頻存成MP4，并保存到云端，同時(shí)，將這個(gè)實(shí)時(shí)的視頻流以RTMP的形式推到CDN，這樣，HTML5頁(yè)面就可以在線觀看實(shí)時(shí)的網(wǎng)頁(yè)直播；同時(shí)媒體錄制服務(wù)器會(huì)將上課時(shí)產(chǎn)生的所有內(nèi)容以元素集合的形式存儲(chǔ)一份，我們把這個(gè)存儲(chǔ)格式叫做OCS。下面就是直播或錄播的流程圖：

錄制OCS回顧視頻過(guò)程如下：

我們還有一套專(zhuān)門(mén)的OCS編輯器來(lái)幫助對(duì)OCS回顧進(jìn)行二次編輯，編輯器可以將編輯之后的結(jié)果再次傳到云端，這樣學(xué)生就可以觀看編輯之后的內(nèi)容。

在這個(gè)過(guò)程中，我們使用的轉(zhuǎn)碼服務(wù)，前期用戶(hù)量不大的情況下，我們使用CPU轉(zhuǎn)碼，單臺(tái)16核的機(jī)器的并發(fā)數(shù)量可以達(dá)到40路，后面隨著業(yè)務(wù)增長(zhǎng)，對(duì)于轉(zhuǎn)碼集群的要求不斷增大，所以我們改用了GPU轉(zhuǎn)碼，并發(fā)情況如下：

5、高并發(fā)場(chǎng)景案例分析

高并發(fā)場(chǎng)景的案例分析，這一部分與實(shí)際的音視頻沒(méi)有太大的關(guān)系，但卻存在教育場(chǎng)景當(dāng)中不得不面對(duì)的一些問(wèn)題，我首先舉個(gè)例子，希望能夠?qū)Υ蠹矣幸欢ǖ膯l(fā)。我們來(lái)想一個(gè)問(wèn)題：同一個(gè)教室里，有20萬(wàn)人同時(shí)在聽(tīng)課，我們會(huì)遇到哪些問(wèn)題，我們?cè)撊绾谓鉀Q這些問(wèn)題？假設(shè)有20萬(wàn)人在同一個(gè)房間，每個(gè)人攜帶的數(shù)據(jù)量是30字節(jié)（例如：用戶(hù)列表、用戶(hù)ID、昵稱(chēng)等等），假設(shè)每臺(tái)網(wǎng)關(guān)承載三千人，那么至少需要66臺(tái)網(wǎng)關(guān)，正常情況下，假設(shè)每秒有800人進(jìn)出房間，那么負(fù)載到每個(gè)網(wǎng)關(guān)上就是12人每秒的瞬間吞吐，所以算下來(lái)當(dāng)有一個(gè)用戶(hù)進(jìn)房間，那么他拉取的這個(gè)數(shù)據(jù)量就是45Mb，他進(jìn)房間的這一瞬間需要拉這么多的數(shù)據(jù)，每臺(tái)網(wǎng)關(guān)承載的實(shí)時(shí)的吞吐量是554Mb，當(dāng)出現(xiàn)異常時(shí)，比如說(shuō)某臺(tái)網(wǎng)關(guān)宕機(jī)或者脫離了核心服務(wù)，我們的負(fù)載均衡服務(wù)會(huì)將出現(xiàn)的問(wèn)題的至少三千人負(fù)載到剩余的64臺(tái)服務(wù)上，此時(shí)的網(wǎng)關(guān)負(fù)載增量是46.8人，異常時(shí)的網(wǎng)關(guān)瞬間流量是2Gb。總結(jié)下來(lái)存在的問(wèn)題如下：

1）客戶(hù)端帶寬消耗太大

2）進(jìn)入教室慢

3）服務(wù)并發(fā)處理量太大

那么，我們的應(yīng)對(duì)策略是：

1）精簡(jiǎn)信息+詳細(xì)信息

2）提供數(shù)據(jù)的版本機(jī)制，在一定范圍內(nèi)，只處理變化的數(shù)據(jù)。