WebRTC：TURN服务器与滚动通过通信的自定义服务器有何不同？

Question

在了解WebRTC时，我发现对TURN服务器很难理解。让我快速回顾一下我的理解。

信令服务器：是通过传递SDP数据包以协商WebRTC连接的自定义（未指定协议）实现。最有趣/古怪的实现是按照Chris Ball的说明将SDP数据包以纯文本格式复制/粘贴（注：谁说“实现”意味着您必须进行编程？：-D）。

STUN服务器：它告诉您可访问的IP +端口。再见NAT！哦，只有80％的情况。

我对 TURN服务器的理解的另外20％是：两（或更多）个P2P连接方都可以访问的服务器，该服务器通过TURN服务器中继来自这些方的数据（使用绕过Nat的中继的遍历）并将其发送给另一方。在RFC 5766中有描述。

我的情况（以及由此引起的问题）

1. 我有一个信令服务器（是的！）
2. 我有一个STUN服务器（欢呼！）
3. 我有一个运行Socket.io的NodeJS服务器，用于当P2P通过信令和STUN服务器失败时。它只是获取传入流量并将其广播给需要收听的任何人。

我知道我的服务器是定制的，可以实现与TURN服务器相同的功能。

我的问题：这种定制服务器与TURN服务器相比有何不同？

注意：在我的情况下，它是NodeJS + Socket.io，但是它可以是任何定制服务器（出于乐趣，我还使用WebSockets创建了Ruby / Rails实现，而无需进行HTTP长轮询，一个备用）。

Answer 1

嗯，也许是因为当有一些coturn和restund这样的好而免费的实现时，我们不希望从头开始构建中继服务器的开销。您需要花费大量时间才能达到相同水平的性能和可伸缩性。

此外，有了TURN服务器，您就不需要单独的STUN服务器。

Answer 2

通常，socket.io和Node仅用于发信号（和发送自定义消息）。一个简单的CoTurn实例可以在5 $ vps上运行。

除了用作转弯服务器外，它还提供眩晕功能，但以我的经验，最好也使用公开的Google STUN（在中国除外，这是无法获得的。）

问题是：您是否检查了实施的网络和系统负载并将其与传统的TURN设置进行了比较？