單個群組WebRTC視頻通話中可以容納多少用戶

只要你想，在WebRTC視頻通話中添加從一到一百萬的用戶都是可以的。

當被要求創(chuàng)建一個群組視頻通話時，顯然，針對該項目應該選擇WebRTC技術。這幾乎是唯一的選擇，而且肯定也是性價比最好的。這時有個很大的問題：單個群組WebRTC視頻通話中可以容納多少用戶？

每周至少有一次我會被問到：WebRTC是點對點的，能否用于大型群組通話，因為這種技術可能不適合這種用例。事實上，WebRTC技術十分適合大型群組通話。

您需要做的是，將WebRTC看作一組技術構建模塊，根據(jù)具體需求進行整合和匹配，同時，WebRTC在瀏覽器中的實現(xiàn)也只是其中一個構建模塊。

目前，WebRTC技術中支持群組視頻通話的最常用構件是SFU（選擇性轉(zhuǎn)發(fā)單元），這是一個媒體路由器，它接收所有來自會話的參與者的媒體流，并決定傳輸路徑。

在本文中，我想要討論的是，在創(chuàng)建支持使用WebRTC的大型視頻會話的應用程序時，需要考慮的幾個方面和決策。

分析復雜性

首先，來分析一下我們用例的復雜性。

對于WebRTC，以及實時視頻通信，我們將歸結為速度和流數(shù):

1、速度——在服務器中我們所期待的分辨率和比特率。

2、流數(shù)——單個會話的媒體流數(shù)量。

讓我們從一個例子開始。

假設你為企業(yè)提供一個群組通話服務。它可以在全球范圍內(nèi)運行。人們將一起參加工作會議。你計劃將小組會議限制在4人以內(nèi)。我知道你想要更多參與者，但在這個例子中我只是想讓事情變得簡單明了。

上面的插圖顯示了4人參與會議的示意圖，4個人多對多的推流和拉流就形成了魔方矩陣方式的推拉流關系（布局）。

魔方矩陣方式：720p

如果你希望這個視頻會議是魔方矩陣式的布局，我們的討論如下:

你想要高質(zhì)量的視頻。這就是每個人都想要的。因此，針對WQHD顯示器（即2560×1440），你計劃讓所有參與者發(fā)送分辨率為720p的視頻。它消耗了1.5Mbps(這里我很吝嗇，它可能需要更多)，所以:

會話中的每個參與者發(fā)送1.5Mbps，接收3個1.5Mbps的流

在4個參與者中，媒體服務器需要接收6Mbps并發(fā)送18Mbps的數(shù)據(jù)。

總結在一張簡單的表格中，我們得到：

魔方矩陣方式：VGA

如果您對分辨率不太感興趣，可以針對VGA分辨率，甚至將比特率限制600Kbps：

以VGA標準傳輸視頻時，需要避免的事情是在顯示器上提高分辨率 - 因為看起來會很難看，特別是在較大的4K顯示器上。

即使在餐巾紙上粗略地計算，可以得出，一個分辨率為720P的視頻會議消耗的帶寬大概相當于3個VGA會議。

Hangouts方式

但是如果我們的布局有點不同呢？像圖示有主要演講者和以較小窗口出現(xiàn)的其他參與者：

我稱之為Hangouts方式，因為Hangouts以這種布局而聞名，并且屬于第一批專門使用這種方式而不提供更多額外的布局。

這一次，我們將使用聯(lián)播的方式（simulcast），并計劃讓每個人都發(fā)送高質(zhì)量的視頻，SFU決定使用哪個輸入流作為主要的發(fā)言人并為其選擇更高的分辨率，而其他參會者則選擇較低的分辨率。

經(jīng)過幾次實驗后，發(fā)現(xiàn)將較低分辨率的視頻縮放到較大顯示器時看起來不太好，所以你決定選取720p。你最終得到如下結果：

.會話中的每個參與者發(fā)送2.2Mbps（對于720p的視頻流，這是1.5Mbps，對于其他聯(lián)播的參與者會有額外80Kbps）

.會話中的每個參與者從占主導地位的發(fā)言者接收到1.5Mbps的數(shù)據(jù)，同時還有來自于較小窗口的兩個~300Mbps的輸入數(shù)據(jù)流

