STUN 服务器如何获得 IP address/port 然后如何使用这些 IP？
How does the STUN server get IP address/port and then how are these used?
我正在尝试了解 WebRTC 的工作原理，但无法理解 STUN 的作用。
根据我在各种 web-pages 上阅读有关 STUN 的理解，例如 rfc5389, or watching Google's 2013 presentation on WebRTC，STUN 似乎唯一要做的就是告诉客户它是什么 public IP address/port是。
然而，看看人们如何实施 STUN 服务器表明他们涉及更多，并且似乎包括 fail-back 对 UDP、TCP 和 TLS-TCP 的支持，以及握手，客户端和服务器报告他们期望的 IP 地址，并根据对方所说的 IP 地址进行验证。例如，据传闻，jselbi's stunserver project 有超过 50 个 C++ 文件。
- 所以 STUN 一定不仅仅是报告 public IP address/port？
此外，我不明白为什么 WebRTC 客户端甚至需要知道自己的 public IP 地址。在 Google's presentation video (at time 19:46) 中显示了两个想要从 NAT 后面相互交谈的对等点，并且每个对等点还与信令服务器进行通信。此图表明每个信令服务器都不知道对等方的 public IP address/port。但是这张图一定是错的：它显示了对等点直接与信令服务器对话，但通过 NAT 间接与 STUN 服务器对话。实际上，对等点也会通过 NAT 与信令服务器通信，因此，信令服务器已经知道对等点的 public IP address/port.
据此，我遇到的问题是：
从客户端到信令服务器的任何请求都将在请求的 IP header 中包含该客户端的 public IP address/port。当客户端与 STUN 服务器对话时也是如此，这就是为什么 STUN 服务器可以用 public IP address/port 响应的原因...这是对的吗？
在我看来，这两个对等点可以相互交谈的方式是劫持对等点和 STUN 服务器之间的开放连接：对等点打开到 STUN 服务器的连接。 STUN 服务器通过说明已为此请求设置的 IP address/port 进行回复。然后该 IP address/port 被转发到远程对等点，远程对等点开始在最初为 STUN 服务器打开的连接上发送消息...这是正确的吗？
...还是我完全误解了发生了什么事？
STUN 服务器只对 return 的 public ip 和端口有非常简单的作用，它们接收到客户端上的 UDP 数据包。您看到的是一个同样实现 TURN（在 https://www.rfc-editor.org/rfc/rfc5766 中描述）的服务器，它是一个 STUN 扩展，允许客户端在服务器上打开一个 udp 端口并中继数据。
与信令服务器的连接是使用 TCP 完成的，不受 NAT 的影响。信令服务器看到传入的 TCP 连接，但该数据对于从外部建立连接没有用。
是的。嗯，几乎，媒体路径使用 UDP，所以没有连接。大多数 NAT 都将发送到 public ip/port 的任何内容转发给发起方。对称 NAT 不需要，这也是需要 TURN 的原因。整个过程被称为“udp holepunching”或更正式的 ICE（在 https://www.rfc-editor.org/rfc/rfc5245 中描述）
不，你说对了核心思想之一的“劫持”部分。但是 NAT 比你想象的更糟糕 ;-)
我正在尝试了解 WebRTC 的工作原理，但无法理解 STUN 的作用。
根据我在各种 web-pages 上阅读有关 STUN 的理解，例如 rfc5389, or watching Google's 2013 presentation on WebRTC，STUN 似乎唯一要做的就是告诉客户它是什么 public IP address/port是。
然而，看看人们如何实施 STUN 服务器表明他们涉及更多，并且似乎包括 fail-back 对 UDP、TCP 和 TLS-TCP 的支持，以及握手，客户端和服务器报告他们期望的 IP 地址，并根据对方所说的 IP 地址进行验证。例如，据传闻，jselbi's stunserver project 有超过 50 个 C++ 文件。
- 所以 STUN 一定不仅仅是报告 public IP address/port？
此外，我不明白为什么 WebRTC 客户端甚至需要知道自己的 public IP 地址。在 Google's presentation video (at time 19:46) 中显示了两个想要从 NAT 后面相互交谈的对等点，并且每个对等点还与信令服务器进行通信。此图表明每个信令服务器都不知道对等方的 public IP address/port。但是这张图一定是错的：它显示了对等点直接与信令服务器对话，但通过 NAT 间接与 STUN 服务器对话。实际上，对等点也会通过 NAT 与信令服务器通信，因此，信令服务器已经知道对等点的 public IP address/port.
据此，我遇到的问题是：
从客户端到信令服务器的任何请求都将在请求的 IP header 中包含该客户端的 public IP address/port。当客户端与 STUN 服务器对话时也是如此，这就是为什么 STUN 服务器可以用 public IP address/port 响应的原因...这是对的吗？
在我看来，这两个对等点可以相互交谈的方式是劫持对等点和 STUN 服务器之间的开放连接：对等点打开到 STUN 服务器的连接。 STUN 服务器通过说明已为此请求设置的 IP address/port 进行回复。然后该 IP address/port 被转发到远程对等点，远程对等点开始在最初为 STUN 服务器打开的连接上发送消息...这是正确的吗？
...还是我完全误解了发生了什么事？
STUN 服务器只对 return 的 public ip 和端口有非常简单的作用，它们接收到客户端上的 UDP 数据包。您看到的是一个同样实现 TURN（在 https://www.rfc-editor.org/rfc/rfc5766 中描述）的服务器，它是一个 STUN 扩展，允许客户端在服务器上打开一个 udp 端口并中继数据。
与信令服务器的连接是使用 TCP 完成的，不受 NAT 的影响。信令服务器看到传入的 TCP 连接，但该数据对于从外部建立连接没有用。
是的。嗯，几乎，媒体路径使用 UDP，所以没有连接。大多数 NAT 都将发送到 public ip/port 的任何内容转发给发起方。对称 NAT 不需要，这也是需要 TURN 的原因。整个过程被称为“udp holepunching”或更正式的 ICE（在 https://www.rfc-editor.org/rfc/rfc5245 中描述）
不，你说对了核心思想之一的“劫持”部分。但是 NAT 比你想象的更糟糕 ;-)