在本文章的討論中，筆者準備從幾個不同的方面來介紹WebRTC 服務器端的性能處理的介紹，具體包括：服務器端MCU/SFU模式的性能處理，主要影響要素，視頻會議畫面布局影響，測試工具討論，級聯(lián)/分布式部署討論和測試架構(gòu)以及不同環(huán)境和角度的測試數(shù)據(jù)分享。

　　1）引用的論文和研究數(shù)據(jù)可能存在時間延后，讀者最好參考最新文章。

　　2）數(shù)據(jù)分享沒有過多介紹數(shù)據(jù)結(jié)果的具體測試背景，筆者最好進一步閱讀論文原文。

　　3）引用數(shù)據(jù)都來自于互聯(lián)網(wǎng)資源。

　　4）參考資料中的論文可以到知識星球下載：https://t.zsxq.com/Ei2Jim2

　　在討論視頻會議的性能時，我們首先需要確定基本的媒體處理架構(gòu)。如果在沒有確定基本的技術(shù)架構(gòu)之前討論視頻會議的性能是沒有任何意義，這些服務器可能也不存在任何的可比性。因此，在以下的測試數(shù)據(jù)討論中一定要注意這個前提條件。

　

　　本圖片以及以下圖例均來自于互聯(lián)網(wǎng)資源

　　

　　根據(jù)以上圖例，我們可以看出，無論用戶部署采用何種方式，這些方式本身都有自己的特色，用戶需要自己根據(jù)實際情況做決定，決定因素包括網(wǎng)絡(luò)帶寬費用，CPU資源費用和部署管理方式等都需要考慮。目前，市場上主流廠家基本上或者使用MCU方式，或者使用SFU方式。因此，在接下來的各種關(guān)于涉及穩(wěn)定性的數(shù)據(jù)說明中可能會涉及這些關(guān)鍵數(shù)據(jù)，因為部署方式的不同，這些數(shù)據(jù)也完全不同。除了以上說明以外，筆者另外簡單補充的幾點：

　　以上分析僅簡單介紹了三種部署方式的存在的優(yōu)缺點。當然，很多研究人員針對這些部署方式有很多更加完善的深度討論，讀者可以結(jié)合自己的用戶場景做進一步學習，這里不再花費時間介紹。如果讀者想了解開源WebRTC媒體服務器的背景介紹，可以閱讀筆者的歷史文檔：

　　大家都知道，基于互聯(lián)網(wǎng)的產(chǎn)品或者應用的性能受制于很多環(huán)境因素，這些因素制約其性能。同樣，基于WebRTC的視頻會議系統(tǒng)也因為很多因素的制約，其性能會受到這些因素的影響。首先，筆者和大家分享一些筆者閱讀的關(guān)于WebRTC性能測試的一些研究結(jié)果和其相關(guān)論文。Bart Jansen在他發(fā)表的論文中提到了時延，丟包, 帶寬，部署方式（Mesh/SFU），視頻編碼（VP8，VP9，H264），移動網(wǎng)絡(luò)，無線網(wǎng)絡(luò)環(huán)境來進行綜合測試。另外一位研究人員Sajjad Taheri在他發(fā)表的論文中，通過具體WebRTC的創(chuàng)建和媒體性能進行了分析評價：

　　連接測試評價參數(shù)

　　

　　媒體處理性能評價參數(shù)

　　Boni García在其發(fā)表的論文中針對WebRTC的瀏覽器進行了比較深入的測試。Boris Grozev在關(guān)于其SFU測試和MCU測試中的測試了圖像質(zhì)量，客戶端資源占用率，渲染Rendered Frame Rate，服務器端資源占用率，流媒體切換時延等做了非常深度的分析。Cristian Constantin Spoiala針對WebRTC在容器和虛擬機境中針對Kurento做了完整的測試。Vamis Xhagjika???針對WebRTC云部署（MCU/SFU）環(huán)境發(fā)表了一篇關(guān)于WebRTC服務器的負載和性能測試的模型。這些測試研究都是從不同角度使用各種模型和工具對WebRTC資源和性能做的充分的測試。為我們討論關(guān)于WebRTC 視頻會議服務器的性能提供了非常完整的概括。

