WebRTC入门篇：NAT和防火墙的原理区别及分类

大多数人开始编程或构建结构时，首先考虑到的是性能问题。开始时，他们可能会假设网络环境平稳，可靠且安全。但实际情况往往是，演示或实验会在并非像实验室那样友好的环境下开展，突然你发现实验没有正常运行，质量问题层出不穷，或者是你的系统被黑客入侵。这时你会感觉回到了实验设计的“第2阶段”，需要倾尽全力来修复漏洞。

值得庆幸的是，WebRTC配备了一套内置于引擎中的鲁棒性很强的工具，它可以使Web开发者在“执行”WebRTC任务时应对自如。而在WebRTC的标准工作中，这套工具仍在不断改进。希望此文能作为详细研究这些工具的入门篇供大家学习。诚然，虽然WebRTC旨在使这套工具完全独立，所以开发人员不必关心其中缘由。但是对于那些对这套工具好奇的人、与WebRTC合作构建媒体编码器的人、或者那些努力解决WebRTC互操作性问题的人（句子太长，换口气。），我们将从WebRTC如何解决NAT和防火墙穿越的问题说起。这里我们主要使用三种工具，分别是ICE，STUN和TURN。

为了更透彻理解这些工具，笔者认为最好从NAT的基础知识开始讲起。如果您是NAT行家，请多担待。本文只是一次简单的入门科普。因为我希望将来我们发帖讨论WebRTC的工具时，大家能正确理解引入这些工具的原因和面临的挑战——特别是对于那些不习惯在进行对点链接时考虑网络实时动态的开发人员。

什么是NAT？

NAT意为网络地址转换（https://en.wikipedia.org/wiki/Network_address_translation）。它是一种广泛使用的系统，多用于保留IPv4地址，或使本地网络管理员能够控制本地拓扑结构。实际上NAT技术多种多样，在此不多赘述。最常见的NAT设备通过改变通过它的数据包的IP报头信息得以运行。通常情况下NAT技术与防火墙结合完成，大多数家用路由器都如此，这些路由器通常在保证安全性的同时还保留了IPv4的地址空间，可谓一举两得。但正如我们所见，这也可能导致某些程序和协议出现问题，尤其是像WebRTC这样尝试进行点对点连接的。

常见的NAT 或者防火墙场景是私人或受保护的IP端点子网的场景，与公共互联网的环境不同。

（NAT或防火墙设备保护局域网免受公共互联网的影响。）

通常，局域网上的主机可以将数据包发送给互联网上的主机，但是当来自互联网的任何数据包尝试发送到局域网上的主机时，防火墙都会进行阻止。也就是说，NAT 或防火墙设备阻止数据包通过。显然这是个大问题，因为如果没有数据包可以从互联网传送到局域网上的主机，WebRTC和任何其他基于IP的通信工具都无法运行。

典型的NAT场景

值得庆幸的是，多数防火墙都允许来自互联网的某些特定的数据包通过，即当局域网中的主机首先通过防火墙发送数据包时才能通过。实质上，连接必须由局域网上的主机开启。同时，NAT会应用于通过NAT或防火墙设备加载的数据包。比如说，线上的每个数据包都有一个五元组的TCP / IP基本信息：源IP，源端口，目标IP，目标端口，传输协议（UDP / TCP / SCTP）。当数据包通过NAT或防火墙设备时，它会将数据包的源IP和源端口更改为新的源IP和源端口。然后它在“内部”源IP和源端口以及“外部”源IP和源端口之间保存此绑定。 这称为NAT绑定，NAT 或防火墙会将此路线存储在表中。

NAT将私有IP端口地址关联或绑定到公共IP端口地址。

互联网上的主机只会看到并了解到已更改的“外部”IP端口。如果互联网上的主机了解到这个外部IP端口，并且想要向其发送数据包，这些数据包首先会到达NAT或/防火墙设备。 NAT 或防火墙设备将在其NAT表中查找，并根据NAT绑定，通过更改目标IP端口将数据包转发到内部主机。

这是相当常见的NAT或防火墙行为，而且此行为不会给大多数客户端/服务器通信带来麻烦。 NAT背后的主机通常会通过防火墙请求保留一条后路，如此，服务器可以便捷地响应它收到的数据包IP端口。客户端和服务器主机都不会知道他们中间隔着NAT或防火墙。

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标准来解决上述问题：

交互式连接建立 (ICE）—— RFC 5245

NAT会话穿越应用程序 (STUN）——RFC 5389

通过Relay方式穿越NAT (TURN）——RFC 5766

每个WebRTC会话都需要在与对等方通信时使用上述工具。一旦WebRTC会话指令正确发出并被接受，发现和穿越NAT或防火墙的过程就此开始。完成此过程后，通信路径得以建立，媒体流得以运行。多亏这些工具，诸多拓扑问题得以解决，WebRTC可以正常运作。

即便如此。仍有问题亟待解决。如果您是WebRTC的忠实用户，那么您可能遇到过无法建立通话路径的时候。而本文中描述的场景是更常见的家庭宽带路由器案例，这种问题往往相对易用STUN，ICE和TURN来解决。但在企业、酒店或免费WiFi热点中存在的的限制性NAT和防火墙仍然可能出问题。

至此，笔者意识到笔者用一整篇文章来讨论为何NAT和防火墙可以阻止像WebRTC这样的点对点通信，对WebRTC的ICE / STUN / TURN机制如何避免大多数情况下被限制通话才刚讲了点皮毛。在随后的帖子中，笔者将详细介绍这些工具的工作原理，以及一些需要克服的问题。