WebRTC：如果一个对等点总是使用 Full Cone 或地址限制（但不是端口限制）NAT，我们是否需要 TURN 服务器？
WebRTC: do we need a TURN server if one peer is always using Full Cone Or Address Restricted (but not Port Restricted) NAT?
我已经阅读了一些关于 WebRTC 的内容，但我不明白为什么我们需要 Turn Server 如果只有一个对等点使用对称 NAT，而另一个既不使用对称 NAT 也不使用端口受限 NAT，所以让我们说A 正在使用 Full Cone NAT，B 正在使用对称 NAT：
STUN SERVER会将B的正确IP地址发送给A，并将A的正确IP+端口地址发送给B。
A 尝试连接到 B（现在 A 将能够接受来自 B 的消息，因为它在目标地址列中）。
B 尝试连接到 A，这将允许从 A 到 B 的请求（ofc A 需要将端口更新为从 B 而不是 Sdp 接收到的端口）。
我是不是遗漏了什么，或者这是正确的（并已实施），还是实施起来太复杂了？
如果这是正确的，那么理论上，如果我是对等点 A 并且我正在使用 Full Cone NAT，任何对等点 B 都可以连接到我（只要我先发送连接请求），而不需要一个 TURN 服务器。
谢谢
如果对称 NAT 环境仅更改端口，那么关于与 Full Cone NAT 的连接，您将是正确的。打孔步骤可行。
但是许多企业和移动环境具有复杂的路由方案和疯狂的网络环境，这与传统的家庭网络路由器不同。这些环境不仅仅是连接到电缆调制解调器的小型路由器盒。它是使用一组 IP 地址的路由器和负载平衡器的复杂阵列。并且每个出站连接都可能获得与之前连接不同的 IP 地址。所以它在技术上是“对称 NAT”。
因此，在此环境中的节点从 STUN 服务器获得外部 IP/port 对后，后续发送到对等地址可能会同时更改端口 和 IP 地址 还有。
因此，当 UDP 数据包在打孔步骤中到达时，NAT 看到的 IP 地址与预期完全不同。因此，这里需要一个中继地址（TURN）。
如果你从Mapping/Filtering的角度思考，这道题会简单一些。其他 NAT 术语并不能很好地描述事物的实际工作方式。我的回答来自RFC 4787 and WebRTC for the Curious: Connecting
映射是指您的 NAT 为出站数据包分配 IP/Port。远程对等方可以将流量发送到此映射。过滤是关于谁可以使用这些映射的规则。
然后过滤和映射可以是地址相关的和独立的。如果映射依赖于地址，则意味着每次联系新 IP/Port 时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，它都会被重新使用。这些相同的规则适用于过滤。
如果一个对等点独立于地址+过滤，我认为 TURN 服务器不会提供任何好处。
如果您想要 TCP 连接，部署 TURN 服务器是个好主意。一些 WebRTC 服务器支持 TCP，但我不相信任何浏览器会生成被动 TCP 候选对象。
我已经阅读了一些关于 WebRTC 的内容，但我不明白为什么我们需要 Turn Server 如果只有一个对等点使用对称 NAT，而另一个既不使用对称 NAT 也不使用端口受限 NAT，所以让我们说A 正在使用 Full Cone NAT，B 正在使用对称 NAT：
STUN SERVER会将B的正确IP地址发送给A，并将A的正确IP+端口地址发送给B。
A 尝试连接到 B（现在 A 将能够接受来自 B 的消息，因为它在目标地址列中）。
B 尝试连接到 A，这将允许从 A 到 B 的请求（ofc A 需要将端口更新为从 B 而不是 Sdp 接收到的端口）。
我是不是遗漏了什么，或者这是正确的（并已实施），还是实施起来太复杂了？
如果这是正确的，那么理论上，如果我是对等点 A 并且我正在使用 Full Cone NAT，任何对等点 B 都可以连接到我（只要我先发送连接请求），而不需要一个 TURN 服务器。
谢谢
如果对称 NAT 环境仅更改端口，那么关于与 Full Cone NAT 的连接，您将是正确的。打孔步骤可行。
但是许多企业和移动环境具有复杂的路由方案和疯狂的网络环境，这与传统的家庭网络路由器不同。这些环境不仅仅是连接到电缆调制解调器的小型路由器盒。它是使用一组 IP 地址的路由器和负载平衡器的复杂阵列。并且每个出站连接都可能获得与之前连接不同的 IP 地址。所以它在技术上是“对称 NAT”。
因此，在此环境中的节点从 STUN 服务器获得外部 IP/port 对后，后续发送到对等地址可能会同时更改端口 和 IP 地址 还有。
因此，当 UDP 数据包在打孔步骤中到达时，NAT 看到的 IP 地址与预期完全不同。因此，这里需要一个中继地址（TURN）。
如果你从Mapping/Filtering的角度思考，这道题会简单一些。其他 NAT 术语并不能很好地描述事物的实际工作方式。我的回答来自RFC 4787 and WebRTC for the Curious: Connecting
映射是指您的 NAT 为出站数据包分配 IP/Port。远程对等方可以将流量发送到此映射。过滤是关于谁可以使用这些映射的规则。
然后过滤和映射可以是地址相关的和独立的。如果映射依赖于地址，则意味着每次联系新 IP/Port 时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，它都会被重新使用。这些相同的规则适用于过滤。
如果一个对等点独立于地址+过滤，我认为 TURN 服务器不会提供任何好处。
如果您想要 TCP 连接，部署 TURN 服务器是个好主意。一些 WebRTC 服务器支持 TCP，但我不相信任何浏览器会生成被动 TCP 候选对象。