STUN 和 TURN 说明

Question

我需要在服务器和客户端之间建立连接，它们都可以位于任何类型的 NAT 之后。为此，我在 Internet 上有一个专用主​​机，其 IP 干净，用于托管 STUN/TURN 服务器。我不会使用 WebRTC，我只想使用 STUN/TURN 服务器在客户端和服务器之间进行消息传递。在阅读了 RFC、SO 等之后，我有一些不清楚的问题：

1. 在什么情况下使用 STUN？据我了解，STUN 仅用于全锥 NAT。在所有其他情况下，由于主机和/或端口限制，必须使用 TURN 服务器。对吗？
2. 看来我需要一个信令服务器来通知客户端服务器地址，反之亦然。但是一旦客户端/服务器向信令服务器发送消息，我就知道他们的外部主机：端口，所以我让每一方都知道对方的主机：端口，每一方都可以向这个信令服务器发送包含对等方主机：端口数据的消息，信令服务器可以使用它来检测该消息是针对哪个对等点并将其转发给相应的对等点。乍一看，这个逻辑在我看来非常简单，我的信令服务器变成了一个 TURN 服务器——这就是 TURN 服务器的实现方式吗？但如果是这样，我不明白，为什么我需要像“coturn”、“reTurn”等这样的 TURN 服务器？我知道他们实现了 ICE，但是如果我的信令服务器从对等点的具体主机：端口接收到消息，那么这个 ICE 将如何工作，那么这是唯一可用于与对等点连接的候选对象？
3. 在受限 NAT（端口、地址或对称）的情况下，客户端外部（公共）端口在路由器上打开多长时间以接收 UDP 数据报？我读到 TURN 客户端向服务器发送刷新消息以保持通道打开，这是客户端也防止端口关闭的方式吗？

Answer 1

1. STUN 可以桥接大多数 NAT 的 P2P 连接，但对称类型除外，它具有不可预测的端口映射。后者需要TURN。

2. 信令通常使用 TCP 和不同的套接字来完成。 P2P 媒体通常是 UDP。所以有这个区别。您可能会在信令服务器的帮助下发现 IP 地址，但无法可靠地发现端口。即使两者都是 TCP，您也可能需要一个单独的套接字连接用于信令服务而不是媒体。

3. 根据我的经验：1-2 分钟不等。有时更长。在没有双向数据流动的情况下，每 45 秒发送一次保持活动消息，以防止会话被丢弃。