STUN和TURN澄清

Question

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

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

Answer 1

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

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

3. 根据我的经验：1-2分钟左右。有时更长。如果没有数据在两个方向上流动，请保持每45秒流动一次的消息，以防止会话被丢弃。