TURN Server：是什么、如何工作及在何处使用

什么是 TURN Server

TURN Server（Traversal Using Relays around NAT）— 是一种网络服务，定义于 RFC 5766 并在 RFC 8656 中更新，当由于 NAT 或防火墙限制而无法建立直接 P2P 连接时，它在两个客户端之间中继 UDP 和 TCP 流量。在 WebRTC 架构中，TURN 服务器作为最终的备用机制，确保在任何网络条件下都能建立连接。

与 STUN 只告知客户端其外部地址不同，TURN 服务器积极参与数据传输。每个对等点与 TURN 服务器建立连接，并将其媒体数据发送给它。TURN 服务器再将数据转发给另一个对等点。结果是对等点之间没有直接连接——所有流量都经过中继服务器，即使在最严格的 NAT 限制下也能保证送达。

TURN 协议

TURN 是 STUN 协议的扩展。TURN 消息使用相同的 20 字节头部和属性机制。关键区别在于 TURN 定义了新的消息类型（Allocate、Refresh、Send、Data、CreatePermission、ChannelBind）以及管理中继分配所需的属性。客户端通过 Allocate 消息在 TURN 服务器上创建分配（allocation），获取中继传输地址（relayed transport address），并使用该地址通过服务器发送和接收数据。

TURN 服务器如何工作

TURN 服务器按照以下步骤序列工作。客户端发送带有身份验证（username、credential）的 Allocate 请求。服务器验证凭据并创建一个分配——将中继地址（TURN 服务器上的 IP:端口）临时绑定到客户端。服务器返回带有 relayed transport address 的 Allocate 响应——其他对等点将通过 TURN 服务器向该客户端发送数据所使用的地址。

创建分配后，客户端可以通过 Send Indication 消息或通过通道（ChannelBind）经由 TURN 服务器发送数据。当从客户端接收数据时，TURN 服务器检查权限（permissions）并将数据中继到目标对等点。为了接收传入数据，客户端必须首先为其期望接收数据的对等点创建权限，否则 TURN 服务器将丢弃传入的数据包。权限通过 CreatePermission 消息指定对等点的 IP 地址来创建。

分配与生存时间

TURN 服务器上的分配具有有限的生存时间——默认为 10 分钟。客户端必须定期发送 Refresh 请求以延长分配。生存时间以秒为单位在 LIFETIME 属性中指定。如果没有 Refresh，服务器将删除分配并释放中继地址。建议的刷新间隔为 5 分钟（300 秒），以防止 Refresh 数据包丢失。

在 WebRTC 中配置 TURN 服务器

在 WebRTC 中，TURN 服务器通过 RTCPeerConnection 配置中的 iceServers 数组进行配置。TURN 服务器可以使用 UDP、TCP 或 TLS 传输。身份验证通常使用在应用服务器上生成且具有有限有效期的临时凭据（TURN credentials）。

让我们看一个在 JavaScript 中通过 HMAC-SHA1 令牌进行身份验证的 TURN 服务器配置示例。

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

在此示例中，TURN 服务器与 STUN 服务器一起在统一的 ICE 配置中指定。ICE 过程将首先尝试 host 候选者以及从 STUN 获取的 srflx 候选者。如果无法建立直接连接，ICE 将自动切换到从 TURN 服务器获取的 relay 候选者。参数 iceTransportPolicy: "all" 允许 relay 候选者——替代值 "relay" 禁止除 TURN 之外的任何候选者，这有助于测试。

TURN 服务器身份验证

为防止未经授权的使用，TURN 服务器需要身份验证。标准方法是使用在应用服务器上通过 HMAC-SHA1 生成的限时凭据（time-limited credentials）。应用服务器使用 TURN 服务器的密钥加密用户名，并将 username 和 credential 返回给客户端。客户端将它们传递给 RTCPeerConnection 配置，浏览器在 TURN 服务器上创建分配时使用它们。凭据过期后，客户端从应用服务器获取新凭据。

TURN vs STUN：对比

TURN 和 STUN 解决类似的 NAT 穿越问题，但在机制和成本上有根本区别。TURN 中继流量，充当中介，而 STUN 仅帮助确定外部地址以建立直接 P2P 连接。两者之间的选择取决于对等点的 NAT 类型和性能要求。

在实践中，TURN 服务器仅用于 P2P 不可行的连接。根据 Google 的数据（WebRTC statistics, 2023），约 15–20% 的 WebRTC 连接需要 TURN 中继。其余 80–85% 通过 STUN 或本地 host 候选者建立。在设计应用程序时，如果受众包括来自企业网络和 NAT 限制严格区域的用户，应预留 TURN 流量预算，约为总媒体数据量的 15–20%。

TURN 服务器的成本与性能

TURN 服务器消耗大量资源，因为所有媒体流量都经过它。每个使用 TURN 中继的活动通话都会占用相当于媒体流量总带宽（传入 + 传出流）的服务器带宽。对于高清（720p）视频通话，每个方向可能需要 1.5–2.5 Mbps，即通过 TURN 服务器的总流量为 3–5 Mbps。

部署 TURN 基础设施有几种选择。免费的公共 TURN 服务器不推荐用于生产环境，因为缺乏质量和安全保障。商业提供商（Twilio Network Traversal Service、Xirsys、Metered）提供按流量付费的 TURN 服务——典型成本为每 GB $0.005–0.02。基于 coturn（开源 TURN 服务器）的独立部署需要具有足够带宽的服务器和监控配置。

• coturn — 最流行的开源 TURN 服务器，用于大多数生产系统，支持 UDP、TCP、TLS 和 DTLS 传输。
• Twilio — 商业服务，提供 TURN + STUN，按流量计费，通过临时令牌进行身份验证。
• Xirsys — 专业的 TURN 提供商，拥有全球服务器网络和详细的使用分析。
• Metered.ca — TURN 服务，每月免费额度高达 50 GB，超额部分按量计费。
• Self-hosted coturn — 完全控制配置，但需要服务器管理和可用性监控配置。

在选择 TURN 服务器解决方案时，应考虑用户地理位置、流量成本和安全性要求。对于拥有数千个并发通话的应用程序，在带宽充足（1+ Gbps）的服务器上自托管 coturn 可能比商业提供商更经济。对于只有几十个用户的小型项目，商业 TURN 服务由于无需管理和监控成本而更受欢迎。