作者：Philipp Hancke（原文链接）
翻译：刘通
WebRTC的目的是在网络浏览器之间建立端到端连接。为了完成这个目的，它使用了一系列的技术，统称为ICE。ICE允许在特定类型的NAT路由器之后的用户可以建立直接连接。而这会遇到的第一个问题是，用户需要找到他们对应的公共IP地址是什么。为了解决这个问题，用户想STUN服务器询问他们的IP地址。
NAT是一种可以将我们的本地私有网络与公共互联网对应联系起来的盒子（物理意义上或者是虚拟的盒子）。他们将我们使用的内部IP地址翻译成对应的公共IP地址。内部IP和公共IP是不一样的，所以WebRTC就需要同时依赖STUN和TURN的帮助才能建立起通话。
通过观看Tsahi Levent-Levi的WebRTC架构课程里面“NAT穿越”的这一讲，我从这一页幻灯片中（重新）学到了对称NAT的定义：
如果你向两个不同的STUN服务器询问你的公共IP地址，对称NAT将给你两个同样的IP地址（希望如此），但是两个端口号不一样。我们需要一个TURN服务器来处理这种混乱的现象，对称NAT不允许建立直接连接。
几年前我曾对一些可以增强连接性的技术进行过讨论（点击此处查看视频，以及演示文稿）。Tsahi的讲话让我想到，我们是不是也能在你获得了两个不同的端口号的时候，对这种对称NAT的情景进行测试呢？
在做了一些测试之后我确定了我们是可以的。
第一部要向两个STUN服务器询问我们的IP地址，通过这个配置：
我们创建一个数据通道来使对等端连接只能产生一个本地候选项。
然后我们查看onicecandidate事件，并且提取出我们可以获得到的任何候选。如果候选项的类别是srflx，我们同时注意这两个端口—在NAT设备转化后的端口—以及relatedPort—转化前的端口。
最后但不是不重要的一步，我们调用createOffer和setLocalDescription来开始收集：
一旦我们完成候选项的收集之后，我们就会获得一个icecandidate事件，其event.candidate没有被设定。我们然后观察我们得到的候选项。只有三种情况：
#1 如果我们只得到了一个候选项，浏览器不会用从第二个STUN服务器那里得到的响应来麻烦我们，因为它包含了同样的端口。也就意味着我们并没有处在一个对称NAT之后。
#2 如果我们得到了两个有着同样relatedPort的候选项，但是端口不一样，那么就代表我们正处于一个对称NAT之后。
#3 如果我们在所有UDP连接都被屏蔽的情况下没有得到srflx候选项。这意味着我们需要一个TURN/TCP或者TURN/TLS服务器。
那么你要怎么来测试它呢？一台iPhone的个人热点所使用的就是对称NAT，而这可以帮大忙。这里有在线测试。
如果我们知道了我们是不是处在一个对称NAT之后，这会对我们起到什么帮助呢？很有可能不会有什么大作用。我们现在可以搭建一个NAT类型检测器。我不确定这个类型检测器会不会有任何实际的用处，因为WebRTC的ICE机制是被设计用于在不打扰你的情况下寻找并创建连接，但是到底会不会派上用场谁都说不好。但这确实是一个可以帮助你更好了解WebRTC的NAT穿越机制的有趣的方法。
