开发WebRTC应用时需要避免的5个错误

作者:Tsahi Levent-Levi(原文链接

翻译:刘通

原标题:5 Mistakes to Avoid When Developing WebRTC Applications

mistakes1

为什么我们从事WebRTC的时候会失败呢?

我不确定聪明人会在WebRTC技术方面比在其他技术中遭遇更多的失败,但确实感觉是这样的。

马克吐温说过,“世界上根本不存在什么新想法。我们只是简单地把许多就想法放进一个精神层面的万花筒里。我们转动万花筒,就会产生出很多新的好奇的组合。我们不断地转动就不会无限期地创造新组合。但是它们的本质就像是经历过各个时代的老旧彩色玻璃一样。”

人们对WebRTC所犯下的许多新手错误都源于此。WebRTC就是这样的新想法。简单的说,很多就想法都融入了一个新奇而好奇的组合中。所以我们了解它。并且我们假设我们知道该如何解决它。

创业者?Skype已经14岁了。所以今天要想做出Skype这样的应用程序应该并不难。

VoIP开发者?我们知道SIP。WebRTC只是没有信令的SIP。所以我们只是把SIP强加在WebRTC之上就应该能解决了。

网页开发者?WebRTC是HTML5的一部分。几行JS代码,我们就准备好可以上线了。

视频开发者?我们可以将WebRTC视频放在CDN上,对吧?

那么结果如何呢?

1. 聪明的人觉得他们的知识足够多,可以单独去做。最终会犯下一些有趣的错误。

2. 人们相信上述那种人,所以只会得到失败的结果

你不再有其他选择了。Flash正在消亡,除了WebRTC之外,你没有其他严肃点的选项了。如果你想采用WebRTC技术,那么这里有五个错误需要避免。

错误1:未能配置STUN / TURN

mistakes2

你不会相信有多少开发者不配置NAT穿越服务器。就在昨天,还有人通过我网站的聊天窗口问我,如何通过在没有任何STUN / TURN服务器的HostGator上托管他的信令和网络服务器来运行他的应用。这根本不可能实现。

简单的答案是,不可能,你一定会需要STUN服务器。对于大多数使用情况,如果你想要连接会话,那么TURN服务器也是必须要有的。

在过去的一个月里,我发现我已经对NAT穿越给出了很多解释:

# 你必须使用STUN和TURN服务器

# 免费的STUN服务器靠不住,更不要使用免费的TURN服务器

# 除非你真的清楚自己在干什么,否则不要强制所有会话都通过TURN

# TURN在使用的时候没有额外的安全性保障

# 你在WebRTC服务器配置中,不需要超过1个的STUN服务器,以及超过3个的TURN服务器(UDP,TCP及TLS)

# 在你的TURN配置中使用临时/短期密码

# STUN不会影响媒体质量

错误2:选择了错误的信令框架

mistakes3

有人听说过PeerJS吗?PeerJS感觉就像一个旅游陷阱:

mistakes4

有1693颗星和499人喜欢,是github上最受欢迎的WebRTC项目之一。能出什么岔子呢?

问题就在它太老了。

mistakes5

一个在3年前提交的WebRTC项目在今天根本不能使用。

有些人使用Muaz Khan的代码片段并期待它们能能为商业级,稳定,高度可扩展的产品。但它们根本做不到这些,它们只是一些有用的代码片段。

准备用一些开源项目?那么请确保:

# 它最近更新过(近几个月)

# 它够火

# 你能够理解框架的代码,并且在有需要的时候能够自己维护

# 尝试确认项目背后有人提供支持,并且在你遇到困难的时候能给你帮助

请不要轻视这些选择过程。

错误3:当你需要的时候却不使用媒体服务器

mistakes6

我知道你在想什么。WebRTC是端到端传输的,所以不需要服务器。有人认为即使信令和网络服务器也是不需要的—那么我希望他们来解释一下会话参与者应该如何找到对方呢?

对于这些人来说,这种端到端的概念也意味着你可以在没有任何媒体服务器的情况下运行这些荒谬的大规模会话。

这里有我遇到过的两种“架构”:

mistakes7

网状结构。这种架构很棒。但不要认为你在今年或者明年就能使其正常运行。所以,下一个。

mistakes8

通过转发内容进行实时广播。这个可以做到,但很可能不是你希望它增长到一百万用户而没有基础架构和零延迟的方式。

对于市面上的很多用例,你需要一个媒体服务器来处理和路由媒体。现在你知道了,那么就去找一个开源媒体服务器或者是商业媒体服务器吧。

错误4:短期思想

mistakes9

你找了一个外包供应商。给他写了一篇特别好的需求文档,付给他钱,得到了一些工作成果,你就大功告成了。

并不是。

WebRTC仍处于起步阶段。规范时刻在改变。浏览器实现也在改变。所以如果你打算使用WebRTC,则可以:

1. 使用WebRTC API平台(这里有一些选择),你就可以少投入一些精力,可能会有一些维护工作,但不会很多。

2. 自行开发或者通过外包开发。在这种情况下,你至少需要在未来3年或者更长的时间内继续投资该项目。

WebRTC代码比大多数其他HTML5代码更容易过时。这点最终会发生改变,但是现在还没有。

错误5:没有理解WebRTC

mistakes10

他们说假设是所有错误的母亲(assumption is the mother of all mistakes),而谷歌也基本同意这个说法。

WebRTC不是微不足道的。它的地位在于VoIP和网络之间。它是一个新技术,所以关于它的信息在网上是分散的,有些则是保持动态的(意味着很多信息并不准确)。

如果你打算使用WebRTC,请确保你先了解它,以及知道它错综复杂的特性。了解部署WebRTC应用程序所需要的服务器。了解WebRTC内置的信令机制。了解媒体如何处理并通过网络进行发送。了解WebRTC可用于构建生产预备系统的丰富的解决方案。

还有很多东西需要学习。不要意味你熟识网络开发或者因为你了解VoIP或者视频处理就了解WebRTC。

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营