　　除了以上討論以外，如果涉及到更底層的圖像處理的參數(shù)和編碼處理，視頻質(zhì)量會取決于更多的影響參數(shù)。視頻會議著名廠家思科對傳輸網(wǎng)絡(luò)中其視頻質(zhì)量的服務保障有基本的參數(shù)標準，用戶可以根據(jù)此標準作為一個參考來評價視頻會議質(zhì)量。

　　思科針對視頻會議和視頻媒體流推薦的質(zhì)量影響變量：

　　雖然以上研究人員從不同的角度和應用場景針對WebRTC性能做了詳細分析，但是因為我們使用場景不同，我們不可能完全針對這些環(huán)境做深入了解，我們只能針對比較接近自己的環(huán)境進行研究。因為我們僅對當前關(guān)于WebRTC視頻會議的應用比較關(guān)心，因此，我們更多會討論視頻會議部署中關(guān)于服務器端資源，終端資源和視頻圖像質(zhì)量等進行進一步分析。其他測試手段和項目讀者可以查閱相關(guān)行業(yè)研究成果來學習。

　　在前面的討論中，筆者介紹了很多研究人員針對WebRTC的性能進行的各種測試。但是，在這些測試中，針對瀏覽器界面布局的設(shè)置和分辨率的討論相對比較少。事實上，這個因素也是影響視頻會議穩(wěn)定性的重要因素。因此，這里我們單獨加以具體討論。在視頻會議的測試討論中，一般會根據(jù)基本的三個參數(shù)，分辨率（resolution），比特率和會話人數(shù)來確定。當然，如果針對視頻還有更多細節(jié)的其他特性，例如顏色清晰度，穩(wěn)定性，偽影，銳度，對比度，亮度等非常專業(yè)的特性，這些特性可能會應用在WebRTC環(huán)境中的一些行業(yè)應用中，應用軟件通過攝像頭獲取更多分析數(shù)據(jù)，進行實時分析。這里，我們僅討論一般情況下，視頻會議中分辨率，傳輸比特率和會會人數(shù)的測試討論。根據(jù)這三個數(shù)據(jù)，用戶在視頻會議的畫面布局將會決定服務器端和終端的處理能力。在視頻會議的場景中，我們一般也做不到終端用戶都使用非常高的分辨率，或者使用其他高清終端（實際上每個人都想獲得高清效果），但是視頻會議還有其特殊性，一般來說，會議主持人和演講人具有相對比較大的權(quán)限，這些人的布局設(shè)計可以通過調(diào)整的方式來實現(xiàn)，這樣就可以優(yōu)化整個視頻會議的系統(tǒng)性能。假設(shè)，如果用戶WQHD顯示器的話，有四個會議用戶的話，使用SFU的模式處理方式的話，根據(jù)布局和分辨率的不同，SFU服務器所占用的發(fā)送和接收到帶寬都完全不同，用戶端的帶寬占用也完全不同。一些圖例對比了如果用戶使用720P，VGA和Hangouts模式的實際帶寬：

　　目前，比較熱門的一些視頻會議基本上都采用Hangouts的模式，會議主講人顯示圖像顯示比較大，其他人的相對比較小，很多其他用戶可能關(guān)閉了圖像功能，僅留語音功能。另外，還有的開源視頻會議系統(tǒng)，例如，jitsi，它提供了更為靈活的優(yōu)化方式，根據(jù)自己的網(wǎng)絡(luò)環(huán)境和其必要性，用戶端可以靈活調(diào)整圖像質(zhì)量。這樣就更加保證了會議的穩(wěn)定性。

　　當然，如果用戶都開啟了攝像頭，整個測試的數(shù)據(jù)肯定會完全不同。通過以上數(shù)據(jù)可以看出，事實上，視頻會議支持的人數(shù)在MCU和SFU環(huán)境中是完全不同的。如果是MCU的話，支持人數(shù)更多取決于MCU本身的支持能力。如果是SFU的話，讀者可能需要考慮SFU的部署環(huán)境設(shè)置，客戶端的能力，SFU的級聯(lián)配置。另外，如果讀者部署在云平臺的話，例如CPaaS，用戶還要考慮平臺的支持能力。

　　50 participants in a single session（一個視頻會議的基準設(shè)置）

 

　　為了滿足更多的用戶需求，級聯(lián)方式是SFU使用的主要的配置方式：

　　如果使用MCU方式，或者需要單臺服務器支持更多用戶人數(shù)的話，部署視頻會議只能通過增加CPU的處理能力，增加帶寬和控制人數(shù)方式來進行優(yōu)化。

