WebRTC視頻通話中最多能容納多少用戶？

作者 / Tsahi Levent-Levi

翻譯 / 小極狗

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

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

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

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

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

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

分析複雜性

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

對於WebRTC，以及實時視頻通信，我們將歸結為速度和流數:

1、速度——在伺服器中我們所期待的解析度和比特率。

2、流數——單個會話的媒體流數量。

讓我們從一個例子開始。

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

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

魔方矩陣方式：720p

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

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

• 會話中的每個參與者發送1.5Mbps，接收3個1.5Mbps的流
• 在4個參與者中，媒體伺服器需要接收6Mbps並發送18Mbps的數據。

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

魔方矩陣方式：VGA

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

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

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

Hangouts方式

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

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

這一次，我們將使用聯播的方式（simulcast），並計劃讓每個人都發送高質量的視頻，SFU決定使用哪個輸入流作為主要的發言人並為其選擇更高的解析度，而其他參會者則選擇較低的解析度。

經過幾次實驗後，發現將較低解析度的視頻縮放到較大顯示器時看起來不太好，所以你決定選取720p。你最終得到如下結果：

• 會話中的每個參與者發送2.2Mbps（對於720p的視頻流，這是1.5Mbps，對於其他聯播的參與者會有額外80Kbps）
• 會話中的每個參與者從佔主導地位的發言者接收到1.5Mbps的數據，同時還有來自於較小窗口的兩個~300Mbps的輸入數據流
• 在4名參與者中，媒體伺服器需要接收8.8Mbps並發送8.4Mbps的視頻流

這裡我們可以學到：

不同的用例中，具有相同用戶數量的群組視頻，在媒體伺服器上會轉換為不同的負載。

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

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

在WebRTC呼叫中有多少用戶處於活躍狀態？

這是個棘手的問題。

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

如果您使用的是SFU，則取決於3個不同的參數：

1. 媒體伺服器的複雜程度以及它的性能

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

3. 構建基礎架構和實現級聯的方式

我們很快會回顧這些。

同樣的場景，不同的實現

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

場景如下：

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

• 使用testRTC進入會話，實現全自動化

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

• 考慮到屏幕上有9個人，所以將所有人的解析度降低到VGA，並分配1.3Mbps

• 導致瀏覽器將接收10Mbps的數據進行處理

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

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

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

同樣的場景，不同的實現。

對於主流應用產品又如何？

基於SFU模型的視頻會議，市面上的一些主流應用產品又如何？他們的應用程序中關於參會者規模有什麼樣的限制？

以下是我從網上搜集到的內容：

• Google Hangouts - 一次會議中最多有25位參與者，過去是最多容納10個人。當我第一次也是唯一一次使用它進行WebRTC培訓時，參會者人數一超過10人就卡死了，導致了我只能選擇使用其他視頻會議服務。
• Hangouts Meet - 在單個會話中將其參與者人數限制在50人以內
• Houseparty - 8名參與者
• Skype - 25名參與者
• http://appear.in - 使用專業帳戶登錄，單個房間內最多支持12個參與者
• Amazon Chime - 桌面版16位參與者，iOS上最多8位參與者（尚未支持安卓）
• Atlassian Stride and Meet Jitsi - 50位參與者

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

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

CPaas對尺寸的限制

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

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

要記住的關鍵點

需要記住的幾件事：

• 群組規模越大，實施和優化的複雜性就越高
• 瀏覽器需要運行多個解碼器，這本身就是一種負擔
• 在這種情況下，移動設備，特別是舊設備，可能很快就會癱倒。在確定要支持的會議人數規模之前，測試你計劃支持中的最老式，最小型的設備
• 您可以構建SFU，使其不會將所有傳入的媒體流路由到每個人，而是選擇部分數據發送出去。例如，音頻通道上只傳送一個發言人的音頻數據，或者4個最重要的發言人的音頻數據

調整您的媒體伺服器

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

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

根據我們上面看到的關於速度和流數的內容，最穩妥的回答應該是：這很大程度上取決於你在實現什麼業務。

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

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

大型機器還是小型機器？

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

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

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

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

基於流，帶寬還是CPU來確定規模？

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

這些問題不容易回答。

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

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

基於帶寬 - SFU消耗了大量網路資源。如果你使用的是更大的機器，你可能不會達到CPU的極限，但是最終會消耗太多的帶寬。所以最終將通過帶寬監控來決定可用的容量。

基於數據流 - 有時基於CPU和帶寬的挑戰在於，根據動態條件，可支持的會話和數據流的數量可能會有所不同。通過策略調整可能也無法應對這種情況，所以可能需要更多的計算。這將導致無論是基於CPU還是帶寬來調整計算機的大小，都需要根據伺服器可支持的數據流數量制定規則。

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

級聯單個會話

級聯是將一個媒體伺服器連接到另一個媒體伺服器的過程。如圖所示：

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

＃1 - 地理分布

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

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

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

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

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

＃2 - 碎片分配

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

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

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

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

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

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

4. 級聯會話。允許跨機器的規模增長

最後一個級聯中，您可以通過預留部分媒體伺服器的資源，來實現將現有會話級聯到其他媒體伺服器的目的。

＃3 - 更大的會議

假設您想創建比單個媒體伺服器能夠處理的更大型會議，那麼唯一的選擇就是級聯。

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

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

概括

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

1. 無論會議是什麼規模，都能使用WebRTC支持實現

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

1.2. 會議規模越大，實現的方式就會越複雜，同時需要更多的限制和假設

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

2.1. 統計每個設備和媒體伺服器的傳入和傳出流

2.2. 決定每個流的視頻質量（解析度和比特率）

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

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

3.2. 在擴展之前計算出所需的規模

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

3.4. 決定是否基於帶寬，CPU，流數或其他進行擴展

4. 圖示的級聯該如何實現

4.1. 提供更好的地理位置支持

4.2. 在雲基礎設施上協助資源碎片化

4.3. 或者使用它在單個媒體伺服器的容量之外增加會議

那麼，最終取決於你的WebRTC會議的規模有多大。

活動預告：3月17日，即構科技主辦的ZEGO Meetup，將攜手直播行業的4位技術大咖，和大家一起暢談視頻直播的技術與未來。這裡有：

《視頻直播的這十年》

《連麥互動直播 X 微信小程序》

《秀色直播的技術實踐之路》

《AI賦能直播：反欺詐技術為直播平台保駕護航》

乾貨滿滿，就等你來！

點擊鏈接，即可快速報名：視頻直播+的技術實踐之道 | ZEGO Meetup 第二期

關於即構ZEGO

即構科技於2015年由QQ前總經理林友堯創立，A輪獲得IDG投資，核心團隊來自騰訊QQ，匯聚了來自YY和華為等廠商的頂尖語音視頻人才。即構ZEGO致力於提供全球最清晰最穩定的實時語音視頻雲服務，助力企業業務創新，改變用戶線上溝通方式。即構ZEGO深耕視頻直播、視頻社交、遊戲語音、線上抓娃娃和在線教育等領域，贏得了映客、花椒直播、一直播、喜馬拉雅FM、陌陌遊戲、自由之戰2、和好未來等頂級廠商託付和信賴。