15、数据通道的带宽估计与拥塞控制：基于 GCC 的带宽估计、数据通道如何影响音视频传输

聊到数据通道，很多人第一反应就是「发消息用的」。嗯，这话没错，但只说对了一半。真正在实战中，你会发现数据通道和音视频轨道其实是共用同一条传输管道的。你想想看，如果数据通道那边突然发了一个大文件，音视频这边会不会卡？答案是：会，而且很可能会。

所以这一章，我们来聊聊 WebRTC 里最核心的带宽管理机制——GCC（Google Congestion Control），以及数据通道到底怎么影响音视频传输。我在项目中遇到过好几次因为数据通道没控制好，导致视频通话直接崩掉的惨案，嗯，后面我会细说。

15.1 GCC 是什么？为什么它这么重要？

GCC，全称 Google Congestion Control，是 WebRTC 默认的拥塞控制算法。说白了，它的任务就是：动态估算当前网络能承载多少数据，然后告诉编码器和发送端「你悠着点，别发太多」。

我个人习惯把 GCC 比作一个「智能水龙头」。网络好的时候，水龙头开大点，视频清晰度拉满；网络差的时候，水龙头拧小点，保证水流不断，哪怕细一点也行。

15.2 GCC 的两大核心机制

GCC 其实分两部分工作：

1. 基于丢包的拥塞控制（Loss-based）——通过观察 RTT 和丢包率来判断网络是否过载。
2. 基于延迟的拥塞控制（Delay-based）——通过观察数据包到达时间的抖动来判断网络是否开始拥堵。

为什么会需要两种？因为丢包检测太慢了。等你发现丢包的时候，网络其实已经堵了好一阵了。而延迟变化能更早地告诉你「路况开始变差了」。我在项目中遇到过一种情况：丢包率只有 0.5%，但视频已经卡成幻灯片了。后来一查，是延迟在剧烈抖动，GCC 的延迟检测早就报警了，但丢包检测还没反应过来。

15.3 数据通道如何影响音视频传输？

这个问题，我建议你从「带宽竞争」的角度去理解。

WebRTC 的发送端有一个 预估带宽（Estimated Bitrate），这个值由 GCC 动态计算出来。然后，音视频编码器和数据通道会一起瓜分这个带宽。分配规则大致如下：

优先级	流类型	说明
最高	音频	必须保证，否则通话中断
中等	视频	可降质，但不能断
最低	数据通道	可延迟，可丢弃

但这里有个坑：数据通道默认使用的是「可靠」模式。一旦你发了数据，WebRTC 会保证它到达，哪怕重传无数次。这就麻烦了——重传会消耗额外的带宽，而这些带宽本来应该给音视频用。

15.4 数据通道的带宽控制策略

既然数据通道会影响音视频，那我们怎么控制它？我总结了三个实战策略：

策略一：使用部分可靠模式

WebRTC 的数据通道支持两种可靠性设置：

• 可靠（Reliable）：保证送达，但可能重传多次
• 部分可靠（Partially Reliable）：可以设置最大重传次数或超时时间

我个人建议：非关键数据用部分可靠。比如聊天消息、光标位置、标注信息，丢几个包无所谓，别让它们拖累视频。

// 创建部分可靠的数据通道
const dataChannel = peerConnection.createDataChannel('chat', {
  ordered: false,
  maxRetransmits: 3  // 最多重传3次
});

策略二：限制数据通道的发送速率

不要一股脑把所有数据都塞进数据通道。我习惯在应用层做一层限速：

// 简单的令牌桶限速
const rateLimiter = {
  tokens: 1000,      // 每秒最多发 1000 字节
  lastRefill: Date.now(),
  
  canSend(bytes) {
    const now = Date.now();
    const elapsed = (now - this.lastRefill) / 1000;
    this.tokens = Math.min(1000, this.tokens + elapsed * 1000);
    this.lastRefill = now;
    
    if (this.tokens >= bytes) {
      this.tokens -= bytes;
      return true;
    }
    return false;
  }
};

策略三：监听带宽变化，动态调整数据量

GCC 会通过 RTCPeerConnection 的 oniceconnectionstatechange 或自定义的带宽估计回调告诉你当前带宽。你可以根据这个值来调整数据通道的发送策略。

15.5 GCC 的带宽估计流程（SVG 图解）

下面这张图是我自己画的 GCC 带宽估计的核心流程，你看完应该能明白整个链路是怎么跑的：

你看，整个流程其实就是一个闭环：发送端发数据 → 接收端测量延迟和丢包 → 反馈给发送端 → GCC 决策 → 调整发送速率。数据通道的数据也走这个流程，所以它的一举一动都会影响音视频。

15.6 实战建议：如何让数据通道和音视频和平共处？

最后，我总结几条实战建议，都是我在项目中踩过坑之后总结出来的：

• 能不用可靠模式就别用——除非是文件传输这种必须保证完整的场景。聊天消息、状态同步这些，用部分可靠就够了。
• 数据通道的发送速率要主动控制——不要依赖 GCC 去被动降速，那样已经晚了。我习惯在应用层做限速，比如每秒不超过 50KB。
• 监控带宽变化，动态调整——通过 getStats() 获取 availableOutgoingBitrate，然后按比例分配。我一般给数据通道留 5%~10% 的带宽。
• 大文件传输走单独通道——如果一定要传大文件，建议单独建一条 PeerConnection，或者用 HTTP 分片上传，别和音视频抢带宽。

---