作者：Lee Sylvester（原文链接）
翻译：刘通
原标题：WebRTC Issues and How to Debug Them
WebRTC是由Google的天才工程师创造的一项惊人且颇具开创性的技术。在浏览器之间创建无插件的连接，WebRTC的典型应用是网络视频聊天。
但是，WebRTC不仅仅可以用于音频和视频的传输，它也能够应用于其他高速数据传输。简而言之，它让我们得以窥探端到端游戏，文件传输和其他真正无服务器应用程序的未来。
WebRTC的阴暗面
我在Xirsys工作时，我看到了一些使用WebRTC技术的非常了不起的应用程序。但是，尽管一些人已经在为下一个伟大的发明努力，但是大多数开发人员还处于起步阶段。因为WebRTC本身就很难！
我们都熟悉典型的Web应用程序。我们有一个客户端，它将数据发送到服务器且从其接收数据；我们还有一个服务器应用，它发送数据给数据库且从其接收数据。许多网络应用的处理过程是线性且可预知的。如果出现问题，我们通常会知道检查哪里，以及它可能发生的原因。
但是，WebRTC，并没有这么简单。
异步
如果你之前编写过多线程应用，那么你可能知道一些会导致问题的地方。竞争条件和受损数据是一对，但是通常大家只是把这些归结于那些难于发现及修复的问题。
WebRTC本质上就是异步的。而且考虑到从远端机器发送和接收数据的情况，它也必须是异步的。这与AJAX调用的不同步性有所不同；相比之下，这些确实很简单。相反的，根据许多这样的调用来考虑，这些调用分布在本地和远端数据不断变化的情况中。
当然，胆小的人不适合来做这件事。
主要在客户端
WebRTC是一个重视客户端的技术。当客户端应用无法正常工作时，通常第一步是询问TURN服务提供商是否有任何日志显示它无法正常工作。
但是需要指出的是，绝大多数WebRTC故障发生在服务器甚至从未被联系过时。至少从服务器的角度来看，没有联系意味着无法登陆。这代表必须挖掘自己的代码来找到答案并知道从哪里开始寻找。
NAT穿越是个雷区
构建Web应用程序通常是一项简单的工作。你写一些会放在Web服务器后面的东西，其中可能有也可能没有服务器端逻辑。一旦写好之后，你就可以部署到您的服务器中去。
在这种情况下，可能发生的最糟糕的事情是你忘了咋爱你IPTable中打开正确的端口。我们都可以做到这些，通常都很简单。但是WebRTC可没有这么容易。
这里的问题是Web服务器本身（硬件而不是软件）是以公开提供数据的目的部署的。他们为此配置了网络硬件并提供公共IP地址。但是，使用WebRTC的目的是连接并发送和接收来自用户机的数据。
这些机器通常情况下，位于旨在保护所述机器免受公众请求的网络上，很有可能不具备公共IP地址，并且经常会引入一些复杂的障碍。
虽然连接到简单的Web服务器与创建HTTP请求一样容易，但WebRTC提供了多种连接类型，我们可以尝试各种连接类型以成功建立连接。
