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

Question

我正在尝试了解 WebRTC 的工作原理，并且无法理解 STUN 的作用。
根据我在各种网页上阅读 STUN 的理解，例如 rfc5389 ，或观看Google's 2013 presentation on WebRTC ，STUN 似乎唯一能做的就是告诉客户端它的公共(public) IP 地址/端口是什么。
然而，看看如何实现一个 STUN 服务器表明他们更多地参与其中，并且似乎包括对 UDP、TCP 和 TLS-TCP 的故障回复支持，以及客户端和服务器报告它们的握手。期望他们的 IP 地址是，并根据对方所说的 IP 地址进行验证。例如，有趣的是，jselbi's stunserver project有超过 50 个 C++ 文件。

所以 STUN 必须做的不仅仅是报告公共(public) IP 地址/端口？

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

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

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

...还是我完全误解了发生了什么？

Answer 1

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

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

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

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