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 實時網際網路大會。