STUN 和 TURN 说明
STUN and TURN clarification
我需要在服务器和客户端之间建立连接，它们都可以位于任何类型的 NAT 之后。为此，我在 Internet 上有一个专用主机，具有干净的 IP 用于托管 STUN/TURN 服务器。我不打算使用 WebRTC，我只想使用 STUN/TURN 服务器在客户端和服务器之间进行消息传递。在阅读了 RFC、SO 等之后，我还有一些不清楚的问题：
- 在什么情况下使用STUN？在我的理解中，STUN 仅用于 Full-cone NAT。在所有其他情况下，必须使用 TURN 服务器，因为主机 and/or 端口限制。对吗？
- 看来我需要一个信令服务器来通知客户端服务器地址，反之亦然。但是只要client/server向信令服务器发送消息，我就知道他们的外层host:port，所以我让每一方都知道对方的host:port，每一方都可以向这个信令服务器发送消息包含 peer 的 host:port 数据，信令服务器可以使用它来检测此消息是针对哪个 peer 并将其转发给相应的 peer。乍一看，这个逻辑在我看来非常简单，我的信令服务器变成了 TURN 服务器——TURN 服务器就是这样实现的吗？但如果是这样，我不明白，为什么我需要像 "coturn"、"reTurn" 等的 TURN 服务器？我知道他们实现了 ICE，但是如果我的信令服务器从对等方的具体 host:port 接收到消息，那么这个 ICE 将如何工作，那么这是唯一可用于与对等方连接的候选者？
- 在受限 NAT（端口、地址或对称）的情况下，客户端外部 (public) 端口在路由器上打开多长时间用于接收 UDP 数据报？我读到 TURN 客户端向服务器发送刷新消息以保持通道打开，这是客户端还防止端口关闭的方式吗？
STUN 可以桥接大多数 NAT 的 P2P 连接，除了具有不可预测的端口映射的对称类型。后者需要TURN。
信令通常使用 TCP 和不同的套接字完成。 P2P 媒体通常是 UDP。所以有这种区别。您可能会在信令服务器的帮助下发现 IP 地址，但无法可靠地发现端口。即使两者都是 TCP，您也可能需要一个单独的套接字连接用于信令服务而不是媒体。
根据我的经验：1-2 分钟不等。有时更长。在没有双向数据流动的情况下，保持每 45 秒流动一次的消息以防止会话丢失。
我需要在服务器和客户端之间建立连接，它们都可以位于任何类型的 NAT 之后。为此，我在 Internet 上有一个专用主机，具有干净的 IP 用于托管 STUN/TURN 服务器。我不打算使用 WebRTC，我只想使用 STUN/TURN 服务器在客户端和服务器之间进行消息传递。在阅读了 RFC、SO 等之后，我还有一些不清楚的问题：
- 在什么情况下使用STUN？在我的理解中，STUN 仅用于 Full-cone NAT。在所有其他情况下，必须使用 TURN 服务器，因为主机 and/or 端口限制。对吗？
- 看来我需要一个信令服务器来通知客户端服务器地址，反之亦然。但是只要client/server向信令服务器发送消息，我就知道他们的外层host:port，所以我让每一方都知道对方的host:port，每一方都可以向这个信令服务器发送消息包含 peer 的 host:port 数据，信令服务器可以使用它来检测此消息是针对哪个 peer 并将其转发给相应的 peer。乍一看，这个逻辑在我看来非常简单，我的信令服务器变成了 TURN 服务器——TURN 服务器就是这样实现的吗？但如果是这样，我不明白，为什么我需要像 "coturn"、"reTurn" 等的 TURN 服务器？我知道他们实现了 ICE，但是如果我的信令服务器从对等方的具体 host:port 接收到消息，那么这个 ICE 将如何工作，那么这是唯一可用于与对等方连接的候选者？
- 在受限 NAT（端口、地址或对称）的情况下，客户端外部 (public) 端口在路由器上打开多长时间用于接收 UDP 数据报？我读到 TURN 客户端向服务器发送刷新消息以保持通道打开，这是客户端还防止端口关闭的方式吗？
STUN 可以桥接大多数 NAT 的 P2P 连接，除了具有不可预测的端口映射的对称类型。后者需要TURN。
信令通常使用 TCP 和不同的套接字完成。 P2P 媒体通常是 UDP。所以有这种区别。您可能会在信令服务器的帮助下发现 IP 地址，但无法可靠地发现端口。即使两者都是 TCP，您也可能需要一个单独的套接字连接用于信令服务而不是媒体。
根据我的经验：1-2 分钟不等。有时更长。在没有双向数据流动的情况下，保持每 45 秒流动一次的消息以防止会话丢失。