　　除了前面筆者討論的畫面布局問題帶來的視頻會議服務器的性能影響以外，如果視頻會議需要拓展支持的話，特別是SFU模式下的拓展支持，級聯(lián)的技術(shù)架構(gòu)和數(shù)據(jù)延遲也會帶來視頻會議的穩(wěn)定性問題。在實際生產(chǎn)環(huán)境中，我們自己也經(jīng)常會遇到會議狀態(tài)的不確定性：會議人數(shù)很難確定，會議人員地理位置很難確定，終端網(wǎng)絡(luò)質(zhì)量和終端處理能力。這樣就會導致視頻會議的不穩(wěn)定性和潛在問題。從幾個會議人員一下子攀升到幾十個或者上百個，甚至于上千人數(shù)等問題，如何進行拓展支持是對視頻會議服務器部署極大的考驗。

　　當會議人數(shù)達到一定的數(shù)量時，視頻會議服務器端網(wǎng)絡(luò)帶寬和技術(shù)架構(gòu)肯定會受到極大沖擊。一般的解決辦法可以通過限制會議人數(shù)，在確認的人數(shù)基礎(chǔ)上增加帶寬，設(shè)置I-frame控制丟包，針對流媒體支持，支持WebRTC的前向糾錯（FEC），通過WebRTC客戶端支持圖像質(zhì)量特征設(shè)置支持。為了完全實現(xiàn)視頻會議的拓展和HA服務，幾乎所有開源的WebRTC視頻服務器或者媒體服務器都可以通過不同的方式實現(xiàn)拓展。以下就是一個Jitsi實現(xiàn)級聯(lián)的技術(shù)架構(gòu)示例，通過Jitsi會議橋來創(chuàng)建不同的拓展和HA高可靠性部署。

　　當然，這種級聯(lián)部署方式仍然可能會出現(xiàn)其他的問題，比如，會議人員的地理位置的不確定導致的數(shù)據(jù)交互延時，還有丟包問題，RTP媒體流延遲，TURN服務器解析DNS的延遲。在以下示例中，Jitsi的jicofo作為信令服務器和jvb（jitsi-videobridge） 媒體服務器進行拓展交互，這樣可以達到最佳優(yōu)化效果。

　　除了在平臺進行拓展處理以外，底層服務器端也可能需要進行優(yōu)化拓展。

　　在WebRTC的視頻會議或者媒體服務器端，一個非常消耗CPU資源的處理就是編碼轉(zhuǎn)換。為了保證媒體服務器的穩(wěn)定性和可拓展性，一些WebRTC服務器也充分使用了拓展的技術(shù)架構(gòu)，例如kurento的媒體服務器(底層是GStreamer)，然后通過底層的拓展來實現(xiàn)人群跟蹤檢測，車牌識別等具體的業(yè)務場景。在各種WebRTC服務器對比中，Kurento服務器端對各種場景和中間件處理比較靈活。其實，這種特性也是因為Kurento本身特性決定的，應該不能說是它的一個優(yōu)點。Kurento本身的設(shè)計初衷就是支持不同媒體服務器場景的，因此相對比較靈活，其他的幾個媒體服務器更多側(cè)重于視頻會議一種業(yè)務，沒有其他的場景支持，因此也沒有kurento設(shè)計的那么靈活。

　　Kurento支持了多種非常具體的業(yè)務場景，包括人臉識別，車牌識別（支持IP攝像頭），物體跟蹤，人群監(jiān)控等場景，因此對中間件支持比較豐富，也支持了多種編碼格式和編碼轉(zhuǎn)換的處理。

　　根據(jù)研究人員Boni García在關(guān)于Kurento 的WebRTC 媒體服務器的論文中的總結(jié)，如果需要拓展媒體服務器的話，基于kurento的WebRTC服務器可以通過橫向增加服務器數(shù)量, 如果是云平臺的話增加實例，CPU，內(nèi)存來實現(xiàn)媒體服務器的拓展。具體的拓展方式以及其靈活性取決于WebRTC服務器的設(shè)計架構(gòu)，讀者可以參考此討論來進行學習。關(guān)于kurento的背景介紹，讀者可以參考以前的文章：

　　kurento-開源WebRTC服務器-”一個半死不活"的開源項目

