在本文章的討論中，筆者準備從幾個不同的方面來介紹WebRTC 服務(wù)器端的性能處理的介紹，具體包括：服務(wù)器端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)之前討論視頻會議的性能是沒有任何意義，這些服務(wù)器可能也不存在任何的可比性。因此，在以下的測試數(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é)合自己的用戶場景做進一步學(xué)習(xí)，這里不再花費時間介紹。如果讀者想了解開源WebRTC媒體服務(wù)器的背景介紹，可以閱讀筆者的歷史文檔：

　　大家都知道，基于互聯(lián)網(wǎng)的產(chǎn)品或者應(yīng)用的性能受制于很多環(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，服務(wù)器端資源占用率，流媒體切換時延等做了非常深度的分析。Cristian Constantin Spoiala針對WebRTC在容器和虛擬機境中針對Kurento做了完整的測試。Vamis Xhagjika???針對WebRTC云部署（MCU/SFU）環(huán)境發(fā)表了一篇關(guān)于WebRTC服務(wù)器的負載和性能測試的模型。這些測試研究都是從不同角度使用各種模型和工具對WebRTC資源和性能做的充分的測試。為我們討論關(guān)于WebRTC 視頻會議服務(wù)器的性能提供了非常完整的概括。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　筆者在前面討論了幾個關(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)建耗時，瀏覽器類型，媒體服務(wù)器類型（MCU/SFU），平臺部署方式（容器/虛擬機/云平臺，服務(wù)器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應(yīng)用環(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 媒體服務(wù)器SFU模式下的對比測試，包括了加載不同數(shù)量的用戶進行測試，傳輸結(jié)果，時延和視頻效果評價得出來不同的測試結(jié)果。

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

　　

　

　　

　

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

　

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

　　

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

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

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