videocalling
glossary.backToGlossary
带宽（Bandwidth）

带宽（Bandwidth）

技术

每秒可通过网络连接传输的数据量

什么是带宽？

带宽是数据通过网络连接传输的最大速率,通常以兆比特每秒（Mbps）或千比特每秒（Kbps）为单位。可以把带宽想象成水管——管道越宽，一次能流过的水（数据）就越多。

在视频通话中，带宽决定了你能发送和接收的最高质量。你的视频质量最终受限于你和对等点之间路径上最窄的带宽瓶颈——无论是你家的上传速度、ISP 的网络，还是接收者的下载速度。

与延迟（衡量延时）或抖动（衡量变化性）不同，带宽衡量的是容量。你可以有高带宽但高延迟（卫星互联网），或低带宽但低延迟（3G 移动网络）。对于 WebRTC 视频通话，你需要足够的带宽和低延迟才能获得良好体验。

上传与下载带宽

大多数互联网连接是非对称的——下载速度远快于上传速度。这是有意为之：ISP 假设用户消费的内容多于创建的内容（流媒体 Netflix、浏览网站）。

对于视频通话，两个方向都重要：

  • 上传带宽：决定你发送给他人的视频/音频质量。这通常是视频通话的限制因素，因为家庭互联网上传速度远低于下载速度
  • 下载带宽：决定你可以接收多少流以及以什么质量接收。在群组通话中，你同时下载多个流

例如，典型的有线互联网连接可能提供 200 Mbps 下载但只有 10 Mbps 上传。在一对一视频通话中，你会没问题。但在 10 人会议中，你需要下载最多 9 个流（可能总共 20+ Mbps），同时上传 1 个流（约 2-3 Mbps）。你的上传会没问题，但下载可能会吃力。

按质量级别的带宽需求

以下是 2025 年 WebRTC 视频通话的典型带宽需求：

仅音频

  • 低质量：8-16 Kbps（窄带语音，电话级质量）
  • 标准质量：32-64 Kbps（宽带语音，良好质量语音）
  • 高质量/音乐：64-128 Kbps（全频段立体声，音乐质量音频）

Opus 编解码器根据可用带宽在这些范围内自动调整。

视频：360p（标清）

  • 最低：300-500 Kbps
  • 推荐：500-1000 Kbps
  • 用例：移动通话、网络条件差、多参与者

视频：720p（高清）

  • 最低：1-1.5 Mbps
  • 推荐：1.5-2.5 Mbps
  • 用例：标准视频通话、大多数桌面应用

视频：1080p（全高清）

  • 最低：2-3 Mbps
  • 推荐：3-5 Mbps
  • 用例：高质量通话、专业会议、演示

屏幕共享

  • 静态内容：300-800 Kbps（文档、幻灯片）
  • 视频内容：1-3 Mbps（观看视频、动画）
  • 高细节：2-4 Mbps（CAD、带细微文本的设计工具）

现实世界平台需求（2025 年）

使用 WebRTC 的主要平台公布了它们的带宽建议：

  • Zoom：720p 群组通话需要 2.6 Mbps 上传 / 1.8 Mbps 下载；1080p 高清需要 3.8 Mbps 上传 / 3.0 Mbps 下载
  • Microsoft Teams：高清视频通话最低需要 1.5 Mbps 上传和下载；基本功能绝对最低 500 Kbps
  • Google Meet：建议 3.2 Mbps 上传和下载以获得最佳体验

这些是指导值。实际使用量根据编解码器效率、参与者数量以及是否使用 SFU 架构而变化。

群组通话和 SFU 架构

在点对点通话中，带宽随参与者线性扩展。在 5 人 P2P 通话中，你会上传 4 个流并下载 4 个流——对于高清质量可能需要 8-10 Mbps 上传和 8-10 Mbps 下载。这就是为什么 P2P 无法扩展到 4-5 个参与者以上。

使用 SFU（选择性转发单元），你上传一次到服务器并下载 N-1 个流：

  • 10 人会议：上传 2-3 Mbps（你的视频），下载 18-27 Mbps（9 个流 × 每个 2-3 Mbps）
  • 50 人网络研讨会：上传 2-3 Mbps，如果查看所有流下载可能 98-147 Mbps

当然，没有人同时查看 50 个视频流。SFU 使用联播和选择性转发仅发送你正在主动查看的流，通常将下载限制为最多 6-12 个流（画廊视图中的可见图块）。

自适应比特率（ABR）

WebRTC 不使用固定比特率。相反，它通过自适应比特率流根据网络条件持续调整编码比特率。

工作原理：

  1. 你的浏览器以初始比特率发送视频（例如 2 Mbps）
  2. 接收者发送 RTCP 反馈，指示数据包丢失、延迟和抖动
  3. 你的浏览器的带宽估计器分析此反馈
  4. 如果网络拥塞（数据包丢失、延迟增加），比特率降低
  5. 如果网络有容量（无丢失、延迟稳定），比特率增加
  6. 编码器调整输出比特率，动态改变视频质量

这持续发生，通常每秒多次。结果：WebRTC 自动找到当前网络条件下可持续的最高质量。

带宽估计（BWE）

WebRTC 使用复杂的带宽估计算法来确定可用网络容量。最重要的是 Google 拥塞控制（GCC），它结合了两种方法：

基于延迟的估计

测量数据包之间的单向延迟变化。当网络队列填满（拥塞）时，延迟在数据包丢失发生之前就会增加。通过检测延迟增加趋势，GCC 可以先发制人地降低比特率，完全避免数据包丢失。

