在本文章的討論中，筆者準備從幾個不同的方面來介紹WebRTC 服務器端的性能處理的介紹，具體包括：服務器端MCU/SFU模式的性能處理，主要影響要素，視頻會議畫面布局影響，測試工具討論，級聯/分布式部署討論和測試架構以及不同環(huán)境和角度的測試數據分享。
說明：
- 引用的論文和研究數據可能存在時間延后，讀者最好參考最新文章。
- 數據分享沒有過多介紹數據結果的具體測試背景，筆者最好進一步閱讀論文原文。
- 引用數據都來自于互聯網資源。
- 參考資料中的論文可以到知識星球下載：https://t.zsxq.com/Ei2Jim2
視頻會議部署方式-MCU/SFU
在討論視頻會議的性能時，我們首先需要確定基本的媒體處理架構。如果在沒有確定基本的技術架構之前討論視頻會議的性能是沒有任何意義，這些服務器可能也不存在任何的可比性。因此，在以下的測試數據討論中一定要注意這個前提條件。
SFU vs MCU
本圖片以及以下圖例均來自于互聯網資源
根據以上圖例，我們可以看出，無論用戶部署采用何種方式，這些方式本身都有自己的特色，用戶需要自己根據實際情況做決定，決定因素包括網絡帶寬費用，CPU資源費用和部署管理方式等都需要考慮。目前，市場上主流廠家基本上或者使用MCU方式，或者使用SFU方式。因此，在接下來的各種關于涉及穩(wěn)定性的數據說明中可能會涉及這些關鍵數據，因為部署方式的不同，這些數據也完全不同。除了以上說明以外，筆者另外簡單補充的幾點：
- MCU服務器端帶寬消耗/CPU消耗的成本是否可以支撐業(yè)務本身
- MCU管理是一個非常大的挑戰(zhàn)，一旦MCU服務器出現問題，會影響所有終端的穩(wěn)定性。SFU在這方面相對風險比較小。
- SFU寄希望終端來處理，消耗終端帶寬和CPU比較多。終端需要一定的優(yōu)化策略來完成高負載。隨著終端性能越來越高，目前看市場反饋的效果比較好。
- 因為MCU服務器承擔了更多的媒體管理能力，所以，相對來說，MCU容易提供業(yè)務處理，SFU需要結合其他方式進行處理。
以上分析僅簡單介紹了三種部署方式的存在的優(yōu)缺點。當然，很多研究人員針對這些部署方式有很多更加完善的深度討論，讀者可以結合自己的用戶場景做進一步學習，這里不再花費時間介紹。如果讀者想了解開源WebRTC媒體服務器的背景介紹，可以閱讀筆者的歷史文檔：
十大必知開源WebRTC服務器
主要影響要素
大家都知道，基于互聯網的產品或者應用的性能受制于很多環(huán)境因素，這些因素制約其性能。同樣，基于WebRTC的視頻會議系統(tǒng)也因為很多因素的制約，其性能會受到這些因素的影響。首先，筆者和大家分享一些筆者閱讀的關于WebRTC性能測試的一些研究結果和其相關論文。Bart Jansen在他發(fā)表的論文中提到了時延，丟包， 帶寬，部署方式（Mesh/SFU），視頻編碼（VP8，VP9，H264），移動網絡，無線網絡環(huán)境來進行綜合測試。另外一位研究人員Sajjad Taheri在他發(fā)表的論文中，通過具體WebRTC的創(chuàng)建和媒體性能進行了分析評價：
連接測試評價參數
媒體處理性能評價參數
Boni García在其發(fā)表的論文中針對WebRTC的瀏覽器進行了比較深入的測試。Boris Grozev在關于其SFU測試和MCU測試中的測試了圖像質量，客戶端資源占用率，渲染Rendered Frame Rate，服務器端資源占用率，流媒體切換時延等做了非常深度的分析。Cristian Constantin Spoiala針對WebRTC在容器和虛擬機境中針對Kurento做了完整的測試。Vamis Xhagjika???針對WebRTC云部署（MCU/SFU）環(huán)境發(fā)表了一篇關于WebRTC服務器的負載和性能測試的模型。這些測試研究都是從不同角度使用各種模型和工具對WebRTC資源和性能做的充分的測試。為我們討論關于WebRTC 視頻會議服務器的性能提供了非常完整的概括。
除了以上討論以外，如果涉及到更底層的圖像處理的參數和編碼處理，視頻質量會取決于更多的影響參數。視頻會議著名廠家思科對傳輸網絡中其視頻質量的服務保障有基本的參數標準，用戶可以根據此標準作為一個參考來評價視頻會議質量。
思科針對視頻會議和視頻媒體流推薦的質量影響變量：
雖然以上研究人員從不同的角度和應用場景針對WebRTC性能做了詳細分析，但是因為我們使用場景不同，我們不可能完全針對這些環(huán)境做深入了解，我們只能針對比較接近自己的環(huán)境進行研究。因為我們僅對當前關于WebRTC視頻會議的應用比較關心，因此，我們更多會討論視頻會議部署中關于服務器端資源，終端資源和視頻圖像質量等進行進一步分析。其他測試手段和項目讀者可以查閱相關行業(yè)研究成果來學習。
畫面布局處理的影響
在前面的討論中，筆者介紹了很多研究人員針對WebRTC的性能進行的各種測試。但是，在這些測試中，針對瀏覽器界面布局的設置和分辨率的討論相對比較少。事實上，這個因素也是影響視頻會議穩(wěn)定性的重要因素。因此，這里我們單獨加以具體討論。在視頻會議的測試討論中，一般會根據基本的三個參數，分辨率（resolution），比特率和會話人數來確定。當然，如果針對視頻還有更多細節(jié)的其他特性，例如顏色清晰度，穩(wěn)定性，偽影，銳度，對比度，亮度等非常專業(yè)的特性，這些特性可能會應用在WebRTC環(huán)境中的一些行業(yè)應用中，應用軟件通過攝像頭獲取更多分析數據，進行實時分析。這里，我們僅討論一般情況下，視頻會議中分辨率，傳輸比特率和會會人數的測試討論。根據這三個數據，用戶在視頻會議的畫面布局將會決定服務器端和終端的處理能力。在視頻會議的場景中，我們一般也做不到終端用戶都使用非常高的分辨率，或者使用其他高清終端（實際上每個人都想獲得高清效果），但是視頻會議還有其特殊性，一般來說，會議主持人和演講人具有相對比較大的權限，這些人的布局設計可以通過調整的方式來實現，這樣就可以優(yōu)化整個視頻會議的系統(tǒng)性能。假設，如果用戶WQHD顯示器的話，有四個會議用戶的話，使用SFU的模式處理方式的話，根據布局和分辨率的不同，SFU服務器所占用的發(fā)送和接收到帶寬都完全不同，用戶端的帶寬占用也完全不同。一些圖例對比了如果用戶使用720P，VGA和Hangouts模式的實際帶寬：
目前，比較熱門的一些視頻會議基本上都采用Hangouts的模式，會議主講人顯示圖像顯示比較大，其他人的相對比較小，很多其他用戶可能關閉了圖像功能，僅留語音功能。另外，還有的開源視頻會議系統(tǒng)，例如，jitsi，它提供了更為靈活的優(yōu)化方式，根據自己的網絡環(huán)境和其必要性，用戶端可以靈活調整圖像質量。這樣就更加保證了會議的穩(wěn)定性。
當然，如果用戶都開啟了攝像頭，整個測試的數據肯定會完全不同。通過以上數據可以看出，事實上，視頻會議支持的人數在MCU和SFU環(huán)境中是完全不同的。如果是MCU的話，支持人數更多取決于MCU本身的支持能力。如果是SFU的話，讀者可能需要考慮SFU的部署環(huán)境設置，客戶端的能力，SFU的級聯配置。另外，如果讀者部署在云平臺的話，例如CPaaS，用戶還要考慮平臺的支持能力。
50 participants in a single session（一個視頻會議的基準設置）
幾個開源的視頻會議平臺所支持的人數以及拓展支持
| 平臺名稱 | 支持人數（建議使用人數/測試用戶） | 攝像頭數量 | 拓展支持（會議房間是否可以調整） |
| Jitsi | 75/35/測試1000-4000用戶 | 120用戶-靜音5攝像頭 | 支持均衡負載，HA |
| bigbluebutton（BBB） | 150/200 | 150-<10攝像頭 | HA拓展支持更多會議房間/用戶 |
multiparty-meeting（MM） |
100用戶/測試用戶/2000用戶（MX） | 135用戶-<10攝像頭 | 支持HA均衡負載 |
為了滿足更多的用戶需求，級聯方式是SFU使用的主要的配置方式：
如果使用MCU方式，或者需要單臺服務器支持更多用戶人數的話，部署視頻會議只能通過增加CPU的處理能力，增加帶寬和控制人數方式來進行優(yōu)化。
Cascading/媒體服務器分布式拓展
除了前面筆者討論的畫面布局問題帶來的視頻會議服務器的性能影響以外，如果視頻會議需要拓展支持的話，特別是SFU模式下的拓展支持，級聯的技術架構和數據延遲也會帶來視頻會議的穩(wěn)定性問題。在實際生產環(huán)境中，我們自己也經常會遇到會議狀態(tài)的不確定性：會議人數很難確定，會議人員地理位置很難確定，終端網絡質量和終端處理能力。這樣就會導致視頻會議的不穩(wěn)定性和潛在問題。從幾個會議人員一下子攀升到幾十個或者上百個，甚至于上千人數等問題，如何進行拓展支持是對視頻會議服務器部署極大的考驗。
當會議人數達到一定的數量時，視頻會議服務器端網絡帶寬和技術架構肯定會受到極大沖擊。一般的解決辦法可以通過限制會議人數，在確認的人數基礎上增加帶寬，設置I-frame控制丟包，針對流媒體支持，支持WebRTC的前向糾錯（FEC），通過WebRTC客戶端支持圖像質量特征設置支持。為了完全實現視頻會議的拓展和HA服務，幾乎所有開源的WebRTC視頻服務器或者媒體服務器都可以通過不同的方式實現拓展。以下就是一個Jitsi實現級聯的技術架構示例，通過Jitsi會議橋來創(chuàng)建不同的拓展和HA高可靠性部署。
當然，這種級聯部署方式仍然可能會出現其他的問題，比如，會議人員的地理位置的不確定導致的數據交互延時，還有丟包問題，RTP媒體流延遲，TURN服務器解析DNS的延遲。在以下示例中，Jitsi的jicofo作為信令服務器和jvb（jitsi-videobridge） 媒體服務器進行拓展交互，這樣可以達到最佳優(yōu)化效果。
除了在平臺進行拓展處理以外，底層服務器端也可能需要進行優(yōu)化拓展。
在WebRTC的視頻會議或者媒體服務器端，一個非常消耗CPU資源的處理就是編碼轉換。為了保證媒體服務器的穩(wěn)定性和可拓展性，一些WebRTC服務器也充分使用了拓展的技術架構，例如kurento的媒體服務器（底層是GStreamer），然后通過底層的拓展來實現人群跟蹤檢測，車牌識別等具體的業(yè)務場景。在各種WebRTC服務器對比中，Kurento服務器端對各種場景和中間件處理比較靈活。其實，這種特性也是因為Kurento本身特性決定的，應該不能說是它的一個優(yōu)點。Kurento本身的設計初衷就是支持不同媒體服務器場景的，因此相對比較靈活，其他的幾個媒體服務器更多側重于視頻會議一種業(yè)務，沒有其他的場景支持，因此也沒有kurento設計的那么靈活。
Kurento支持了多種非常具體的業(yè)務場景，包括人臉識別，車牌識別（支持IP攝像頭），物體跟蹤，人群監(jiān)控等場景，因此對中間件支持比較豐富，也支持了多種編碼格式和編碼轉換的處理。
根據研究人員Boni García在關于Kurento 的WebRTC 媒體服務器的論文中的總結，如果需要拓展媒體服務器的話，基于kurento的WebRTC服務器可以通過橫向增加服務器數量， 如果是云平臺的話增加實例，CPU，內存來實現媒體服務器的拓展。具體的拓展方式以及其靈活性取決于WebRTC服務器的設計架構，讀者可以參考此討論來進行學習。關于kurento的背景介紹，讀者可以參考以前的文章：
kurento-開源WebRTC服務器-”一個半死不活"的開源項目
Scalelite是開源的均衡負載項目，它支持了BigBlueButto（BBB）的技術架構，通過界面可以配置
Scalelite支持的BBB均衡負載技術架構
它可以實現數據庫，Scalelite Server，Redis Cache 服務器。錄像/錄音共享，通過媒體服務器BBB拓展可以實現更多會議人數。
WebRTC服務器測試工具
在前面的章節(jié)中，我們討論了關于級聯的技術架構HA處理方式的不同，還有媒體服務器拓展的方式。這些拓展的技術架構都是為了保證其WebRTC服務器的穩(wěn)定性，那么，如何針對WebRTC服務器進行穩(wěn)定性測試呢？其實，市場上和開源社區(qū)也提供了一些非常有效的測試工具，可以幫助用戶從不同角度來測試WebRTC服務器端的一些性能，以下是目前幾個主流的WebRTC 服務器測試工具：
- WebRTC-Analyzer：基于SimpleWebRTC開發(fā)的分析工具
- WebRTCBench：WebRTC基準測試框架，由Parallel Architectures and Systems LAB開發(fā)，由Intel贊助
- Jitsi-Hammer：專門針對Jitsi開發(fā)的測試工具，可以創(chuàng)建會議室，播放視頻，克隆用戶，生成RTP流
- estRTC：商業(yè)版本的WebRTC視頻會議測試工具
- cosmosoftware：通過多種WebRTC場景測試工具，包括黑客工具，端對端加密服務，WebRTC視頻質量評估工具。它支持目前幾個主流的WebRTC開源服務器（Janus, Jitsi, Medooze ，kurento等）
- ElasTest：開源基于云平臺業(yè)務的測試工具，支持WebRTC測試
- Selenium Framework：商業(yè)的自動測試工具，可以針對WebRTC進行測試。
- Jattack：開源的針對WebRTC服務器端的壓力測試工具，但是目前僅支持Janus。
WebRTC測試架構和應用測試數據分享
筆者在前面討論了幾個關于WebRTC的性能的重要指標以及相關的測試工具。但是，如果我們看一些測試分享時，我們仍然發(fā)現，測試人員進行的測試都是從不同的角度進行的。事實上，業(yè)內很多研究人員以及提出了比較完整的WebRTC測試技術架構，測試人員可以從這個技術架構中選擇不同的角度進行測試。Boni García發(fā)布了關于WebRTC 測試的挑戰(zhàn)和實踐解決辦法，如果讀者計劃對WebRTC進行測試的話，可以參考這個測試架構進行測試。
WebRTC 測試技術架構
在實際的測試數據中，測試結果以及相關測試包括網絡帶寬的結果影響參數（編碼類型，分辨率，Frame rate，圖像大小，呼叫量），用戶人數，呼叫創(chuàng)建耗時，瀏覽器類型，媒體服務器類型（MCU/SFU），平臺部署方式（容器/虛擬機/云平臺，服務器IO/網絡帶寬），時延，視頻質量等對比，CPU消耗，內存消耗，QoS/QoE。Muhammad Shahid在他們團隊的論文中討論了關于視頻會議QoS和QoE的相關測試參數，在進行測試時也需要按照這些參數對比測試。
下面，筆者分享一些不同測試結果，讀者通過這些結果可以基本上了解相關WebRTC性能以及完整的相關要素，這些數據具有一定的參考意義。
瀏覽器是WebRTC呼叫中非常敏感的終端，很多WebRTC功能經常受限于瀏覽器的版本。WebRTC應用環(huán)境中，使用不同瀏覽器實現的信令創(chuàng)建結果。
臉部識別的CPU消耗
內存消耗
存儲設備使用情況
網絡帶寬使用情況
http://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras
Sajjad Taheri發(fā)布了關于針對WebRTC性能測試的基礎測試方法，他不同終端環(huán)境下WebRTC呼叫初始時間，ICE創(chuàng)建時間等做了非常深入的研究調查。這也是很多WebRTC用戶經常會遇到的問題，為什么WebRTC呼叫時間總是很長的一個合理的解釋。
關于ICE創(chuàng)建/offer/answer時間
不同網絡環(huán)境中ICE打洞時間耗費
不同終端VP8編碼解碼渲染執(zhí)行情況
Emmanuel Andr?e針對不同開源WebRTC 媒體服務器SFU模式下的對比測試，包括了加載不同數量的用戶進行測試，傳輸結果，時延和視頻效果評價得出來不同的測試結果。
Transmission bit rates （Jitsi，Janus，Medooze，Kurento和Mediasoup）結果
視頻會議評價結果：
WebRTC媒體服務器可以部署在物理機，也可以部署在虛擬機容器。這些不同平臺針對WebRTC服務器的性能有不同的影響。研究人員針對容器和虛擬機（KVM）上進行了WebRTC媒體服務器的性能測試。使用的WebRTC媒體服務器是Kurento Media Server （KMS）。測試架構如下：
根據此研究人員的測試，容器的整體性能優(yōu)于KVM，特別是實時通信應用中時延的處理比KVM表現要好。
針對具體的WebRTC視頻會議服務器性能測試中，Jitsi的測試相對比較多，測試參數有非常具體。Boris Grozev 和 Emil Ivov根據以下幾個指標對Jitsi進行了測試評估（每秒中進行的測試參數變量）
- conferences —活動會議數量
- endpoints — 所有會議加載的終端數量
- cpu_usage —CPU負載，包括CPU狀態(tài)
- network_in—接收的網絡數據bitrate
- network_out — 發(fā)出的bitrate
- bitrate —總和（network_in 和network_out），以Mbps計算。
- streams —Jitsi會議橋能夠處理的語音視頻數據流總和，這個數值取決于終端數量。
1056語音/視頻占用50Mbps帶寬
1056語音/視頻消耗20%CPU
其他語音/視頻終端加載的帶寬和CPU消耗狀態(tài)
關于針對視頻會議QoE的研究是一個非常重要的技術領域，有的研究論文針對H264高分辨率的研究，有的針對解碼算法進行研究，還有的針對視頻質量和壓縮進行研究。這些視頻會議的算法研究都對QoE有非常大的影響。很多關于QoE評價方法，讀者有興趣的話，可以進行進一步研究。
常用的關于QoS和QoE評價方式中的參數
如果用戶需要進行測試的話，在有限資源條件下盡量采用比較常用的參數，例如抖動，時延，帶寬和丟包測試。這里，我們分享Ahmad Vakili的關于QoE和Frame Rate，壓縮比，Bit Rate以及帶寬預估的研究結果。
WebRTC視頻會議可以使用不同的視頻編碼，目前使用最多的三種編碼中，它們都有各自的特點，特別是在網絡擁塞或者網絡帶寬有限時，它們的表現都不同。在720P測試環(huán)境下，三種視頻編碼的不同表現。H264相對VP8和V9，在帶寬有限時，它會產生更大的延遲，同時在分辨率不同的環(huán)境下，H264相對支持表現比較差。
在WebRTC視頻會議使用環(huán)境中，CPU和帶寬是非常重要的參數（內存相對不太敏感），這兩個參數會直接影響視頻的質量。以下是一個視頻會議測試中，使用SFU模式，不同帶寬環(huán)境下的視頻質量表現（使用VP8編碼）。
設置為 low quality時的結果：
設置為high quality時的結果：
不同quality的jitter buffer delay結果
總結
在本文章介紹中，筆者主要分享了關于基于WebRTC的媒體服務器和視頻會議的介紹。首先，筆者介紹了分享了關于WebRTC性能的一些重要指標，然后介紹了關于WebRTC目前研究的比較新的研究成果，影響WebRTC服務器執(zhí)行的幾個要素，關于視頻會議畫面布局帶來的影響，接下來，筆者介紹了關于WebRTC測試的幾個主要工具，最后筆者和讀者分享了WebRTC的測試架構，以及不同研究人員針對不同環(huán)境和不同角度進行的WebRTC的測試和相關性能報告。
雖然，筆者盡可能完整介紹了關于WebRTC服務器端性能測試的一些數據，但是，因為資源有限，我們缺少針對STUN和TURN的測試報告，也缺少基于App端的測試報告，還缺少關于WebRTC各種開源終端的測試報告。希望以后有機會能夠獲得更多資源來和讀者分享。
再次說明，如果讀者有興趣對某些數據或者測試手段進行進一步研究的話，建議讀者閱讀完整的論文原文和其相關研究論文。
參考資料：
www.w3.org
www.jitsi.org
www.jitsi.org.cn
Bart Jansen，Performance Evaluation of WebRTC based Video Conferencing
Sajjad Taheri，WebRTCBench: A Benchmark for Performance Assessment of WebRTC Implementations
Boni García，WebRTC Testing: State of the Art
Boris Grozev，Experimental Evaluation of Simulcast for WebRTC
Cristian Constantin Spoiala，Performance comparison of a WebRTC server on Docker versus Virtual Machine
Vamis Xhagjika???, Load and Video Performance Patterns of a Cloud Based WebRTC Architecture
Boris Grozev，Jitsi Videobridge Performance Evaluation
Emmanuel Andr?e， Comparative Study of WebRTC Open Source SFUs
for Video Conferencing
Boni García，Kurento: The Swiss Army Knife of WebRTC Media Servers
https://github.com/havfo/multiparty-meeting/blob/master/HAproxy.md
https://www.polycom.fr/content/dam/polycom/common/documents/whitepapers/benchmarking-videoconferencing-success-wp-enus.pdf
https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-video/212134-Video-Quality-of-Service-QOS-Tutorial.html#anc19
https://github.com/blindsidenetworks/scalelite
Boni García，WebRTC Testing: Challenges and Practical Solutions
https://www.red5pro.com/blog/guest-post-tashi-levent-levi-webrtc-scaling-challenges/
https://jitsi.org/blog/new-tutorial-video-scaling-jitsi-meet-in-the-cloud/
B.A. Jansen，Performance Analysis of WebRTC-based Video Conferencing
融合通信/IPPBX/FreePBX商業(yè)解決方案：www.hiastar.com
最新Asterisk完整中文用戶手冊詳解及免費slack支持：www.asterisk.org.cn
Freepbx/FreeSBC技術文檔： www.freepbx.org.cn
如何使用FreeSBC，qq技術分享群：334023047
關注微信公眾號：asterisk-cn，獲得有價值的通信行業(yè)技術分享
