關于CCtalk

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

今天我會從五個方面來給大家介紹：

1，主流直播方案介紹

2，客戶端AV引擎

3，服務端架構演進

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

5，高并發場景案例分析

1、主流直播方案

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

下面介紹一下各自的特點：

1）RTMP

RTMP的優點是CDN加速成熟，成本低，可用的開源庫，以及開源工具比較多，延遲一般在2到5秒。

2）HTTP-FLV

HTTP-FLV的原理是服務器在響應HTTP請求時候，不返回Content-length字段，它使用HTTP協議來實現，不容易被防火墻攔截，延遲略低于RTMP，但都是秒級的。

3）HLS

HLS的優點是CDN分發容易，成本低，可以在HTML5頁面中直接打開觀看，但它延遲一般大于12秒。

4）RTP

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

2、客戶端AV引擎

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

從圖中可以看到，所有的客戶端與信令系統之間有一個TCP長連接，來實現PPT、白板筆、答題卡、文字聊天等等教學相關的小工具；所有的用戶與媒體服務之間有一路TCP或UDP的連接，實現老師與學生之間的雙向實時音視頻互動，比如說老師上課的時候，將產生的實時音視頻數據發送到媒體系統，媒體系統按照一定的路徑將媒體數據發送到學生端；如果學生端也上麥了，那么學生端產生的音視頻數據也會經過媒體系統轉發到老師端，這樣就完成了一個教學場景下的雙向音視頻互動。同時，媒體服務會旁路推流一路RTMP到CDN，學生端可以在HTML5網頁里直接觀看實時單向直播，這樣就滿足了在大型直播中網頁傳播的訴求。另外媒體服務器會將上課時產生的音視頻數據發送一路到錄制服務，同時信令系統會將上課時產生的PPT、白板筆以及文字聊天等內容發送一份到錄制服務，錄制服務收到所有上課內容后，將它們以元素的形式存儲下來，存儲下來的這個格式叫做OCS回顧，便于課后回顧。

因此教育直播架構須具有的以下特性才能滿足需求：

而CCtalk就是這么一個支持多種教學工具的實時大規模并發教學平臺。在最開始實現這個平臺的時候，我們采用了一些開源方案，如webrtc，但后來發現直接使用開源方案無法為完全滿足教育直播的需求，因此我們自研發了一套客戶端AV引擎：

下面我會針對引擎的網絡部分做一個簡單的介紹，主要介紹用到的幾個關鍵的技術。首先思考一個問題：當客戶端在使用媒體引擎的服務時，需要做的第一件事是什么呢？

答：需要找一個網絡質量較高的邊緣節點接入。

如上圖所示，假如我們有一百個邊緣節點，用戶需要從這一百個里面選一個到他的網絡質量較高，那么該如何選擇呢？可能你首先想到的是DNS解析，但其實只靠DNS解析是不夠的，我們還需要一套自動尋路機制，如下圖所示：

以小網絡為例，它的每次DNS解析的結果可能是變化的，我們無法保證它尋到的結果一定是最優的。當用戶接入到邊緣節點之后，在使用過程中，用戶的網絡在不斷變化的，因此我們還需要有一個動態檢測的機制，如果引擎檢測到網絡波動較大的情況，那么需要再次啟動自動尋路機制，再給它找一個網絡質量較高的邊緣節點接入。此外，由于網絡一直在變化，為了適應這種不斷變化的網絡，我們還需要一套擁塞控制機制，在這里我推薦Google的GCC擁塞控制算法：

這個擁塞控制可以分為發送端基于丟包的網絡估計，以及接收端基于延遲的網絡估計兩部分，總結下來，就是根據丟包率以及延遲控制發送端的碼率。除此之外，當我們的碼率開始降低的時候，是不能一直降低下去的，因為碼率降低意味著音視頻質量的下降。我們還需要另外一套補充機制，叫做消峰處理：

