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 实时互联网大会。