WebRTC 的三個「陷阱」

歡迎訪問 RTC 開發者社區，與更多WebRTC開發者交流經驗。 

WebRTC是一個可使咱們在瀏覽器或移動App中直接進行音頻/視頻交流的技術，例如Google Hangouts、Facebook Messenger 和Discord。另外，它還能夠進行P2P文件共享，處理大量音頻數據，實如今線視頻會議等等，可是當咱們到達WebRTC的底層時，事情變得複雜起來。

關於咱們WebRTC APP的故事起始於2018年2月份，形象地來講，一個叫 Redacted 的人在開會時想要咱們實現一個具備 redacted 特性的 redacted APP。你能夠將它理解爲實時視頻交流。

陷阱1：不理解WebRTC技術。

起初，咱們對WebRTC沒有任何實際經驗。儘管2011年就發佈了WebRTC,可是它的想法包含了許多已經創建的領域，例如VoIP交流，網站開發， 視頻流等等。

可是WebRTC是一種新技術，它在瀏覽器中的實現常常變化，你所瞭解的WebRTC信息常常有多是過期或者錯誤的。

所以個人建議是在你開發App以前充分了解WebRTC：
1.你應該瞭解關於你必須用來開發WebRTC App的服務器的一切.
2.學習創建點對點鏈接的發信過程。
3.明確媒體是如何處理傳輸的。
4.有必要時諮詢專家。

你頗有可能高估了你對此項技術的瞭解。另外一方面，實現你本身的解決方案須要更多的投資和持久的努力。所以，若是你的資金或時間不足，使用WebRTC平臺會更好。

陷阱2：選擇了錯誤的library

在查找了一些已經實現好WebRTC鏈接的方案以後，咱們選擇了PeerJS.

Library是GitHub關於WebRTC目錄裏最引人注目的一個。它獲得了類似項目開發者大量的積極反饋。

使用PeerJS實現WebRTC會使咱們致力於邏輯層應用，而不會將咱們拉進網絡協議之中。

這個Library甚至包含本身對於發信服務器的實現。

聽起來是否是很棒？

請注意：最後一條評論是在3年前。

你不能使用這樣一個過期的library來進行WebRTC項目。WebRTC的發展速度很是快。

任何在幾個月以前發佈的技術已通過時了，任何在一年前發佈的技術已經接近死亡了。

在建立一個快速PeerJS模型後，咱們在不一樣的瀏覽器中測試它。結果是，不是全部瀏覽器支持咱們的方案。

如下是關於WebRTC 瀏覽器支持的官方表格。

可是實際上看起來不太同樣。Google Chrome/Chromium具備更好的鏈接。同時，Edge,Safari, Firefox在Linux上不能創建並保持鏈接。所以，哪一個瀏覽器真正支持WebRTC?

即便咱們基於PeerJS的方案在將來效果不錯，這也不能確保它能在更新以後還能在全部現代瀏覽器中持續可靠的工做。

最後，咱們決定使用另外一個library.

咱們的研究將咱們引到了這兩個dozen的library，它們能夠用來進行WebRTC項目。然而，在全部的候選者裏，只有SimpleWebRTC和EasyRTC符合咱們全部的標準。

如下是在選擇一個library時你應該考慮的事：

項目是否依然存活

尋找最近幾個月更新的library。一年以前的代碼可能根本不起做用。一樣，瞭解更新內容和間隔。

是否具備高質量文件。

不一樣WebRTC library的文件差異很大。標準應該是具備library組成和結構的簡介，一個API參考，對暴露出來的屬性和方法進行解釋，項目的使用場景，關於如何安裝，保持並擴展解決方案的信息。

一個高質量的文件將會節省咱們和開發者不少時間。它還能幫你更好理解你經過它能夠實現什麼。
是否瞭解library的代碼而且能夠本身維護。

這與第一個陷阱契合。好的library會具備代碼實際使用的信息。這將會使得對代碼的維護更簡單。

是否在開發者中流行