消峰處理的原理是將比較大的數據分成若干個包，在一定時間內發送出去。但這會帶來延時的增大，因此需要控制發包的間隔大小。最后，當數據在傳輸當中由于誤碼等因素導致丟包時，我們還需要丟包重傳的機制來進一步的提升網絡的質量。總結下來，其實整個客戶端引擎的網絡部分，其實就是在做一件事：在實時性與質量之間權衡，而且這個權衡具有一定的自適應能力。

3、服務端架構演進

這張圖的上半部分在前面已經介紹過了，就是客戶端的引擎部分，下半部分是對應的媒體服務器的一些功能。最初的CCtalk服務系統是由第三方提供的，開發簡單，成本低，但確實存在一些問題。后來我們自主研發了一套服務端體系，架構如下：

這個架構分為兩大部分：信令系統和媒體系統，整個架構中的所有服務設計功能單一、結構簡單，并且所有節點支持線性擴展，理論上它能承載的人數是沒有上限的，你只要加機器就可以了，所有的節點支持失效自動轉移，這套系統我們用了很長一段時間，但在使用的過程中還是發現了一些問題，以媒體系統為例，首先一個是問題是存在中心節點，這就意味著所有的數據都要先經過代理節點轉發到中心節點，再發送到代理節點，最后發送到學生端，并且這個路徑是固定的，所有的數據都要走這么長的路徑，此外，系統之間有一定的耦合。為了解決這些問題，重新設計了新的媒體架構：

首先，我們把信令系統與媒體系統之間解耦，也就是說他們之間相關的操作如加入房間，建立房間，全部放在客戶端的AV引擎去實現；另外，我們去掉了中心節點，加入了轉發節點的概念，所有的轉發節點都是對等的，并且轉發節點會將收到的音視頻數據通過一個智能尋路算法自動找一條最優的路徑。

整個媒體系統設計原則有兩點：一是盡最大的可能找一條最優的路徑，將數據盡快的發送到對端；二是在服務出現問題的時候，盡量的保證服務的可用性，并且讓用戶沒有感知。

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

下面講一下錄制回顧以及旁路推流，架構如下：

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

錄制OCS回顧視頻過程如下：

我們還有一套專門的OCS編輯器來幫助對OCS回顧進行二次編輯，編輯器可以將編輯之后的結果再次傳到云端，這樣學生就可以觀看編輯之后的內容。

在這個過程中，我們使用的轉碼服務，前期用戶量不大的情況下，我們使用CPU轉碼，單臺16核的機器的并發數量可以達到40路，后面隨著業務增長，對于轉碼集群的要求不斷增大，所以我們改用了GPU轉碼，并發情況如下：

5、高并發場景案例分析

高并發場景的案例分析，這一部分與實際的音視頻沒有太大的關系，但卻存在教育場景當中不得不面對的一些問題，我首先舉個例子，希望能夠對大家有一定的啟發。我們來想一個問題：同一個教室里，有20萬人同時在聽課，我們會遇到哪些問題，我們該如何解決這些問題？假設有20萬人在同一個房間，每個人攜帶的數據量是30字節（例如：用戶列表、用戶ID、昵稱等等），假設每臺網關承載三千人，那么至少需要66臺網關，正常情況下，假設每秒有800人進出房間，那么負載到每個網關上就是12人每秒的瞬間吞吐，所以算下來當有一個用戶進房間，那么他拉取的這個數據量就是45Mb，他進房間的這一瞬間需要拉這么多的數據，每臺網關承載的實時的吞吐量是554Mb，當出現異常時，比如說某臺網關宕機或者脫離了核心服務，我們的負載均衡服務會將出現的問題的至少三千人負載到剩余的64臺服務上，此時的網關負載增量是46.8人，異常時的網關瞬間流量是2Gb。總結下來存在的問題如下：

1）客戶端帶寬消耗太大

2）進入教室慢

3）服務并發處理量太大

那么，我們的應對策略是：

1）精簡信息+詳細信息

2）提供數據的版本機制，在一定范圍內，只處理變化的數據。