首先要注意一個重要的問題——問什么樣的SFU是最好的就像問什么樣的車是最好的。如果你只想快點，那么你應(yīng)該買一輛一級方程式賽車，但這不會幫助你送孩子上學(xué)。供應(yīng)商從不對這些類型的測試感到興奮，因為它把它們的功能歸結(jié)為幾個性能指標(biāo)。這些指標(biāo)可能不是其設(shè)計標(biāo)準(zhǔn)的主要部分，而且很多時候他們并不是那么重要。特別是對于WebRTC SFU，因為您可以在SFU上加載很多流，所以可能存在有許多彈性，用戶行為和成本優(yōu)化的原因。負(fù)載測試也不會深入研究端到端用戶體驗、開發(fā)的易用性，或者所有其他能夠成功實現(xiàn)服務(wù)的功能元素。最后，像這樣發(fā)表的報告代表了一個時間點——這些系統(tǒng)一直在改進(jìn)，所以今天的結(jié)果可能會更好。

　　在discussion-webrtc郵件列表上的一個反復(fù)出現(xiàn)的問題是“什么是最好的SFU”。這總是會產(chǎn)生來自各個SFU供應(yīng)商和團(tuán)隊的響應(yīng)。顯然，它們不可能同時是正確的！

　　你可以在這里檢查整個線程。Chad Hart隨后帶著對話友好地回答了這個問題，并表示需要：

　　在任何情況下，我認(rèn)為我們需要全局（同樣適用于所有）可重現(xiàn)且無偏見（可用的源代碼，并且每個供應(yīng)商可以根據(jù)需要調(diào)整其安裝）基準(zhǔn)，以獲得多個可伸縮性指標(biāo)。

　　三年后，我和我的團(tuán)隊建立了這樣一個基準(zhǔn)系統(tǒng)。我將解釋這個系統(tǒng)是如何工作的，并在下面展示我們的一些初步結(jié)果。

　　一些SFU供應(yīng)商提供負(fù)載測試工具。Janus有Jattack。Jitsi有jitsi-hammer，甚至發(fā)表了他們的一些研究成果。Jitsi尤其在透明度方面做了大量工作，提供了可靠的數(shù)據(jù)和足夠的信息來重現(xiàn)結(jié)果。然而，并不是所有的供應(yīng)商都有這些工此外，每個工具都旨在為自己的環(huán)境回答略有不同的問題，例如：

　　沒有辦法進(jìn)行真正的比較研究——一個獨立可重復(fù)且無偏見的研究。這種固有的模糊性也為一些人的一些令人不快的行為打開了大門，他們意識到自己可以逃避任何索賠，因為沒有人能真正檢查他們。我們想要產(chǎn)生一些結(jié)果，人們不需要承擔(dān)責(zé)任，可以通過同行評議。

　　要想對“什么是最好的SFU？”有一個很好的答案，你需要解釋你打算用它做什么。

　　我們選擇研究似乎最受關(guān)注的兩個用例，或者至少是那些在discuss-webrtc上產(chǎn)生最多流量的用例：

　　大多數(shù)視頻會議問題都集中在單個服務(wù)器實例上。在給定的會議中有20多人通常是很多人。相關(guān)研究表明，在大多數(shù)社交案例中，大多數(shù)呼叫都是1-1，平均值大約為3.這種配置非常適合任何公共云提供商中的一個小型實例（只要你獲得1Gbps NIC ）。然后，您可以使用非常簡單的負(fù)載平衡和水平可伸縮性技術(shù)，因為發(fā)送者與觀看者的比例很少。另一方面，媒體流通常涉及從單個源流向成千上萬的觀眾。這需要多服務(wù)器層次結(jié)構(gòu)。

　　我們希望適應(yīng)不同的測試場景，并在幾個WebRTC服務(wù)器上以相同的方式實現(xiàn)它們，這樣唯一的區(qū)別就是所測試的系統(tǒng)，并且結(jié)果不會有偏差。

