重温WebRTC中TURN的使用：WebRTC TURN比你想象的更有用

TURN协议是 WebRTC 严重依赖的烦恼之一，但很少有人真正理解它（另一个例子是SDP）。从公共Q/A论坛上大量的相关问题和投诉来看，大多数 WebRTC 开发者甚至不知道 TURN 的真正目的是什么。但让我们面对现实吧，他们为什么要这样做？在一个理想的世界里，我们根本就不需要 TURN 服务器，那么为什么要这么做？

我们对TURN的作用的立场是完全不同的。我们热切地认为，TURN从一个相对不为人知的烦恼，将成为现代云原生WebRTC堆栈中的一个关键成分，而这种转变将对我们提供WebRTC服务的方式产生一些根本性的影响。因此，让我们对这个不为人知的WebRTC英雄有更多的了解!

我们什么时候需要 TURN 服务器？

点对点音频呼叫中的两个 WebRTC 客户端或大规模视频会议中的许多参与者都假定他们和/或媒体服务器之间的直接连接。这意味着，每个对等体必须事先知道它将从哪个 IP 地址和传输端口接收媒体数据包。因此，用于媒体连接的 IP 五元组（源和目的地 IP 和端口以及传输协议）必须在会话建立之前仔细协商，而且当它发生变化时必须明确地重新协商。然后，当媒体路径上有中间盒在执行网络地址转换（NAT、防火墙、非透明代理或负载平衡器）时，考虑到今天的互联网运营现实，接近 100% 的情况下，那么直接 WebRTC 连接就会失败。

这就是 TURN 的意义所在。当较简单的 NAT 穿越协议无法通过已知的五元组建立连接时，对等体就会把TURN作为最后的手段。TURN服务器本质上是一个 UDP 中继器，在两个或多个客户端之间充当中间人，以便让他们通过已知的五元组交换数据，即使这些客户端在 NAT 后面。如果 UDP 不是一个选项，TURN 可以通过纯 TCP 或甚至 TCP/TLS 的 443 端口进行访问，这基本上是所有防火墙都允许的（气隙网络除外）。除了提供连接，TURN还可以在未加密的客户端连接周围添加一个加密的信封，以提高安全性。

配置 TURN 服务

WebRTC 的直接连接要求可以追溯到 VoIP 的早期，尽管此时已基本具有历史意义，但预计在可预见的未来它将继续存在。统计数据表明，大约 20% 的 WebRTC 流量依赖于 TURN，因此必须以某种方式为公共 WebRTC 服务提供 TURN 服务。

在选择 TURN 服务选项之前，需要考虑一组一般准则和最佳实践：

• 成本： TURN 服务可能会变得昂贵，特别是对于按流量收费的大规模 WebRTC 服务。
• 带宽： TURN 是一个网络密集型协议，需要巨大的网络容量。
• 延迟：作为中继，TURN 会增加额外的延迟，特别是当 TURN 服务器物理位置远离客户端和/或媒体服务器时。
• 质量：由于额外的延迟，TURN 可能会降低质量。
• 专业知识：自托管 TURN 服务通常被认为很困难，通常需要专门的人员来配置和维护它。

处理 TURN 固有复杂性的一种方法是将其外包给第三方 TURN 提供商。对于缺乏资源来维护自己的 TURN 服务器的个人，这些供应商提供了用户友好且低维护的选项。您不必担心扩展 TURN 服务，因为 TURN 提供商部署到世界各地的多个数据中心，并且出于同样的原因，访问托管 TURN 服务通常不会带来额外的延迟。当然，缺点是成本：您需要为通过第 3 方 TURN 服务的每个字节的流量付费。此外，您还放弃了对端到端媒体流的控制，如果 TURN 服务提供商无法提供可靠的服务，可能会造成数小时的停机时间。您的相当大一部分媒体将通过其他人的中继传输，这一事实可能会引起安全和隐私问题。

对于拥有必要内部专业知识的大型 WebRTC 提供商来说，自托管 TURN 服务可提供完全控制和定制，并最大限度地降低成本。您可以将 TURN 服务器放置在媒体服务器附近，这可能会减少端到端延迟的宝贵毫秒数。自托管 TURN 确保所有媒体通信都在您自己的网络内，最大限度地提高隐私和安全性。

迈向云原生WebRTC服务

