STUN 服务器如何获取 IP 地址/端口，然后如何使用它们？

Question

我正在尝试了解 WebRTC 的工作原理，但无法理解 STUN 的作用。

根据我在各种网页上阅读 STUN 的了解，例如 rfc5389，或观看 Google's 2013 presentation on WebRTC，STUN 似乎唯一做的就是告诉客户端它的公共 IP 地址/端口是什么。

但是，查看如何实现 STUN 服务器表明他们参与的程度更高，并且似乎包括对 UDP、TCP 和 TLS-TCP 的故障回复支持，以及客户端和服务器在哪里握手报告他们期望的 IP 地址，并根据对方所说的 IP 地址进行验证。例如，有趣的是，jselbi's stunserver project 有超过 50 个 C++ 文件。

1. 所以 STUN 肯定不仅仅是报告公共 IP 地址/端口？

此外，对我来说，为什么 WebRTC 客户端甚至需要知道自己的公共 IP 地址是没有意义的。在Google's presentation video (at time 19:46) 中显示了两个想要从 NAT 后面相互交谈的对等点，并且每个对等点还与一个信令服务器进行通信。此图表明每个信令服务器都不知道对等方的公共 IP 地址/端口。但是这个图肯定是错误的：它显示了对等方直接与信令服务器对话，但通过 NAT 与 STUN 服务器间接对话。实际上，对等方也会通过 NAT 与信令服务器通信，因此，信令服务器已经知道对等方的公共 IP 地址/端口。

由此，我遇到的问题是：

1. 从客户端到信令服务器的任何请求都将在请求的 IP 标头中包含该客户端的公共 IP 地址/端口。当客户端与 STUN 服务器对话时也是如此，这就是为什么 STUN 服务器可以使用公共 IP 地址/端口进行响应的原因……是这样吗？

2. 在我看来，两个对等点可以相互交谈的方式是劫持对等点和 STUN 服务器之间的开放连接：对等点打开到 STUN 服务器的连接。 STUN 服务器通过说明已为该请求设置的 IP 地址/端口来回复。然后将该 IP 地址/端口转发到远程对等方，远程对等方开始在最初为 STUN 服务器打开的连接上发送消息......这是正确的吗？

3. ...或者我完全误解了发生了什么？

Answer 1

1. STUN 服务器只有一个非常简单的作用，就是将它们收到的 UDP 数据包返回给客户端的公共 IP 和端口。您正在查看的是实现 TURN（在https://www.rfc-editor.org/rfc/rfc5766 中描述）的服务器，这是一个 STUN 扩展，允许客户端在服务器上打开 udp 端口​​并中继数据。

2. 到信令服务器的连接是使用 TCP 完成的，不受 NAT 影响。信令服务器看到传入的 TCP 连接，但该数据对于从外部建立连接没有用处。

3. 是的。好吧，几乎，媒体路径使用 UDP，所以没有连接。大多数 NAT 将任何进入公共 ip/端口的内容转发给发起方。对称 NAT 不需要，这也是需要 TURN 的原因。整个过程被称为“udp打孔”或更正式的ICE（在https://www.rfc-editor.org/rfc/rfc5245中描述）

4. 不，你得到了“劫持”部分，这是正确的核心思想之一。但是 NAT 比你想象的更坏 ;-)