　　在與谷歌和其他許多公司的合作下，我們開發(fā)了KITE，這是一個測試引擎，它可以讓我們輕松地支持各種客戶端——瀏覽器和跨移動或桌面的本機(jī)客戶端——以及各種測試場景。它被用來測試WebRTC的實現(xiàn)，每天都在不同的瀏覽器上運行。

　　負(fù)載測試通常使用單個客戶機(jī)來控制客戶機(jī)的影響。理想情況下，您可以在單個虛擬機(jī)中并行運行測試客戶機(jī)的多個實例。由于這是WebRTC，所以使用其中一個瀏覽器是有意義的。Edge和Safari只局限于一個進(jìn)程，這并不使它們非常適合。此外，Safari只運行MacOS或iOS，而iOS只在蘋果硬件上運行。如果運行的是Windows或Linux，那么在AWS上生成100萬個虛機(jī)相對比較容易。要安裝100萬臺Mac、iPhone或iPad進(jìn)行測試，難度和成本都要大得多。

　　這樣你就有了Chrome或Firefox，可以同時運行多個實例。我們認(rèn)為Chrome的webdriver實現(xiàn)更容易管理，需要處理的標(biāo)志和插件更少（比如H264），所以我們選擇使用Chrome。

　　我們測試了以下SFU：

　　為了確保每個SFU都顯示出最佳結(jié)果，我們聯(lián)系了每個項目背后的團(tuán)隊。我們提議讓他們自己設(shè)置服務(wù)器或連接到服務(wù)器并檢查他們的設(shè)置。我們也分享了結(jié)果，以便他們發(fā)表評論。這確保我們正確配置每個系統(tǒng)以便為我們的測試提供最佳處理。有趣的是，在這項研究的過程中，我們發(fā)現(xiàn)了一些bug，并與團(tuán)隊一起改進(jìn)了他們的解決方案。這將在最后一節(jié)中詳細(xì)討論。

　　我們使用以下方法將流量增加到高負(fù)載。首先，我們在每個視頻會議室中每次只使用一個用戶，直到用戶總數(shù)達(dá)到7個。我們重復(fù)這個過程，直到達(dá)到目標(biāo)用戶總數(shù)。接近500個同步用戶。

　　下圖顯示了測試平臺中的元素：

　　大多數(shù)對可伸縮性問題感興趣的人都會在“負(fù)載”（流、用戶、房間…）增加時測量服務(wù)器的CPU、RAM和帶寬占用。這是一種傳統(tǒng)的方法，它假設(shè)流的質(zhì)量、比特率都保持不變。

　　WebRTC的編碼引擎使得這個問題更加復(fù)雜。WebRTC包括帶寬估計、比特率適應(yīng)和總體擁塞控制機(jī)制，不能假定在整個實驗過程中流將保持不變。除了通常的指標(biāo)之外，測試人員還需要記錄客戶端指標(biāo)，比如發(fā)送的比特率、帶寬估計結(jié)果和延遲。關(guān)注視頻質(zhì)量也很重要，因為它可能會在CPU、RAM和/或服務(wù)器帶寬飽和之前下降。

　　在服務(wù)器端測量不同的度量標(biāo)準(zhǔn)就像自己匯集getStats API或集成callstats.io之類的解決方案一樣簡單。在我們的例子中，我們衡量：

　　由于篇幅限制，上述指標(biāo)未在科學(xué)文章中發(fā)布，但應(yīng)在隨后的研究報告中發(fā)布。除視頻質(zhì)量外，所有這些指標(biāo)都很容易制作和測量。什么是視頻質(zhì)量的客觀衡量標(biāo)準(zhǔn)？存在幾種視頻質(zhì)量代理，例如Google渲染時間，接收幀數(shù)，帶寬使用情況，但這些代理都沒有給出準(zhǔn)確的測量結(jié)果。

　　理想情況下，當(dāng)存在缺陷時，視頻質(zhì)量指標(biāo)在視覺上是顯而易見的。這將使我們能夠衡量彈性技術(shù)的相對好處，例如彈性視頻編碼（SVC），從概念上講，輸出視頻與抖動、丟包等編碼方法的相關(guān)性較弱。有關(guān)視覺比較的一個很好的例子，請參閱Agora的以下視頻：

