18、TURN服务器优化：TURN协议开销、带宽配额、多TURN服务器的负载均衡

聊到WebRTC的最后一公里，TURN服务器往往是那个“又爱又恨”的角色。爱它，是因为没有它，很多对称NAT后面的用户根本连不上；恨它，是因为它太“吃”资源了——带宽、CPU、流量费用，样样都是钱。

我最早接触TURN优化，是在一个跨国视频会议项目里。当时服务器带宽费用高得吓人，老板天天盯着账单看。后来我花了两周时间，把TURN协议的开销、配额和负载均衡全捋了一遍，才把成本降下来。今天我就把这些经验拆开来讲。

18.1 TURN协议的开销到底在哪？

很多人以为TURN就是个“中转站”，数据包进来再出去，没什么损耗。其实不然。TURN协议本身就有不小的开销，主要体现在三个方面：

• 头部开销：每个TURN消息都有STUN头部（20字节），再加上TURN特有的ChannelData头部（4字节）或Send/Data指示的额外字段。对于小包（比如音频20字节一包），这个开销占比非常可观。
• 信道复用开销：TURN支持Channel绑定，但绑定过程需要额外的信令交互。我见过一些实现，每几秒就重新绑定一次，白白浪费带宽。
• 应用层分片：当UDP包超过MTU时，TURN不会自动帮你分片，需要应用层自己处理。处理不好，就会导致重传和延迟。

我个人习惯的做法是：优先使用ChannelData而非Send/Data指示。ChannelData的头部只有4字节，而Send/Data指示的头部至少36字节。对于高频小包场景，这个优化能省下10%以上的带宽。

18.2 带宽配额：别让一个用户拖垮整个集群

没有带宽配额，就像没有红绿灯的十字路口——早晚要出事。我在项目中遇到过这样的情况：一个用户开了4K视频流，直接把TURN节点的上行带宽占满，导致其他几十个用户全部卡顿。

带宽配额的设计，我建议从三个维度来考虑：

维度	说明	推荐值
单用户配额	每个用户最多能使用的带宽	上行2Mbps，下行4Mbps（视频会议场景）
单节点配额	单个TURN服务器实例的总带宽上限	节点网卡带宽的70%（留30%给控制面和突发）
全局配额	整个TURN集群的总带宽上限	根据出口带宽和成本预算设定

实现带宽配额，我推荐在TURN应用层做流量整形，而不是依赖底层网络限速。原因很简单：应用层能感知媒体类型（音频还是视频），可以优先保证音频包的传输。底层限速是“一刀切”，音频和视频一起丢，通话质量直接崩。

18.3 多TURN服务器的负载均衡

单台TURN服务器扛不住大规模并发，这是必然的。多TURN服务器的负载均衡，说白了就是解决两个问题：谁来接和怎么接。

先看一张我常用的架构图：

这张图里，我用了两层调度：信令/调度服务负责给客户端分配TURN地址，负载均衡器负责监控各节点的健康状态和负载。客户端拿到地址后，直接与对应的TURN节点建立连接，媒体流不再经过调度层。

18.4 负载均衡策略：不只是“轮询”

常见的负载均衡策略有几种，我分别说说它们的适用场景：

• 轮询（Round Robin）：简单，但不考虑节点实际负载。如果某个节点刚好在处理一个大流，轮询还是会继续往它身上堆。
• 最少连接（Least Connections）：比轮询好一些，但连接数多不代表带宽大。一个用户可能只开音频，另一个用户开4K视频，连接数一样，负载天差地别。
• 基于带宽的负载均衡：这是我个人最推荐的方式。每个TURN节点定期上报自己的当前带宽使用率，调度服务根据这个数据做分配。比如节点A用了80%带宽，节点B只用了30%，新用户就优先分配给B。

我曾经踩过一个坑：健康检查接口做得太重，每次查询都要扫描所有活跃会话，导致TURN节点CPU飙升。后来我改成异步统计——节点内部每5秒汇总一次数据，缓存到内存里，健康检查接口直接读缓存，毫秒级响应。

18.5 会话保持与故障转移

负载均衡还有一个容易被忽略的问题：会话保持。用户一旦连接到某个TURN节点，后续的媒体流必须始终走同一个节点，不能随意切换。否则，NAT绑定会失效，连接直接断掉。

我的做法是：在调度服务里维护一个用户-节点映射表（用Redis或本地缓存都行）。用户第一次请求TURN地址时，调度服务根据负载策略选一个节点，把映射关系存下来。后续该用户的所有请求，都直接返回同一个节点地址。

故障转移的触发条件，我建议用连续三次健康检查失败，而不是一次失败就切换。网络抖动是常态，一次失败就切换会导致频繁的“乒乓效应”。

18.6 实战：一个简单的带宽配额实现

最后，我贴一段伪代码，展示如何在TURN应用层做带宽配额控制。这段代码基于coturn的插件机制（如果你用其他TURN服务器，思路类似）：

// 伪代码：TURN带宽配额中间件
class BandwidthQuotaMiddleware {
    constructor() {
        this.userQuota = 2 * 1024 * 1024; // 单用户2Mbps
        this.nodeQuota = 100 * 1024 * 1024; // 单节点100Mbps
        this.userStats = new Map(); // userId -> {upBytes, downBytes, lastReset}
    }

    onDataIn(userId, bytes) {
        const stats = this.getOrCreateStats(userId);
        stats.upBytes += bytes;
        
        // 检查单用户上行配额
        if (stats.upBytes > this.userQuota) {
            this.dropPacket(userId, 'up'); // 丢包或降级
            return false;
        }
        
        // 检查节点总配额
        if (this.getNodeTotalBytes() > this.nodeQuota) {
            this.dropPacket(userId, 'up');
            return false;
        }
        
        return true; // 放行
    }

    getOrCreateStats(userId) {
        if (!this.userStats.has(userId)) {
            this.userStats.set(userId, { upBytes: 0, downBytes: 0, lastReset: Date.now() });
        }
        return this.userStats.get(userId);
    }

    getNodeTotalBytes() {
        let total = 0;
        for (const stats of this.userStats.values()) {
            total += stats.upBytes + stats.downBytes;
        }
        return total;
    }
}

这段代码的核心逻辑很简单：每个用户维护一个计数器，超过配额就丢包。实际生产环境里，你还需要加一个定时重置的逻辑（比如每秒重置一次），否则配额用完了就永远不能发数据了。

嗯，关于TURN服务器的优化，今天就聊到这里。带宽配额和负载均衡这两块，说白了就是“管好资源”和“分好任务”。你只要把这两件事做好了，TURN集群的稳定性和成本控制就基本稳了。

---