Zoom有一個Web客戶端，允許參與者在不下載他們的app的情況下參加會議。打開chrome://webrtc-internals顯示只有g(shù)etUserMedia用于訪問相機(jī)和麥克風(fēng)，但是沒有像WebRTC那樣調(diào)用RTCPeerConnection。這讓我很感興趣-他們沒有使用WebRTC是如何打電話的？
為什么不使用WebRTC？
就像他們的網(wǎng)站上所說的那樣，Zoom和WebRTC的關(guān)系比較復(fù)雜。
JitSi團(tuán)隊最近通過比較質(zhì)量回應(yīng)了這件事。Tsahi Levent Levi也對此發(fā)表了一些有用的評論。因此，讓我們在Chrome中運(yùn)行這種非常有趣的環(huán)境下快速查看這些“優(yōu)秀特性”。
Zoom web客戶端
Chrome網(wǎng)絡(luò)開發(fā)者工具迅速顯示了兩件事：
WebSocket用于數(shù)據(jù)傳輸
這是一些工作人員加載的WebAssembly （wasm） 文件
基于WebSocket的媒體傳輸
基于WebSocket的媒體傳輸整體設(shè)計非常有趣。它使用WebSocket傳輸媒體，這當(dāng)然不是最佳選擇。類似于WebRTC中的Turn/TCP——它會影響傳輸質(zhì)量，并且在很多情況下都不能很好地工作。使用TCP傳輸實時媒體的一般問題是丟包，這會導(dǎo)致重新發(fā)送和增加延遲。Tsahi前一段時間在TestRTC上描述了這一點(diǎn)，顯示了使用這種方案對比特率和其他特性的影響。
基于WebSocket傳輸媒體最主要的優(yōu)勢在于，它可以在TURN/TCP和TURN/TLS被防火墻阻塞時，穿過防火墻。它避免了WebRTC TRUN連接不經(jīng)過認(rèn)證代理的問題。這是Chrome WebRTC實施中長期存在的問題，去年才得到解決。
在WebSocket上接收的數(shù)據(jù)進(jìn)入基于WebAssembly （WASM）的解碼器。瀏覽器中的AudioWrkLead獲取到音頻數(shù)據(jù)。從那里，解碼的音頻使用WebAudio“magic”目的節(jié)點(diǎn)播放。
視頻被渲染出來，這個過程出乎意料的順利，質(zhì)量也非常高。
另一方面，WebAudio通過getUserMedia調(diào)用捕獲媒體數(shù)據(jù)，發(fā)送給WebAssembly編碼器編碼，然后通過WebSocket傳輸。640*360分辨率的視頻數(shù)據(jù)在發(fā)送給WebAssembly編碼器之前從畫布中獲取到，這是非常常見的。
WASM文件似乎包含與Zooms本地客戶端相同的編碼器和解碼器，這意味著網(wǎng)關(guān)不必進(jìn)行轉(zhuǎn)碼。相反，它可能只是一個websocet-RTP中繼，類似于轉(zhuǎn)換服務(wù)器。編碼的視頻有時有些像素化。雖然編碼器的CPU使用率相當(dāng)高（在640×360分辨率），但這可能并不重要，因為用戶可能將問題歸咎于Chrome，并在下次使用客戶端。
H.264
使用WebAssembly提供媒體引擎是非常有趣的，它允許支持Chrome／WebRTC不支持的編解碼器。用emscripten編譯的FFmpeg以前已經(jīng)做了很多次了，這里似乎也使用了emscripten。通過WebSockets傳輸編碼后的數(shù)據(jù)，可以使用Chrome優(yōu)秀的調(diào)試工具檢查RTP頭和一些幀來顯示H264荷載。
令我驚訝的是，網(wǎng)絡(luò)抽象層單元（NALU）沒有表示H264-SVC。
和WebRTC的比較：
總之，讓我們比較一下Chrome在本例中使用的與WebRTC標(biāo)準(zhǔn)（W3C或者各種IETF草案）不同的地方：
|
特性 |
Zoom Web client |
WebRTC/RTCWeb Specifications |
|
加密 |
基于安全Websocket的RTP |
DTLS-SRTP |
|
數(shù)據(jù)通道 |
n/a? |
SCTP-based |
|
ICE |
n/a for Websocket |
RFC 5245 (RFC 8445) |
|
Audio codec |
未知 |
Opus |
|
多碼流 |
未研究 |
Chrome實現(xiàn) |
|
Simulcast |
在web client上未研究 |
擴(kuò)展特性 |
WebRTC下一版
盡管WebRTC 1.0還遠(yuǎn)遠(yuǎn)沒有完成（而且大多數(shù)開發(fā)人員仍在使用被稱為“遺留API”的東西），但是關(guān)于“下一個版本”的討論仍然很多。
Zoom網(wǎng)絡(luò)客戶端的總體設(shè)計強(qiáng)烈地提醒了我，在今年早些時候在斯德哥爾摩召開的工作組面對面會議上，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)采取了類似的方法來分離組件�；旧喜扇∫韵虏襟E：
- 編譯用于wasm的webrtc.org編碼器/解碼器。
- 將解碼器與畫布連接，WebAudio用于”布局”
- 將編碼器和getUserMedia連接用于輸入
- 將編碼后的數(shù)據(jù)通過不可靠的信道發(fā)送
- 以某種方式連接RTCDataChannel反饋度量和音頻/視頻編碼器
該方法是從工作組會議幻燈片中看到的：
與Zoom方法相比，該方案具有非常明顯的技術(shù)優(yōu)勢。例如，使用RTCDataChannels傳輸數(shù)據(jù)，這比WebSocket具有更好的擁塞控制特性，特別是當(dāng)存在分組丟失時。
該設(shè)計的最大優(yōu)點(diǎn)是可以將編碼器和解碼器（以及相關(guān)的東西，如RTP打包）與瀏覽器分離，從而允許定制版本。主要問題是找到一種好的方法，以包括硬件加速的高性能方式使數(shù)據(jù)處理脫離主線程。這是Chrome早期面臨的一大挑戰(zhàn)，我記得很多關(guān)于沙箱讓事情變得困難的抱怨。Zoom看起來很好，但是我們只嘗試了1:1的聊天，而典型的WebRTC應(yīng)用程序比這個要求更高一些。重用像MediaStreamTrack這樣的構(gòu)建塊來進(jìn)行從工人到工人的數(shù)據(jù)傳輸也比使用Canvas元素和WebAudio要好。
原文 https://webrtchacks.com/zoom-avoids-using-webrtc/