　　https://www.youtube.com/watch?v=M71uov3OMfk

　　在快速研究了一種自動化這種視覺質(zhì)量測量的方法后，我們意識到?jīng)]有人開發(fā)出一種評估視頻質(zhì)量的方法，在沒有實時流的參考媒體的情況下。因此，我們繼續(xù)開發(fā)我們自己的度量，利用神經(jīng)網(wǎng)絡(luò)來利用機(jī)器學(xué)習(xí)。這使得實時的視頻質(zhì)量評估成為可能。另一個好處是，它可以在不記錄客戶媒體的情況下使用，這有時是一個法律或隱私問題。

　　此機(jī)制的細(xì)節(jié)超出了本文的范圍，但您可以在此處閱讀有關(guān)視頻質(zhì)量算法的更多信息。這種基于AI的算法的細(xì)節(jié)已經(jīng)提交出版，一旦被接受就會公開。

　　我們使用從他們各自的公共GitHub存儲庫下載的最新源代碼（使用Docker容器的Kurento / OpenVidu除外）設(shè)置了以下五個開源WebRTC SFU：

　　每個都是在一個單獨但相同的虛擬機(jī)中設(shè)置并使用默認(rèn)配置。

　　首先是一些免責(zé)聲明。所有團(tuán)隊都看到并評論了他們的SFU的結(jié)果。Kurento媒體服務(wù)器團(tuán)隊意識到他們的服務(wù)器目前正在崩潰的早期，我們和他們一起工作來解決這個問題。在Kurento / OpenVidu上，我們測試了最多140個流（因為它很早就崩潰了）。

　　此外，libnice中存在一個已知的bug，它在我們的初始測試期間影響了Kurento / OpenVidu和Janus。按照J(rèn)anus團(tuán)隊的建議應(yīng)用libnice補(bǔ)丁后，他們的結(jié)果顯著改善。但是，使用Kurento / OpenVidu上的補(bǔ)丁進(jìn)行重新測試實際上更加糟糕。我們的結(jié)論是Kurento還有其他問題。我們正在與他們聯(lián)系并致力于解決方案，因此，Kurento / OpenVidu的結(jié)果可能會很快得到改善。

　　最新版本的Jitsi Videobridge（到本文發(fā)表時為止）在240個用戶時總是變得不穩(wěn)定。Jitsi團(tuán)隊已經(jīng)意識到了這一點并正在解決這個問題。但是，他們指出，他們的一般建議是依賴于使用此處描述的大量較小實例的水平擴(kuò)展。請注意，以前的版本（如兩個月前的版本）沒有這些穩(wěn)定性問題，但表現(xiàn)不佳（請參閱下一節(jié)中的更多內(nèi)容）。我們選擇保留0.1.1077版本，因為它包含使simulcast更好，并顯著改善了結(jié)果。

　　另請注意，自測試以來，幾乎所有這些產(chǎn)品都有版本發(fā)布。自從此處顯示的測試結(jié)果以來，一些已經(jīng)做了改進(jìn)

　　作為參考點，我們選擇了一種常用的視頻測試序列，并使用多種視頻質(zhì)量評估指標(biāo)計算其視頻質(zhì)量得分：

　　圖1：基于不同比特率對各種視頻質(zhì)量度量進(jìn)行基準(zhǔn)測試

　　注意，質(zhì)量分?jǐn)?shù)和比特率之間的關(guān)系不是線性的。如果您從參考值（1.7Mbps）開始緩慢地減少帶寬，那么質(zhì)量分?jǐn)?shù)只會略微下降，直到它達(dá)到一個低比特率閾值，然后急劇下降。要降低10%的感知視頻質(zhì)量，需要根據(jù)WMAF將帶寬減少到250Kbps，根據(jù)SSIM將帶寬減少到150k，根據(jù)NARVAL將帶寬減少到100k。

　　對SFU的測試也顯示出同樣的模式。圖2給出了比特率作為每個SFU參與者數(shù)量的函數(shù)。可以看到，WebRTC的擁塞控制算法在早期（大約250名參與者）就開始運行，以保持比特率。然而，圖3顯示了延遲的線性增長。盡管帶寬減少，延遲增加，但是在圖4中顯示的視頻質(zhì)量度量只在帶寬低于200k時報告質(zhì)量下降。這再次表明，比特率和延遲并不是視頻質(zhì)量的好代理。

