Zoom的Web客戶(hù)端與WebRTC有何不同？

　　Zoom有一個(gè)Web客戶(hù)端，允許參與者在不下載他們的app的情況下參加會(huì )議。打開(kāi)chrome://webrtc-internals顯示只有g(shù)etUserMedia用于訪(fǎng)問(wèn)相機和麥克風(fēng)，但是沒(méi)有像WebRTC那樣調用RTCPeerConnection。這讓我很感興趣-他們沒(méi)有使用WebRTC是如何打電話(huà)的？

　　就像他們的網(wǎng)站上所說(shuō)的那樣，Zoom和WebRTC的關(guān)系比較復雜。

　　JitSi團隊最近通過(guò)比較質(zhì)量回應了這件事。Tsahi Levent Levi也對此發(fā)表了一些有用的評論。因此，讓我們在Chrome中運行這種非常有趣的環(huán)境下快速查看這些“優(yōu)秀特性”。

　　Zoom web客戶(hù)端

　　Chrome網(wǎng)絡(luò )開(kāi)發(fā)者工具迅速顯示了兩件事：

　　WebSocket用于數據傳輸

　　這是一些工作人員加載的WebAssembly （wasm） 文件

　　基于WebSocket的媒體傳輸整體設計非常有趣。它使用WebSocket傳輸媒體，這當然不是最佳選擇。類(lèi)似于WebRTC中的Turn/TCP——它會(huì )影響傳輸質(zhì)量，并且在很多情況下都不能很好地工作。使用TCP傳輸實(shí)時(shí)媒體的一般問(wèn)題是丟包，這會(huì )導致重新發(fā)送和增加延遲。Tsahi前一段時(shí)間在TestRTC上描述了這一點(diǎn)，顯示了使用這種方案對比特率和其他特性的影響。

　　基于WebSocket傳輸媒體最主要的優(yōu)勢在于，它可以在TURN/TCP和TURN/TLS被防火墻阻塞時(shí)，穿過(guò)防火墻。它避免了WebRTC TRUN連接不經(jīng)過(guò)認證代理的問(wèn)題。這是Chrome WebRTC實(shí)施中長(cháng)期存在的問(wèn)題，去年才得到解決。

　　在WebSocket上接收的數據進(jìn)入基于WebAssembly （WASM）的解碼器。瀏覽器中的AudioWrkLead獲取到音頻數據。從那里，解碼的音頻使用WebAudio“magic”目的節點(diǎn)播放。

　　視頻被渲染出來(lái)，這個(gè)過(guò)程出乎意料的順利，質(zhì)量也非常高。

　　另一方面，WebAudio通過(guò)getUserMedia調用捕獲媒體數據，發(fā)送給WebAssembly編碼器編碼，然后通過(guò)WebSocket傳輸。640*360分辨率的視頻數據在發(fā)送給WebAssembly編碼器之前從畫(huà)布中獲取到，這是非常常見(jiàn)的。

　　WASM文件似乎包含與Zooms本地客戶(hù)端相同的編碼器和解碼器，這意味著(zhù)網(wǎng)關(guān)不必進(jìn)行轉碼。相反，它可能只是一個(gè)websocet-RTP中繼，類(lèi)似于轉換服務(wù)器。編碼的視頻有時(shí)有些像素化。雖然編碼器的CPU使用率相當高（在640×360分辨率），但這可能并不重要，因為用戶(hù)可能將問(wèn)題歸咎于Chrome，并在下次使用客戶(hù)端。

　　H.264

　　使用WebAssembly提供媒體引擎是非常有趣的，它允許支持Chrome／WebRTC不支持的編解碼器。用emscripten編譯的FFmpeg以前已經(jīng)做了很多次了，這里似乎也使用了emscripten。通過(guò)WebSockets傳輸編碼后的數據，可以使用Chrome優(yōu)秀的調試工具檢查RTP頭和一些幀來(lái)顯示H264荷載。

　　

　　令我驚訝的是，網(wǎng)絡(luò )抽象層單元（NALU）沒(méi)有表示H264-SVC。

　　總之，讓我們比較一下Chrome在本例中使用的與WebRTC標準（W3C或者各種IETF草案）不同的地方：

　　盡管WebRTC 1.0還遠遠沒(méi)有完成（而且大多數開(kāi)發(fā)人員仍在使用被稱(chēng)為“遺留API”的東西），但是關(guān)于“下一個(gè)版本”的討論仍然很多。

　　Zoom網(wǎng)絡(luò )客戶(hù)端的總體設計強烈地提醒了我，在今年早些時(shí)候在斯德哥爾摩召開(kāi)的工作組面對面會(huì )議上，Google的Peter Thatcher為WebRTC NV提出的建議。請參閱幻燈片（https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf）。

　　如果我們要在2018重建WebRTC，我們可能已經(jīng)采取了類(lèi)似的方法來(lái)分離組件。基本上采取以下步驟：

　　與Zoom方法相比，該方案具有非常明顯的技術(shù)優(yōu)勢。例如，使用RTCDataChannels傳輸數據，這比WebSocket具有更好的擁塞控制特性，特別是當存在分組丟失時(shí)。

　　該設計的最大優(yōu)點(diǎn)是可以將編碼器和解碼器（以及相關(guān)的東西，如RTP打包）與瀏覽器分離，從而允許定制版本。主要問(wèn)題是找到一種好的方法，以包括硬件加速的高性能方式使數據處理脫離主線(xiàn)程。這是Chrome早期面臨的一大挑戰，我記得很多關(guān)于沙箱讓事情變得困難的抱怨。Zoom看起來(lái)很好，但是我們只嘗試了1:1的聊天，而典型的WebRTC應用程序比這個(gè)要求更高一些。重用像MediaStreamTrack這樣的構建塊來(lái)進(jìn)行從工人到工人的數據傳輸也比使用Canvas元素和WebAudio要好。