.在4名參與者中，媒體服務器需要接收8.8Mbps并發(fā)送8.4Mbps的視頻流

這里我們可以學到：

不同的用例中，具有相同用戶數(shù)量的群組視頻，在媒體服務器上會轉(zhuǎn)換為不同的負載。

如果沒有特別提到，聯(lián)播（simulcast）的效果是最好的，它提高了群組呼叫的效率和質(zhì)量（聯(lián)播是我們在Hangouts方式的視頻會議中使用的）。

在我們描述的用于4路視頻通話的3種場景中，我們得到了在SFU上3組的不同數(shù)據(jù)：

在WebRTC呼叫中有多少用戶處于活躍狀態(tài)？

這是個棘手的問題。

如果你使用的是MCU，在MCU可以處理的前提下，呼叫數(shù)量可以盡可能多。

如果您使用的是SFU，則取決于3個不同的參數(shù)：

1. 媒體服務器的復雜程度以及它的性能

2. 在客戶端設備上可用的資源

3. 構建基礎架構和實現(xiàn)級聯(lián)的方式

我們很快會回顧這些。

同樣的場景，不同的實現(xiàn)

在單次呼叫中，當用戶達到8-10個時，情況會變得復雜。這里我想分享一個公共服務（產(chǎn)品）的例子。

場景如下：

.在魔方矩陣方式布局中單次會議有9名參與者

.使用testRTC進入會話，實現(xiàn)全自動化

.因為是demo，在運行一分鐘之后進程會自動結束

.考慮到屏幕上有9個人，所以將所有人的分辨率降低到VGA，并分配1.3Mbps

.導致瀏覽器將接收10Mbps的數(shù)據(jù)進行處理

在這里媒體服務器會決定如何限制和測量流量。

這里是另一個demo，進行的是完全相同場景：

現(xiàn)在每個瀏覽器的平均傳入速率僅為2.7Mbps，幾乎是其他服務的四分之一。

同樣的場景，不同的實現(xiàn)。

對于主流應用產(chǎn)品又如何？

基于SFU模型的視頻會議，市面上的一些主流應用產(chǎn)品又如何？他們的應用程序中關于參會者規(guī)模有什么樣的限制？

以下是我從網(wǎng)上搜集到的內(nèi)容：

.Google Hangouts - 一次會議中最多有25位參與者，過去是最多容納10個人。當我第一次也是唯一一次使用它進行WebRTC培訓時，參會者人數(shù)一超過10人就卡死了，導致了我只能選擇使用其他視頻會議服務。

.Hangouts Meet - 在單個會話中將其參與者人數(shù)限制在50人以內(nèi)

.Houseparty - 8名參與者

.Skype - 25名參與者

.appear.in - 使用專業(yè)帳戶登錄，單個房間內(nèi)最多支持12個參與者

.Amazon Chime - 桌面版16位參與者，iOS上最多8位參與者（尚未支持安卓）

.Atlassian Stride and Meet Jitsi - 50位參與者

這是否意味著不能超過50個參與者？

我認為隨著會議規(guī)模的增加，難度越來越大：

CPaas對尺寸的限制

當您查看CPaaS平臺時，那些支持視頻和群組呼叫的服務通常會限制其會議規(guī)模。在大多數(shù)情況下，他們會給出一個他們測試過的或適合的參會者人數(shù)。正如我們所看到的那樣，這個參會者人數(shù)適用于一個非常具體的場景，但很可能不是你要滿足的場景需求。

在CPaaS中，在單個會話中，這些數(shù)字在從10位到100位參與者不等。通常情況下，如果超過給定的參會者人數(shù)，則超過指定數(shù)目的參與者只能觀看而不能發(fā)言。

要記住的關鍵點

需要記住的幾件事：

.群組規(guī)模越大，實施和優(yōu)化的復雜性就越高

.瀏覽器需要運行多個解碼器，這本身就是一種負擔

.在這種情況下，移動設備，特別是舊設備，可能很快就會癱倒。在確定要支持的會議人數(shù)規(guī)模之前，測試你計劃支持中的最老式，最小型的設備