　　圖2：JItsi在240名參與者失敗。Kurento / OpenVidu很早就遇到了問題。Janus和mediasoup似乎比Medooze更好。它似乎與更好的CPU優(yōu)化有關(guān)，因為拐點與各個CPU的飽和度相關(guān)。

　　圖3：JItsi在240名參與者失敗，Kurento / OpenVidu在50左右出現(xiàn)問題。否則SFU表現(xiàn)出類似的行為。

　　圖4：視頻質(zhì)量僅在實驗結(jié)束時下降，表明擁塞控制機(jī)制正在完成其工作，并設(shè)法做出正確的妥協(xié)，以便在調(diào)整其他參數(shù)的同時保持感知質(zhì)量高。

　　除了上述結(jié)果本身之外，有趣的是，我們可以看到這項研究所引發(fā)的結(jié)果的進(jìn)展。僅僅是提高知名度，就允許各自的團(tuán)隊解決最嚴(yán)重的問題。

　　你也可以觀察到Janus很快就被限制了。他們已經(jīng)在一個外部庫中確定了這個瓶頸，以及一個可能的解決方案，但從未真正評估過真正的影響。我們可以清楚地看到這一節(jié)中的圖（第一次運行）和前一節(jié)中的圖（最新結(jié)果）之間的區(qū)別，Janus似乎表現(xiàn)最好。

　　比特率作為負(fù)載的函數(shù)。

　　之前（左）和之后（右）將補(bǔ)丁應(yīng)用于Janus和Jitsi。我們還添加了mediasoup結(jié)果（綠色）。Medooze和Kurento / OpenVidu結(jié)果在兩個圖中都是相同的，因為第二次沒有更好的結(jié)果。

　　RTT或延遲，作為負(fù)載的函數(shù)（對數(shù)標(biāo)度）。之前（左）和之后（右）將補(bǔ)丁應(yīng)用于Janus和Jitsi。我們還添加了mediasoup結(jié)果（綠色）。Medooze和Kurento / OpenVidu結(jié)果來自同一數(shù)據(jù)集。

　　最后，我們最初文章的一位審稿人指出，CoSMo的雇員塞爾吉奧？加西亞？穆里洛（Sergio Garcia Murillo）的Medooze最終成為了我們研究的重點，暗示了利益沖突可能導(dǎo)致的偏見。我們花了很大的努力來進(jìn)行我們所有的測試，沒有偏見的透明。我認(rèn)為在最新的結(jié)果中看到一些SFUs與Medooze持平或更好，消除了一些人可能有的最后的擔(dān)憂，這是令人振奮的。這對Medooze團(tuán)隊來說也是個好消息——現(xiàn)在他們知道他們要做什么（比如Medooze 0.46的改進(jìn)），他們有了一個工具來衡量他們的進(jìn)展。

　　結(jié)論

　　我們希望我們已經(jīng)證明，由于KITE和CoSMo最近與WebRTC生態(tài)系統(tǒng)的作者合作開發(fā)的一些其他工具，現(xiàn)在相對容易實現(xiàn)對SFU的無偏見的比較測試。我們將繼續(xù)與不同的開源WebRTC SFU供應(yīng)商合作，幫助他們改進(jìn)他們的軟件。我們計劃盡可能多地使用用于生成這些結(jié)果的代碼公開，并且無論如何，以非營利的方式為公共研究人員提供對該工具的訪問。最終，我們希望將這些結(jié)果作為“實時”網(wǎng)頁托管，在新版本的軟件可用時，可以獲得新的結(jié)果。

　　請參閱本周在IIT實時通信會議上展示的論文全文

　　（https://www.cosmosoftware.io/publications/andre2018_Comparative_Study_of_SFUs.pdf）和幻燈片。

　�。╤ttps://www.cosmosoftware.io/publications/andre2018_slides_Comparative_Study_of_SFUs.pdf）摘要。

　　閱讀原文