WebRTC的问题以及如何debug-1

作者:Lee Sylvester(原文链接

翻译:刘通

原标题:WebRTC Issues and How to Debug Them

webrtc-logo

WebRTC是由Google的天才工程师创造的一项惊人且颇具开创性的技术。在浏览器之间创建无插件的连接,WebRTC的典型应用是网络视频聊天。

但是,WebRTC不仅仅可以用于音频和视频的传输,它也能够应用于其他高速数据传输。简而言之,它让我们得以窥探端到端游戏,文件传输和其他真正无服务器应用程序的未来。

WebRTC的阴暗面

我在Xirsys工作时,我看到了一些使用WebRTC技术的非常了不起的应用程序。但是,尽管一些人已经在为下一个伟大的发明努力,但是大多数开发人员还处于起步阶段。因为WebRTC本身就很难!

我们都熟悉典型的Web应用程序。我们有一个客户端,它将数据发送到服务器且从其接收数据;我们还有一个服务器应用,它发送数据给数据库且从其接收数据。许多网络应用的处理过程是线性且可预知的。如果出现问题,我们通常会知道检查哪里,以及它可能发生的原因。

但是,WebRTC,并没有这么简单。

异步

如果你之前编写过多线程应用,那么你可能知道一些会导致问题的地方。竞争条件和受损数据是一对,但是通常大家只是把这些归结于那些难于发现及修复的问题。

WebRTC本质上就是异步的。而且考虑到从远端机器发送和接收数据的情况,它也必须是异步的。这与AJAX调用的不同步性有所不同;相比之下,这些确实很简单。相反的,根据许多这样的调用来考虑,这些调用分布在本地和远端数据不断变化的情况中。

当然,胆小的人不适合来做这件事。

主要在客户端

WebRTC是一个重视客户端的技术。当客户端应用无法正常工作时,通常第一步是询问TURN服务提供商是否有任何日志显示它无法正常工作。

但是需要指出的是,绝大多数WebRTC故障发生在服务器甚至从未被联系过时。至少从服务器的角度来看,没有联系意味着无法登陆。这代表必须挖掘自己的代码来找到答案并知道从哪里开始寻找。

NAT穿越是个雷区

issue2

构建Web应用程序通常是一项简单的工作。你写一些会放在Web服务器后面的东西,其中可能有也可能没有服务器端逻辑。一旦写好之后,你就可以部署到您的服务器中去。

在这种情况下,可能发生的最糟糕的事情是你忘了咋爱你IPTable中打开正确的端口。我们都可以做到这些,通常都很简单。但是WebRTC可没有这么容易。

这里的问题是Web服务器本身(硬件而不是软件)是以公开提供数据的目的部署的。他们为此配置了网络硬件并提供公共IP地址。但是,使用WebRTC的目的是连接并发送和接收来自用户机的数据。

这些机器通常情况下,位于旨在保护所述机器免受公众请求的网络上,很有可能不具备公共IP地址,并且经常会引入一些复杂的障碍。

虽然连接到简单的Web服务器与创建HTTP请求一样容易,但WebRTC提供了多种连接类型,我们可以尝试各种连接类型以成功建立连接。

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

WebRTC 中文社区由

运营