.您可以構建SFU，使其不會將所有傳入的媒體流路由到每個人，而是選擇部分數(shù)據(jù)發(fā)送出去。例如，音頻通道上只傳送一個發(fā)言人的音頻數(shù)據(jù)，或者4個最重要的發(fā)言人的音頻數(shù)據(jù)

調(diào)整您的媒體服務器

調(diào)整大小和媒體服務器是我最近在testRTC上做的事情。過去我們曾經(jīng)和Kurento合作過一段時間，并正在計劃修補其他媒體服務器。我參與的每個項目中都會遇到這個問題：

在單個媒體服務器中，我們最多可以添加多少會話/用戶/流？

根據(jù)我們上面看到的關于速度和流數(shù)的內(nèi)容，最穩(wěn)妥的回答應該是：這很大程度上取決于你在實現(xiàn)什么業(yè)務。

如果你需要的是每個人都處于活躍狀態(tài)的群組呼叫，你應該選取在一臺服務器上容納100-500名參與者的方案。這些數(shù)字會根據(jù)你為媒體服務器選擇的計算機以及每個數(shù)據(jù)流平均計劃的比特率而有所不同。

如果你需要的是一個單主播對多觀眾的聯(lián)播，使用WebRTC是為了維持低延遲，200-1,000是較理想的估計規(guī)模，甚至可能更多。

大型機器還是小型機器？

你需要解決的另一件事是，要選擇哪臺計算機來托管你的媒體服務器。是選擇性能較差的大機器，還是體驗良好的小機器呢？

使用大型機器意味著你可以在一個服務器中添加更多的觀眾，這樣服務的復雜性就會降低。但是如果發(fā)生崩潰（媒體服務器崩潰），就會有更多的用戶受到影響。當你需要升級你的媒體服務器（很顯然你會），這個過程會讓你付出更多的代價，或者變得更加復雜。

機器越大，它的內(nèi)核就越多。這導致需要在多線程模式下運行媒體服務器。這意味著它們構建、調(diào)試和修復變得更加復雜。也增加更多不確定的部分。

選擇小型機器意味著你會更早地遇到規(guī)模問題，他們將需要更精細的算法和啟發(fā)式算法。在負載平衡服務時，會出現(xiàn)更多的極端情況。

基于流，帶寬還是CPU來確定規(guī)模？

如何確定你的媒體服務器達到了滿負載？如何決定下一個會話是否需要一臺新機器，還是放置在當前使用的媒體服務器上？如果選擇當前使用的媒體服務器，當新的參與者想要加入在此媒體服務器上正在運行的會話時，那么他們是否有足夠的空間？

這些問題不容易回答。

通常有3種不同的度量標準，用于決定何時從單個媒體服務器擴展到其他服務器。具體如下：

基于CPU?- 當CPU達到一定的百分比時，意味著機器是“滿”的。當你使用較小的機器時，它的效果最好，因為CPU是你消耗的第一個資源。

基于帶寬?- SFU消耗了大量網(wǎng)絡資源。如果你使用的是更大的機器，你可能不會達到CPU的極限，但是最終會消耗太多的帶寬。所以最終將通過帶寬監(jiān)控來決定可用的容量。

基于數(shù)據(jù)流?- 有時基于CPU和帶寬的挑戰(zhàn)在于，根據(jù)動態(tài)條件，可支持的會話和數(shù)據(jù)流的數(shù)量可能會有所不同。通過策略調(diào)整可能也無法應對這種情況，所以可能需要更多的計算。這將導致無論是基于CPU還是帶寬來調(diào)整計算機的大小，都需要根據(jù)服務器可支持的數(shù)據(jù)流數(shù)量制定規(guī)則。

這里面臨的挑戰(zhàn)是，無論你選擇哪種方案，確定規(guī)模都是需要獨自完成的。我看到，在需要解決這個問題時，很多人會選擇使用testRTC。

級聯(lián)單個會話

級聯(lián)是將一個媒體服務器連接到另一個媒體服務器的過程。如圖所示：

我們有一個4路組視頻電話，分布在3個不同的媒體服務器上。服務器根據(jù)需要在它們之間建立連接。為什么要做這個？

