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

Question

我试图了解 WebRTC 的工作原理，但在理解 STUN 的作用时遇到了麻烦。

根据我在各种网页（例如rfc5389 ）上阅读有关 STUN 的内容，或在 WebRTC 上观看Google 2013 年的演示，STUN 似乎唯一能做的就是告诉客户端它的公共 IP 地址/端口是什么。

然而，看看如何实现 STUN 服务器表明他们涉及更多，并且似乎包括诸如对 UDP、TCP 和 TLS-TCP 的故障回复支持之类的东西，以及客户端和服务器报告他们什么的握手期望他们的 IP 地址是，并根据对方所说的 IP 地址进行验证。例如，有趣的是，jselbi 的 stunserver 项目有超过 50 个 C++ 文件。

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

此外，我不明白为什么 WebRTC 客户端甚至需要知道自己的公共 IP 地址。在Google 的演示视频（时间 19:46）中，两个对等方想要从 NAT 后面相互通信，并且每个对等方还与信令服务器进行通信。该图表明每个信令服务器不知道对等方的公共 IP 地址/端口。但是这个图肯定是错误的：它显示了对端直接与信令服务器通话，但通过 NAT 间接与 STUN 服务器通话。实际上，对等方也将通过 NAT 与信令服务器通信，因此，信令服务器已经知道对等方的公共 IP 地址/端口。

由此，我遇到的问题是：

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

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

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

Answer 1

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

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

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

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