NAT和点对点通讯：有何问题？
虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：
（指令1和没有NAT的点对点数据2）
以上过程在没有NAT或防火墙时可以顺利进行。但在使用万维网进行通信的许多情况下，端点之间可能存在NAT /防火墙设备。更重要的是，端点无法知道它与它想要通信的对等体之间的网络拓扑类型。因此，当端点发出信号表示它希望在本地主机操作系统的IP端口上进行通信时，它完全没有意识到自己为其他端点提供的连接信息将被其防火墙阻止。此外，由于端点间存在NAT，端点报告的地址甚至不能被另一个对等体访问。也就是说，端点“自认为”其发出的信号可以到达某一地址，但由于NAT的存在，NAT之外的其他地方只知道，并且只能到达NAT的设备地址。因为对等体不知道其拓扑结构，所以它发出了错误的连接信息。
以下示例大致与上述例子相同，只添加了NAT或防火墙设备：
（对等方无法识别自己的外部地址或传达此信息）
显然在有NAT或防火墙设备的情况下，点对点通信必然会失败。且本文所述只是其中一种可能出现的拓扑类型。实际上，多种NAT、防火墙和拓扑结构的组合都是可能导致点对点通信失败的原因，只不过是以不同方式。
那么，应该如何解决此问题呢？
解决NAT或防火墙穿越问题的WebRTC工具
点对点通信对于大多数（或绝大多数）WebRTC应用程序来说必不可少，因为其可以最大限度地减少延迟和服务器成本。笔者已大致介绍了NAT或防火墙设备给点对点通信带来的严峻挑战，WebRTC必须有能克服挑战的一套机制，此机制需要为浏览器配备一些重要功能：
- 尽可能地学习它本身及它想要与之通信的对等体之间的拓扑类型；
- 通过既定拓扑在最佳路径上建立连接；
- 如果所有方法都失败，使用后备方案。
WebRTC标准借鉴了互联网工程任务组(IEFT) 的三项穿越NAT标准来解决上述问题：
每个WebRTC会话都需要在与对等方通信时使用上述工具。一旦WebRTC会话指令正确发出并被接受，发现和穿越NAT或防火墙的过程就此开始。完成此过程后，通信路径得以建立，媒体流得以运行。多亏这些工具，诸多拓扑问题得以解决，WebRTC可以正常运作。
即便如此。仍有问题亘待解决。如果您是WebRTC的忠实用户，那么您可能遇到过无法建立通话路径的时候。而本文中描述的场景是更常见的家庭宽带路由器案例，这种问题往往相对易用STUN，ICE和TURN来解决。但在企业、酒店或免费WiFi热点中存在的的限制性NAT和防火墙仍然可能出问题。
至此，笔者意识到笔者用一整篇文章来讨论为何NAT和防火墙可以阻止像WebRTC这样的点对点通信，对WebRTC的ICE / STUN / TURN机制如何避免大多数情况下被限制通话才刚讲了点皮毛。在随后的帖子中，笔者将详细介绍这些工具的工作原理，以及一些需要克服的问题。
原文标题: An Intro to WebRTC’s NAT/Firewall Problem
作者: Reid Stidolph
