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

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

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

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

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

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

　

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

　　

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

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

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

　　連接測試評價(jià)參數

　　

　　媒體處理性能評價(jià)參數

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　WebRTC 測試技術(shù)架構

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

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

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

　

　　

　　臉部識別的CPU消耗


　　內存消耗

　

　　存儲設備使用情況

　

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

　　

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

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

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

　

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

　　

　　不同終端VP8編碼解碼渲染執行情況

　　

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

　　Transmission bit rates （Jitsi，Janus，Medooze，Kurento和Mediasoup）結果

　　

　

　　

　

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

　

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

　　

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

　　1056語(yǔ)音/視頻占用50Mbps帶寬

 

　　1056語(yǔ)音/視頻消耗20%CPU

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

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

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

 

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

　　

　　

　　

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

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

　　設置為 low quality時(shí)的結果：

　　設置為high quality時(shí)的結果：

　　

　　不同quality的jitter buffer delay結果

　　

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

　　雖然，筆者盡可能完整介紹了關(guān)于WebRTC服務(wù)器端性能測試的一些數據，但是，因為資源有限，我們缺少針對STUN和TURN的測試報告，也缺少基于A(yíng)pp端的測試報告，還缺少關(guān)于WebRTC各種開(kāi)源終端的測試報告。希望以后有機會(huì )能夠獲得更多資源來(lái)和讀者分享。

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