具備一個活躍的社羣和來自開發者的支持說明你應該把注意力放在它上面。流行也意味着你能夠輕易找到答案，僱到人來進行項目。

這個library是脫機使用仍是要基於主機

若是是基於host的，你並不能控制開發者服務器中的部分。脫機library，容許你控制WebRTC實現中的每一方面。

是否具備後端實現？

這將會爲你節省不少時間，可是糟糕的是，只有少數library包括了server.

最後，是否可配置？

陷阱3： 使用公有 STUN/ TURN 服務器。

既然咱們已經關注了瀏覽器兼容性問題，另外一個問題變得應該優先考慮。任何在本地網絡中工做正常的部分。可是當咱們試圖跨越防火牆時，鏈接變得不可靠。

咱們發現鏈接的常常中斷緣由是咱們項目使用的 STUN/ TURN服務器。

可是難道我沒說WebRTC總體上是P2P而且不須要服務器麼？

好吧，這是理論上。實際中，狀況更復雜。

讓咱們考慮一下你想更新Redacted。可是爲了創建與Redacted的P2P鏈接，首先須要一個WebRTC App來定位它。

若是是正常的網站和服務器，你將會經過DNS服務器收到它們的IP地址。

可是redacted不是一個服務器，你不能獲得它的IP地址。

大多數電腦沒有公共IP。你的‘朋友’可能經過頂級保密LAN來上網，他實際的IP唄隱藏在防火牆內，和NAT設備中。這些設備將他的內部IP指向可用的公共IP。即便是redacted也不必定知道他的外部IP。

一種發現他的IP，並讓他知道向哪裏發送響應的方法是使用 STUN服務器。

當創建點對點鏈接時，首先你須要 STUN服務器來揭示公共IP。以後，你能夠告訴朋友如何與你鏈接。他反過來也會作一樣的事情。

既然大家互相知道了對方的IP，你能夠創建P2P鏈接。

可是發現對方IP僅僅是發信過程中的一小步。

它包括髮現網絡，NAT穿透，創建管理session，確保交流頻道安全，處理錯誤等等。

可是有時NAT設備和防火牆不容許你創建P2P鏈接。

此時，須要使用 TURN服務器來在兩個瀏覽器間傳輸數據。

在WebRTC中，當標準方案失敗後，使用 TURN服務器是最後一個求助方案。

當使用 TURN服務器時，瀏覽器不須要知道如何與對方進行連接併發送信息。它們只須要知道中間使用哪一個 TURN服務器。

爲了更好的用戶體驗，你的 TURN服務器應該很強大，具備大帶寬，能夠處理大量數據。

最後，咱們須要創建本身的服務器。如今咱們關心鏈接的問題。

因此爲了不相同的錯誤，你應該知道關於 STUN/ TURN服務器的哪些信息呢？
1.儘管不使用任何服務器來進行P2P鏈接是可能的，可是實際項目中須要它們來獲得可靠的鏈接。
2.永遠不要寄但願於 STUN（尤爲是 TURN）服務器。
3.有了 STUN服務器你不須要一個極其強大的機器。咱們的估測代表一個視頻通話會增長10Kb發信傳輸。
4. TURN服務器能夠獨佔資源。對於HD視頻的比特率在2-4Mbps之間。這意味着十分鐘的WebRTC視頻通話會消耗至少150MB。若是用戶平均天天打1000次電話，你使用 TURN服務器轉接10%的話，你天天將會獲得30Gb。沒有人會提供一個對全部人免費的 TURN服務器來處理如此大的傳輸量。

另一件須要考慮的事是 TURN服務器對於用戶位置很是敏感。若是兩個英國的用戶經過西海岸的 TURN服務器通話，延遲將會很明顯的下降通話質量。

這就是爲何若是你有全球用戶，你須要在全球各地有不少 TURN服務器。可是一般3個 TURN服務器和一個 STUN服務器對於WebRTC服務器的創建足夠了。

想了解更多 WebRTC 及相關 RTC 技術乾貨？請關注本週9月7日、8日將在北京長城飯店舉行的 RTC 2018 實時互聯網大會。