自托管 TURN 服务器的价格优势是以过多的管理负担为代价的，或者至少这是传统观点。这种负担很大程度上源于TURN 服务器是DevOps 术语中所谓的独特雪花(a unique snowflake)的典型示例：专用服务器实例，部署到具有自己的操作系统、共享库和系统实用程序的物理或虚拟机，使用自己唯一的主机名和公共 IP 地址运行，并需要专家人员为其提供手动定制的配置。当独特的雪花发生故障时，工程师必须立即介入排除故障，这可能需要几个小时。扩展 TURN 服务器池是一个重复、容易出错且劳动密集型的过程。更糟糕的是，WebRTC 媒体服务器本身是完全相同类型的独特雪花：我们所说的有关部署和扩展 TURN 服务器的困难的所有内容也同样（如果不是更多）适用于媒体服务器。

WebRTC如何转型到云原生时代？如何使 WebRTC 摆脱手动工作流程、每服务器虚拟机映像、零碎配置，以及最重要的是独特的公共 IP 的影响？这将需要正确虚拟化 WebRTC 组件，从相同的轻量级容器映像运行每个实例，使用相同的配置进行引导，并且不维护持久的内部状态。至关重要的是，所有 TURN 和媒体服务器都必须在私有 IP 地址上运行，否则配置就变成了每个服务器，因为每个服务器都有自己唯一的 IP。

事实证明，WebRTC 向云原生转型的关键是久负盛名的 TURN 协议！第一步是停止将 TURN 视为与媒体服务器完全隔离的独立服务。相反，请将 TURN 服务器和媒体服务器视为单个云原生 WebRTC 媒体平面的两个同等重要的组件。在这个新架构中，TURN服务器成为入口媒体网关 ，为客户端和WebRTC媒体服务器提供NAT穿越设施；回想一下，媒体服务器现在托管在私有 IP 上，因此它们像客户端通常那样依赖 NAT 遍历设施。TURN 让我们对待所有人媒体路径中的网络地址转换步骤，从客户端执行的步骤到将数据包从公共 Internet 转发到媒体服务器的私有 IP 期间由云负载均衡器执行的步骤，作为单个统一的端到端 NAT 和一口气穿越它。

其价值主张是为WebRTC服务提供自动化的生命周期管理和直接的扩展。想要创建新的自助式 TURN 服务器或媒体服务器池？只需编写几行声明性 YAML，将预打包的容器映像部署到 Kubernetes 中，通过公共负载均衡器地址公开服务即可。将您的 YAML 放在 Git 下，瞧，您现在正在使用 GitOps！需要扩大泳池规模吗？只需发出一个kubectl scale命令，或者更好的是，设置 Kubernetes 水平自动缩放器以根据实际负载自动执行相同的操作。不仅仅是横向扩展，纵向收缩也可以自动化，以至于现代 Kubernetes 自动缩放器可以提供“缩放到零”：不会有TURN 服务器或媒体服务器在没有客户端需要时运行。这一切都要归功于根据最佳云原生原则重新架构 WebRTC 提供商堆栈，这是通过单个协议实现的：TURN！

这正是我们称为STUNner的媒体网关所承诺的：一个自动管理和扩展的自助式 TURN 服务器池，并允许您使用完全自动化的云原生工作流程在其后面托管媒体服务器。STUNner 公开一个面向公众的 STUN/TURN 服务器端口，并以受控方式将所有 WebRTC 媒体流量引入 Kubernetes。至关重要的是，STUNner 是一个正确的Kubernetes 网关 API 实现，它恰好实现了 TURN 协议，因此您可以像管理任何 Kubernetes 资源一样管理它：标准的声明性 YAML 配置。

结论

STUNner 不仅仅是另一个 STUN 或 TURN 服务器。您可以这样使用它，但随后您就放弃了它的主要承诺：它使您不必将媒体服务器视为独特的雪花。通过消除手动服务器配置和管理的需要，可以释放资源用于其他关键任务。此外，STUNner 还为企业提供所有媒体通信的升级可观察性、保密性和安全性。其中最好的部分是什么？STUNner 是完全开源的，因此您可以立即尝试。

然而，成功的云原生转型将要求您重新考虑构建和交付 WebRTC 服务的方式。至关重要的是，您不应再将 TURN 视为辅助服务，而应将其视为云原生 WebRTC 转换的关键推动者。这种文化转变正是大多数云迁移失败的地方：如果您不愿意放弃一些旧的假设，您将永远无法利用云所提供的真正好处。

作者：Gabor Retvari
编译自medium.