基于丢失的估计

监控数据包丢失百分比。当数据包丢失时，算法假设网络已饱和并降低比特率。基于丢失的估计是基于延迟的估计不足时的降级方案。

传输范围拥塞控制（TWCC）

现代 WebRTC 使用 TWCC（RFC 8888），发送方为所有 RTP 数据包添加序列号，接收方通过 RTCP 反馈报告每个数据包到达的时间，发送方使用此时间信息准确估计带宽。

TWCC 提供精确的拥塞检测，因为它看到确切的数据包到达时间，允许亚秒级响应网络变化。

带宽探测

当你的应用没有发送太多数据时（仅音频通话、暂停视频），WebRTC 无法估计可用带宽，因为没有流量可测量。这称为应用限制区域（ALR）。

为了保持准确的带宽估计，WebRTC 发送填充数据包——仅用于探测的空 RTP 数据包。这些探测生成人工流量以测试网络是否能处理更高的比特率，即使实际数据传输很少也能保持带宽估计的最新状态。

探测是保守和轻量的（通常为 255 字节数据包），以避免不必要地浪费带宽。

常见带宽问题

上传带宽不足

症状：其他人看到你的低质量或冻结视频。你这边的视频看起来很好。

原因：你的上传速度无法支持你试图发送的视频质量。对于具有非对称速度（高下载、低上传）的有线/DSL 连接很常见。

解决方案：降低视频分辨率（1080p → 720p → 360p），降低帧率（30 fps → 15 fps），或确保没有其他应用使用上传带宽（云备份、文件上传）。

下载带宽不足

症状：你看到来自他人的像素化、冻结或缺失视频。他们报告视频看起来很好。

原因：你的下载速度无法同时接收多个视频流，尤其是在群组通话中。

解决方案：减少可见视频图块数量（隐藏非发言人），通过联播层选择请求较低分辨率流，或为某些参与者切换到仅音频。

带宽竞争

症状：当你家里其他人开始流媒体 Netflix、下载文件或玩游戏时，视频质量下降。

原因：多个应用竞争同一互联网连接。

解决方案：在路由器中使用服务质量（QoS）规则优先处理视频通话流量，或在重要通话之外安排高带宽活动。

低带宽优化

当带宽严重受限时，几种优化有助于保持可用质量：

  • 降低帧率：15 fps 而不是 30 fps 节省约 50% 带宽，对说话的头部感知影响极小
  • 使用高效编解码器：VP9 或 AV1 在低比特率下比 VP8 或 H.264 提供更好的质量
  • 仅音频降级：当视频变得无法使用（<300 Kbps）时，完全禁用视频并使用仅音频
  • 降低分辨率：360p @ 500 Kbps 看起来比 720p @ 500 Kbps 更好（分辨率的比特率不足）
  • 禁用视频背景：虚拟背景需要额外的处理和带宽
  • 关闭带宽密集型应用：停止云同步、关闭流媒体服务、暂停下载

监控带宽使用

你可以在 WebRTC 应用中监控实时带宽使用：

  • Chrome：导航到 chrome://webrtc-internals 并查看显示发送/接收字节数、比特率和带宽估计的图表
  • Firefox：打开 about:webrtc 以获取类似统计信息
  • 应用 API：在 RTCPeerConnection 上使用 getStats() 以编程方式访问带宽指标

要观察的关键指标：

  • bytesSent / bytesReceived：传输的总数据
  • availableOutgoingBitrate：估计的可用上传带宽
  • availableIncomingBitrate：估计的可用下载带宽
  • totalPacketSendDelay：指示拥塞的队列延迟

带宽估计中的机器学习

截至 2025 年，先进的 WebRTC 实现正在将机器学习纳入带宽估计。Meta（Facebook）公开讨论了他们基于机器学习的方法：

  • 学习网络行为模式（每日带宽波动、WiFi vs 蜂窝特性）
  • 在传统算法检测到之前预测拥塞
  • 更快适应变化的条件
  • 减少比特率振荡（更少的质量波动）

虽然尚未成为浏览器实现的标准，但基于机器学习的 BWE 代表了拥塞控制的未来方向。

最低带宽建议

对于 2025 年可靠的 WebRTC 视频通话：

  • 一对一通话：2 Mbps 上传 / 2 Mbps 下载（720p 质量）
  • 群组通话（4-6 人）：3 Mbps 上传 / 8 Mbps 下载
  • 群组通话（10+ 人）：3 Mbps 上传 / 15 Mbps 下载
  • 绝对最低（任何通话）：500 Kbps 上传 / 500 Kbps 下载（质量下降）

这些假设使用联播的 SFU 架构。点对点或 MCU 架构有不同的要求。

总结

带宽是视频通话行驶的高速公路。太窄，就会发生拥塞——导致像素化视频、冻结或完全连接失败。WebRTC 的自适应比特率算法努力充分利用任何可用带宽，动态调整质量以匹配网络条件。

与延迟或抖动（你无法轻易控制）不同，带宽是你通常可以改善的：升级互联网套餐、减少竞争流量、选择高效编解码器，或降低视频分辨率。理解你的带宽限制并适当配置 WebRTC 对于提供可靠的视频通话体验至关重要。

在 2025 年，随着全球家庭互联网速度的持续提高，带宽不再像以前那样经常成为瓶颈。但对于移动用户、农村地区或发展中市场的用户，带宽管理对于可用的视频通话仍然至关重要。

参考资料

相关术语

编解码器（Codec）延迟（Latency）抖动（Jitter）丢包（Packet Loss）
glossary.backToGlossary