WebRTC：如果一个对等方始终使用全锥或地址限制但不是端口限制NAT，我们是否需要 TURN 服务器？

我一直在阅读有关 WebRTC 的一些内容，如果只有一个对等方使用对称 NAT，而另一个对等方既不使用对称 NAT 也不使用端口限制 NAT，那么我不明白为什么我们需要 Turn Server，所以假设 A 是使用 Full Cone NAT，B 使用对称 NAT：

我是否遗漏了什么，或者这是正确的（并已实施），还是太复杂而无法实施？

如果这是正确的，那么理论上，如果我是对等方 A 并且我使用的是 Full Cone NAT，则任何对等方 B 都可以连接到我（只要我先发送连接请求），而无需 TURN服务器。

谢谢

如果对称 NAT 环境仅更改端口，那么您对 Full Cone NAT 的连接性是正确的。打孔步骤会起作用。

但许多企业和移动环境具有不同于传统家庭网络路由器的复杂路由方案和疯狂的网络环境。这些环境不仅仅是连接到电缆调制解调器的小型路由器盒。它是一组复杂的路由器和负载平衡器，使用一组 IP 地址。并且每个出站连接可能会获得与先前连接不同的 IP 地址。所以它在技术上是“对称 NAT”。

因此，在此环境中的节点从 STUN 服务器获得外部 IP/端口对后，后续发送到对等地址可能会同时更改端口和 IP 地址。

因此，当 UDP 数据包在打孔步骤期间到达时，NAT 看到的 IP 地址与预期完全不同。因此，这里需要一个中继地址（TURN）。

如果您从映射/过滤的角度考虑，这个问题会更容易一些。其他 NAT 术语不能很好地描述事情的实际工作方式。我的答案来自RFC 4787和WebRTC for the Curious: Connecting

映射是指您的 NAT 为出站数据包分配 IP/端口。远程对等方可以将流量发送到此映射。过滤是关于谁可以使用这些映射的规则。

过滤和映射然后可以是地址相关和独立的。如果映射依赖于地址，则意味着每次联系新 IP/端口时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，都会重新使用它。这些规则同样适用于过滤。

如果一个对等点是独立于地址和过滤的，我认为 TURN 服务器不会提供任何好处。

如果您想要 TCP 连接，则部署 TURN 服务器是个好主意。一些 WebRTC 服务器支持 TCP，但我认为没有任何浏览器会生成被动 TCP 候选。