　　Scalelite是開源的均衡負載項目，它支持了BigBlueButto（BBB）的技術(shù)架構(gòu)，通過界面可以配置

　　Scalelite支持的BBB均衡負載技術(shù)架構(gòu)

　　它可以實現(xiàn)數(shù)據(jù)庫，Scalelite Server，Redis Cache 服務器。錄像/錄音共享，通過媒體服務器BBB拓展可以實現(xiàn)更多會議人數(shù)。

　　在前面的章節(jié)中，我們討論了關(guān)于級聯(lián)的技術(shù)架構(gòu)HA處理方式的不同，還有媒體服務器拓展的方式。這些拓展的技術(shù)架構(gòu)都是為了保證其WebRTC服務器的穩(wěn)定性，那么，如何針對WebRTC服務器進行穩(wěn)定性測試呢？其實，市場上和開源社區(qū)也提供了一些非常有效的測試工具，可以幫助用戶從不同角度來測試WebRTC服務器端的一些性能，以下是目前幾個主流的WebRTC 服務器測試工具：

　　筆者在前面討論了幾個關(guān)于WebRTC的性能的重要指標以及相關(guān)的測試工具。但是，如果我們看一些測試分享時，我們?nèi)匀话l(fā)現(xiàn)，測試人員進行的測試都是從不同的角度進行的。事實上，業(yè)內(nèi)很多研究人員以及提出了比較完整的WebRTC測試技術(shù)架構(gòu)，測試人員可以從這個技術(shù)架構(gòu)中選擇不同的角度進行測試。Boni García發(fā)布了關(guān)于WebRTC 測試的挑戰(zhàn)和實踐解決辦法，如果讀者計劃對WebRTC進行測試的話，可以參考這個測試架構(gòu)進行測試。

　　WebRTC 測試技術(shù)架構(gòu)

　　在實際的測試數(shù)據(jù)中，測試結(jié)果以及相關(guān)測試包括網(wǎng)絡(luò)帶寬的結(jié)果影響參數(shù)（編碼類型，分辨率，F(xiàn)rame rate，圖像大小，呼叫量），用戶人數(shù)，呼叫創(chuàng)建耗時，瀏覽器類型，媒體服務器類型（MCU/SFU），平臺部署方式（容器/虛擬機/云平臺，服務器IO/網(wǎng)絡(luò)帶寬），時延，視頻質(zhì)量等對比，CPU消耗，內(nèi)存消耗，QoS/QoE。Muhammad Shahid在他們團隊的論文中討論了關(guān)于視頻會議QoS和QoE的相關(guān)測試參數(shù)，在進行測試時也需要按照這些參數(shù)對比測試。

　　下面，筆者分享一些不同測試結(jié)果，讀者通過這些結(jié)果可以基本上了解相關(guān)WebRTC性能以及完整的相關(guān)要素，這些數(shù)據(jù)具有一定的參考意義。

　　瀏覽器是WebRTC呼叫中非常敏感的終端，很多WebRTC功能經(jīng)常受限于瀏覽器的版本。WebRTC應用環(huán)境中，使用不同瀏覽器實現(xiàn)的信令創(chuàng)建結(jié)果。

　

　　

　　臉部識別的CPU消耗


　　內(nèi)存消耗

　

　　存儲設(shè)備使用情況

　

　　網(wǎng)絡(luò)帶寬使用情況

　　

　　http://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras

　　Sajjad Taheri發(fā)布了關(guān)于針對WebRTC性能測試的基礎(chǔ)測試方法，他不同終端環(huán)境下WebRTC呼叫初始時間，ICE創(chuàng)建時間等做了非常深入的研究調(diào)查。這也是很多WebRTC用戶經(jīng)常會遇到的問題，為什么WebRTC呼叫時間總是很長的一個合理的解釋。

　　關(guān)于ICE創(chuàng)建/offer/answer時間

　

　　不同網(wǎng)絡(luò)環(huán)境中ICE打洞時間耗費

　　

　　不同終端VP8編碼解碼渲染執(zhí)行情況

　　

　　Emmanuel Andr?e針對不同開源WebRTC 媒體服務器SFU模式下的對比測試，包括了加載不同數(shù)量的用戶進行測試，傳輸結(jié)果，時延和視頻效果評價得出來不同的測試結(jié)果。

