WebRTC：TURN 服务器与滚动您自己的传递通信的自定义服务器有何不同？答案

【问题标题】：WebRTC: how does a TURN server differ from rolling your own custom server that passes communication through?WebRTC：TURN 服务器与滚动您自己的传递通信的自定义服务器有何不同？
【发布时间】：2020-02-09 01:05:01
【问题描述】：

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

信令服务器： 是传递 SDP 数据包以协商 WebRTC 连接的自定义（未指定协议）实现。最有趣/古怪的实现是您将 SDP 数据包复制/粘贴为纯文本，正如Chris Ball 所解释的那样（旁注：谁说“实现”意味着您必须编程？:-D）。

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

另外 20%，我对 TURN 服务器 的理解是：一个可供双方（或更多）P2P 连接方访问的服务器，它通过 TURN 服务器中继来自这些方的数据（Traversal Using Relays Around Nat ) 并将其发送给另一方。在RFC 5766中有描述。

我的情况（以及由此产生的问题）

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

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

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

注意：在我的例子中，它是 NodeJS + Socket.io，但它可以是任何自定义构建的服务器（为了好玩，我还使用 WebSockets 创建了一个 Ruby/Rails 实现，没有 HTTP 长轮询作为后备）。

【问题讨论】：

标签： webrtc turn

【解决方案1】：

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

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

【讨论】：

公平地说，当您面前已经有一个完美的车轮时，从头开始并不是一件好事。

【解决方案2】：

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

除了用作回合服务器外，它还提供眩晕功能，但根据我的经验，使用公共 google STUN 总是一个好主意（除了在中国，无法访问）。

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

【讨论】：