＃1 - 地理分布

當將SFU作為其中一部分并在全球范圍中提供服務時，立即引發(fā)的問題是在進行新的會話時，您將為其分配哪個SFU？在哪些數(shù)據(jù)中心？由于我們希望讓媒體服務器盡可能靠近用戶，因此我們要么提前知道有關會話的信息并根據(jù)這決定將其分配到哪里，要么通過合理的方式來決定，比如地理定位 - 我們選擇在離用戶最近的數(shù)據(jù)中心創(chuàng)建會議。

假設4人正在通話。其中3人來自紐約，而第4個人來自法國。但是如果是這個法國人最先加入到這個通話中，那么會發(fā)生什么？

結果是該服務器將會在法國托管。4人中有3人將遠離媒體服務器。顯然這不是最好的方法...

一種解決方案是，通過距離參與者最近的服務器之間進行傳播的方式來進行會議：

我們使用更多的服務器資源來獲取此會話，但我們對媒體路由有更多的控制權，所以我們可以更好地優(yōu)化它們。這提高了會議的媒體質(zhì)量。

＃2 - 碎片分配

假設我們可以在單個媒體服務器上連接多達100個參與者。此外，每次會議最多可容納10人。理想情況下，我們不希望為每個媒體服務器分配超過10次會議。

但是如果我告訴你會議的平均規(guī)模是2人呢？那么我們將得到這樣的分配:

這會導致服務器資源的大量浪費。我們該如何解決這個問題？

1. 通過預設人數(shù)達到最大會議規(guī)模。但這不是真正需要做的事情

2. 冒一個風險，假設你分配了50%的服務器容量，那么剩余的容量則是留給現(xiàn)有的會議以應對參會人數(shù)的增長。雖然仍然是在浪費資源，但程度較低。由于服務器資源的限制，我們可能無法應對會議中可能出現(xiàn)的邊緣情況

3. 通過跨媒體服務器遷移會話對服務器進行“碎片整理”。這聽起來不太有友好，而且可能會擾亂用戶。

4. 級聯(lián)會話。允許跨機器的規(guī)模增長

最后一個級聯(lián)中，您可以通過預留部分媒體服務器的資源，來實現(xiàn)將現(xiàn)有會話級聯(lián)到其他媒體服務器的目的。

＃3 - 更大的會議

假設您想創(chuàng)建比單個媒體服務器能夠處理的更大型會議，那么唯一的選擇就是級聯(lián)。

如果您的媒體服務器可以容納100名參與者，但是您希望參加規(guī)模為5000名的會議，那么您需要通過級聯(lián)以支持他們。但這并不容易，這就解釋了為什么沒有很多這樣的解決方案可以用，但這是可能實現(xiàn)的。

請注意，在這樣的大型會議上，媒體流不會是雙向的。在會議中，發(fā)送媒體流的參與者比較少，絕大部分的參與者都只是接收媒體流。關于純粹的聯(lián)播場景，在Red5 Pro博客上我寫了一篇關于的縮放挑戰(zhàn)的文章。

概括

本文中我們觸及了很多領域。在嘗試確定在WebRTC視頻通話中能夠有多少用戶時，應該做的是：

1. 無論會議是什么規(guī)模，都能使用WebRTC支持實現(xiàn)

1.1. 這是一個成本問題，并與商業(yè)模式保持一致，這將決定或打破這一模式。

1.2. 會議規(guī)模越大，實現(xiàn)的方式就會越復雜，同時需要更多的限制和假設

2. 分析你需要支持的復雜性

2.1. 統(tǒng)計每個設備和媒體服務器的傳入和傳出流

2.2. 決定每個流的視頻質(zhì)量（分辨率和比特率）

3. 定義將使用的媒體服務器

3.1. 選擇一種機器類型以運行媒體服務器

3.2. 在擴展之前計算出所需的規(guī)模

3.3. 檢查服務器資源上的增長是否是線性的

3.4. 決定是否基于帶寬，CPU，流數(shù)或其他進行擴展

4. 圖示的級聯(lián)該如何實現(xiàn)

<p style="border:0px;color:rgb(25,25,25);font-family:'PingFang