　　Transmission bit rates （Jitsi，Janus，Medooze，Kurento和Mediasoup）結(jié)果

　　

　

　　

　

　　WebRTC媒體服務器可以部署在物理機，也可以部署在虛擬機容器。這些不同平臺針對WebRTC服務器的性能有不同的影響。研究人員針對容器和虛擬機（KVM）上進行了WebRTC媒體服務器的性能測試。使用的WebRTC媒體服務器是Kurento Media Server (KMS）。測試架構(gòu)如下：

　

　　根據(jù)此研究人員的測試，容器的整體性能優(yōu)于KVM，特別是實時通信應用中時延的處理比KVM表現(xiàn)要好。

　　

　　針對具體的WebRTC視頻會議服務器性能測試中，Jitsi的測試相對比較多，測試參數(shù)有非常具體。Boris Grozev 和 Emil Ivov根據(jù)以下幾個指標對Jitsi進行了測試評估（每秒中進行的測試參數(shù)變量）

　　1056語音/視頻占用50Mbps帶寬

 

　　1056語音/視頻消耗20%CPU

　　其他語音/視頻終端加載的帶寬和CPU消耗狀態(tài)

　　關(guān)于針對視頻會議QoE的研究是一個非常重要的技術(shù)領(lǐng)域，有的研究論文針對H264高分辨率的研究，有的針對解碼算法進行研究，還有的針對視頻質(zhì)量和壓縮進行研究。這些視頻會議的算法研究都對QoE有非常大的影響。很多關(guān)于QoE評價方法，讀者有興趣的話，可以進行進一步研究。

　　常用的關(guān)于QoS和QoE評價方式中的參數(shù)

 

　　如果用戶需要進行測試的話，在有限資源條件下盡量采用比較常用的參數(shù)，例如抖動，時延，帶寬和丟包測試。這里，我們分享Ahmad Vakili的關(guān)于QoE和Frame Rate，壓縮比，Bit Rate以及帶寬預估的研究結(jié)果。

　　

　　

　　

　　WebRTC視頻會議可以使用不同的視頻編碼，目前使用最多的三種編碼中，它們都有各自的特點，特別是在網(wǎng)絡(luò)擁塞或者網(wǎng)絡(luò)帶寬有限時，它們的表現(xiàn)都不同。在720P測試環(huán)境下，三種視頻編碼的不同表現(xiàn)。H264相對VP8和V9，在帶寬有限時，它會產(chǎn)生更大的延遲，同時在分辨率不同的環(huán)境下，H264相對支持表現(xiàn)比較差。

　　在WebRTC視頻會議使用環(huán)境中，CPU和帶寬是非常重要的參數(shù)（內(nèi)存相對不太敏感），這兩個參數(shù)會直接影響視頻的質(zhì)量。以下是一個視頻會議測試中，使用SFU模式，不同帶寬環(huán)境下的視頻質(zhì)量表現(xiàn)（使用VP8編碼）。

　　設(shè)置為 low quality時的結(jié)果：

　　設(shè)置為high quality時的結(jié)果：

　　

　　不同quality的jitter buffer delay結(jié)果

　　

　　在本文章介紹中，筆者主要分享了關(guān)于基于WebRTC的媒體服務器和視頻會議的介紹。首先，筆者介紹了分享了關(guān)于WebRTC性能的一些重要指標，然后介紹了關(guān)于WebRTC目前研究的比較新的研究成果，影響WebRTC服務器執(zhí)行的幾個要素，關(guān)于視頻會議畫面布局帶來的影響，接下來，筆者介紹了關(guān)于WebRTC測試的幾個主要工具，最后筆者和讀者分享了WebRTC的測試架構(gòu)，以及不同研究人員針對不同環(huán)境和不同角度進行的WebRTC的測試和相關(guān)性能報告。

　　雖然，筆者盡可能完整介紹了關(guān)于WebRTC服務器端性能測試的一些數(shù)據(jù)，但是，因為資源有限，我們?nèi)鄙籴槍�STUN和TURN的測試報告，也缺少基于App端的測試報告，還缺少關(guān)于WebRTC各種開源終端的測試報告。希望以后有機會能夠獲得更多資源來和讀者分享。

　　再次說明，如果讀者有興趣對某些數(shù)據(jù)或者測試手段進行進一步研究的話，建議讀者閱讀完整的論文原文和其相關(guān)研究論文。