我们技术人员喜欢我们的首字母缩略词，但 ICE、STUN、TURN、TURN... 可能有点多。这些东西到底是什么？它们为什么存在，LiveSwitch 如何使用它们？本文的目的是揭开这些技术及其使用的神秘面纱。
最终，实时应用程序的目标是各种客户端之间的高吞吐量、低延迟通信，这些客户端可能（或可能不会）在限制性防火墙规则之后。这意味着以下网络通信协议的首选优先级：
- UDP - 直接在媒体流的源和目标之间。
- UDP - 媒体流的源和目标之间的间接（中继）。
- TCP - 通过 TCP 在媒体流的源和目标之间间接（中继）。
- TCP/TLS - 媒体流的源和目标之间的间接（中继），通过 TCP，具有额外的加密层。
现在我们知道了我们想要什么，这与 STUN、TURN 和 ICE 有什么关系？
UDP - 直接在媒体流的源和目标之间
为了在两个客户端之间建立 UDP 连接，我们需要能够通过防火墙进行协商。为此，给定客户端必须能够以其他客户端的公共 IP 地址和协商端口为目标。但是，大多数客户端不知道自己的公共 IP 地址。这就是 STUN 的用武之地。STUN 是一种用于从 NAT 后面自我发现客户端公共 IP 地址的协议。STUN 服务器允许 Internet 上的计算机确定其面向公众的 IP 地址。STUN 使用 UDP，STUN 服务器通常在端口 3478 上侦听 UDP 请求。对于使用 STUN 的客户端，他们的网络必须允许 UDP 流量。
STUN 告诉客户端它的公共 IP，以便客户端可以反过来将其 IP 传送给其他参与的客户端。假设两个客户端都可以直接路由到对方发现的 IP 地址和端口，则使用直接 UDP 套接字建立通信。这种路由能力是一个很大的假设，因为一些防火墙规则和/或网络设备会阻止直接连接。当这种直接连接失败时，我们会退回到间接（中继）UDP。
UDP - 媒体流的源和目标之间的间接（中继）
在直接连接过程 (STUN) 中，许多防火墙规则不允许协商端口上的传入流量。在这种情况下，我们必须引入一个我们提前知道可用的 IP 和端口。这是一个 TURN 服务器。TURN 是 STUN 的扩展，因此，TURN 服务器通常也侦听端口 3478。但是，TURN 提供 STUN 功能等等。TURN 是一种协议，用于在两个端点之间无法直接连接时通过服务中继媒体流量。TURN 通常通过用户名/密码授权访问服务器。
TURN 的首选操作模式是使用 UDP 套接字。但是，这假设目标网络没有完全主动阻塞 UDP 套接字。这是另一个大假设。当 UDP TURN 失败时，我们回退到 TCP。
TCP - 媒体流的源和目标之间的间接（中继）
此时，UDP 已失败。在这种情况下，我们使用 TCP 卡住了，为了使我们的连接最有可能成功，我们需要假装我们的数据是标准网络流量。因此，我们将把它包装在一个标准的 TCP 数据包中，并使用我们的 TCP TURN 服务器进行中继。这通常在端口 80 上完成，因为这是 Web 流量的标准端口。
TURN over TCP 可以在许多限制性环境中工作，但我们还做了一个假设。我们假设防火墙本身不会检查数据包以确保数据实际上是 Web 流量。我们的第三个大假设。当这失败时，我们回退到 TCP/TLS。
TCP/TLS - 媒体流的源和目标之间的间接（中继）
如果我们已经达到了这一点，那么网络就会受到很大的限制。这仅适用于大型企业网络、银行或医院。在这种情况下，我们将 TCP 数据包装在一个安全的 TCP 套接字中，通过 HTTPS 握手启动连接，因此防火墙无法将此流量与任何其他 Web 流量区分开来，除非使用启发式（例如数据量）或人工通过代理在中间。在实践中，我们从未见过这种失败。
STUN、TURN 和 TURNS 协议
用于通过我们上面概述的网络通信协议实现连接的协议是 STUN、TURN 和 TURNS。我们已经暗示过这一点，但让我们明确定义这些：
- 用于 NAT 的会话遍历实用程序 (STUN) - 用于在两个客户端之间建立直接 UDP 连接。
- Traversal Using Relay around NAT (TURN) - 用于在两个客户端之间建立中继的 UDP 或 TCP 连接。在这里，必须通过 TURN 服务器中继流量以绕过限制性防火墙规则，并且首选是 UDP 而不是 TCP，因为 TCP 保证数据包的有序传递意味着开销对于实时通信来说是不希望的。
- 使用围绕 NAT 的中继进行安全遍历 (TURNS) - 用于在两个客户端之间建立中继的 TCP/TLS 连接。在这里，必须通过 TURN 服务器和 TLS 套接字中继流量，以绕过极其严格的防火墙规则。
至此，您了解了在客户端之间路由媒体流量的首选方法和技术。
那么这一切如何适用于我的应用程序？在 LiveSwitch 内部，我们利用 ICE 协议来管理 STUN、TURN 和 TURNS。继续阅读以了解 ICE 如何实现这一点。
冰简而言之
交互式连接建立 (ICE) 是使用 STUN 和 TURN 在两个端点之间建立连接的标准。ICE 考虑了上述讨论中隐含的所有复杂性，并协调 STUN、TURN 和 TURNS 的管理以 a) 优化连接建立的可能性，以及 b) 确保优先考虑首选网络通信协议。
要了解 ICE，您必须了解“候选者”，即它们是如何收集的，以及它们如何用于在两个对等点之间建立连接。候选者是一个 IP 地址和一个端口。这些候选者由 ICE 协议的实现“收集”，并迭代以找到“可路由”的候选者 - 即客户端可以在其之间路由媒体数据包的候选者。
候选人有四种类型：
- “主机”候选- 直接从本地网络适配器收集，候选主机是 LAN 上计算机的内部 IP 地址和端口。它们只能在同一子网上的对等方之间进行路由。
- “srflx”候选项- 通过 STUN、srflx或服务器自反候选项收集，由本地对等点的公共 IP 地址和协商端口组成。当向远程对等方发出信号时，它们可用于通过 Internet 路由流量，前提是该流量未被防火墙规则阻止。
- “prflx”候选人- 对等反身候选人只是服务器反身候选人的变体。在这种情况下，这些候选者在建立连接后直接由对等方收集。如果正在进行的连接检查确定候选是可路由的，并且当前活动候选上的连接失败，则可以在建立连接后使用对等自反候选。
- “中继”候选- 通过 TURN 收集，中继候选由公共 IP 地址和中继服务器的协商端口组成。当防火墙不允许通过srflx候选直接路由时，这很有用。在这种情况下，远程对等点已向一个候选者发出信号，它可以用来将流量路由到中继服务器，然后中继服务器可以将该流量中继到限制性防火墙后面的对等点。防火墙允许 TURN 服务器将流量路由到对等方，因为对等方向服务器发出了初始请求。通过这种方式，TURN 服务器充当启动对等方用来绕过其防火墙的“中间人”。从上面的讨论中，您知道通过中继候选人进行的通信是最不理想的选择。
现在我们知道候选人是什么，并且了解了不同的类型，很明显，对于实时通信，候选人的偏好是host > srflx / prflx > relay。让我们看看 ICE 如何使用候选人来确保媒体流的最佳路径，同时最大限度地提高连接的可能性。这是其工作原理的简化版本：
- LiveSwitch 客户端 SDK 的 ICE 层收集了它可以收集的所有类型的候选者。如果 STUN、TURN 和 TURNS 服务可用，则如果可能，则始终为 UDP 和 TCP 收集所有候选类型。
- 候选人的排名是host > srflx / prflx > relay和 UDP > TCP。
- 候选人按排名顺序进行测试。第一个建立连接的人是赢家，成为“活跃”的候选人。
- 对候选人进行持续的连通性检查。如果活动候选者未通过连接检查，则使用不同的候选者。同样，如果排名较高的候选人的连通性检查成功，则它成为活动候选人。
了解客户端如何使用 ICE 建立和维护连接非常酷，最好的部分是通过直接在媒体服务器中提供嵌入式 STUN/TURN 功能，LiveSwitch 为您管理所有这些。
为嵌入式 TURN 提供凭据
如上所述，TURN 允许对服务器进行经过身份验证的访问。但是，您不希望任何人通过您的中继服务中继流量。LiveSwitch 的嵌入式 TURN 使用用户名/密码身份验证，但同样，LiveSwitch 使用加密和临时的用户名和密码为您管理。您无需进行任何配置，也无需担心将 TURN 凭据出售给授权客户端。
via https://developer.liveswitch.io/liveswitch-server/guides/what-are-stun-turn-and-ice.html
