大多数人开始编程或构建结构时，首先考虑到的是性能问题。开始时，他们可能会假设网络环境平稳，可靠且安全。但实际情况往往是，演示或实验会在并非像实验室那样友好的环境下开展，突然你发现实验没有正常运行，质量问题层出不穷，或者是你的系统被黑客入侵。这时你会感觉回到了实验设计的“第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或防火墙。
原文标题: An Intro to WebRTC’s NAT/Firewall Problem
作者: Reid Stidolph
