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