在同一网络中部署 TURN 和媒体服务器是否有意义？
Does it make sense to deploy TURN and media server in the same network?
假设我们部署了一个媒体服务器S。我们有一个客户端 C 在对称 NAT 后面。由于对称 NAT，直接 WebRTC 媒体流是不可能的。所以我们想部署一个 TURN 服务器 T，它将中继 S 和 C 之间的所有媒体。
现在，为了简单起见，开发人员似乎有时会在 S 附近部署 T。但它有助于在 C 和 S 之间传输媒体吗？ "Near" 表示 "in the same network"，因此 S 和 T 在同一个 NAT 后面（如果有的话）。因为，它们在同一个 NAT 后面，它似乎并没有改善连接性：在 S 和 C 之间流式传输 WebRTC 流量的机会与在 T 和 [=11= 之间流式传输 WebRTC 流量的机会相同].
这个推理是正确的还是我遗漏了什么？在我目前的理解中，TURN 服务器就像一个代理，在 C 方面具有更好的连接性。所以他们应该放在另一个网络中才能发挥作用。
C -> T 可以做一些 C -> S 不能做的事情
- DTLS 和 TLS 传输，ICE 只允许 UDP 和 TCP。一些网关只允许 443
上的 TLS
- 单一端口，您可以在一个众所周知的端口上处理所有流量。网关可能只允许
:443
S 可能不支持 ICE-TCP。不过有些 SFU 确实支持它！
假设我们部署了一个媒体服务器S。我们有一个客户端 C 在对称 NAT 后面。由于对称 NAT，直接 WebRTC 媒体流是不可能的。所以我们想部署一个 TURN 服务器 T，它将中继 S 和 C 之间的所有媒体。
现在，为了简单起见，开发人员似乎有时会在 S 附近部署 T。但它有助于在 C 和 S 之间传输媒体吗？ "Near" 表示 "in the same network"，因此 S 和 T 在同一个 NAT 后面（如果有的话）。因为，它们在同一个 NAT 后面，它似乎并没有改善连接性：在 S 和 C 之间流式传输 WebRTC 流量的机会与在 T 和 [=11= 之间流式传输 WebRTC 流量的机会相同].
这个推理是正确的还是我遗漏了什么？在我目前的理解中，TURN 服务器就像一个代理，在 C 方面具有更好的连接性。所以他们应该放在另一个网络中才能发挥作用。
C -> T 可以做一些 C -> S 不能做的事情
- DTLS 和 TLS 传输，ICE 只允许 UDP 和 TCP。一些网关只允许 443 上的 TLS
- 单一端口，您可以在一个众所周知的端口上处理所有流量。网关可能只允许
:443 S可能不支持ICE-TCP。不过有些 SFU 确实支持它！