延迟（Latency）

什么是延迟？

延迟是数据从发送到接收之间的时间间隔。在视频通话中，它是指从你说话到对方听到你的声音之间的延迟，或者从你做出动作到对方看到这个动作之间的时差。可以把延迟想象成邮件投递时间——带宽是你能发送的包裹大小，而延迟则是包裹送达所需的时间。

低延迟对于自然的对话流程至关重要。当延迟超过 150-200 毫秒时，对话会变得明显别扭——人们开始相互打断，停顿感觉不自然，整个交互给人的感觉不再是"实时"的，而更像是延时播放。

WebRTC 专为低延迟实时通信而设计。传统流媒体协议（如 HLS）可能有 5-30 秒的延迟，而 WebRTC 通常能实现低于 500 毫秒的延迟，在理想条件下甚至可以达到 100-250 毫秒。

延迟 vs. 带宽

这两个概念经常被混淆，但它们测量的是不同的东西：

• 带宽：每秒可以传输多少数据（容量）
• 延迟：数据传输需要多长时间（速度/延时）

你可能遇到高带宽但高延迟的情况（卫星互联网：25 Mbps 但 600 毫秒延迟），也可能遇到低带宽但低延迟的情况（3G 移动网络：1 Mbps 但 50 毫秒延迟）。视频通话需要足够的带宽和低延迟两者兼具。

低带宽会导致画面模糊和卡顿。高延迟会导致对话延迟和尴尬。两者都会降低用户体验，但影响方式不同。

延迟的组成部分

WebRTC 视频通话中的总端到端延迟由多个组成部分构成：

1. 采集延迟（5-20 毫秒）

从麦克风和摄像头采集音视频所需的时间。现代设备通常能达到 10-15 毫秒的采集延迟。

2. 编码延迟（10-50 毫秒）

将原始音视频压缩为编码格式所需的时间。硬件编码器更快（约 10-20 毫秒），而软件编码器较慢（约 20-50 毫秒）。更复杂的编解码器（VP9、AV1）比简单的编解码器（VP8、H.264）增加更多编码延迟。

3. 打包延迟（1-5 毫秒）

将编码数据分解为 RTP 数据包所需的时间。虽然很小但可以测量。

4. 网络延迟（10-300 毫秒）

数据包通过互联网从发送方传输到接收方所需的时间。这通常是最大且变化最大的组成部分：

• 本地网络（同一城市）：5-20 毫秒
• 区域性（同一国家）：20-50 毫秒
• 跨国：50-100 毫秒
• 跨洲际：100-300 毫秒
• 卫星：500-700 毫秒（地球同步轨道）

网络延迟受到物理限制——光在光纤中的传播速度。你无法改善这个物理距离限制，尽管不良的路由或拥塞可能使其比理论最小值更糟。

5. 抖动缓冲延迟（0-100 毫秒）

接收方会短暂缓冲传入的数据包以平滑抖动（数据包到达时间的变化）。自适应抖动缓冲区会根据网络状况动态调整大小——稳定网络通常为 20-60 毫秒，抖动网络会扩展到 100 毫秒以上。

6. 解码延迟（5-30 毫秒）

将接收到的数据包解压缩为原始音视频所需的时间。与编码类似，硬件解码器比软件解码器更快。

7. 渲染延迟（5-20 毫秒）

显示视频帧并通过扬声器播放音频所需的时间。包括保持音视频同步的同步延迟。

总端到端延迟

将所有组成部分相加：

• 最佳情况（本地网络，硬件加速）：50-100 毫秒
• 典型情况（同一地区，良好连接）：100-250 毫秒
• 可接受情况（跨国）：250-400 毫秒
• 较差情况（跨洲际，拥塞）：400-600 毫秒以上

WebRTC 的目标是将所有通话保持在 500 毫秒以下，并在可能的情况下低于 250 毫秒。

往返时间（RTT）

往返时间（RTT）是数据包从发送方到接收方再返回的时间——一个完整的往返。RTT 是单向延迟的两倍（假设路径对称）。

RTT 的重要性：WebRTC 使用 RTCP 反馈机制，其中接收方向发送方报告数据包接收情况。高 RTT 会延迟此反馈，减慢拥塞控制反应和带宽估算。

典型 RTT 测量值：

• 优秀：<50 毫秒 RTT（本地/区域连接）
• 良好：50-100 毫秒 RTT（国内连接）
• 可接受：100-200 毫秒 RTT（跨洲际）
• 较差：>200 毫秒 RTT（卫星，严重拥塞的网络）

你可以使用 ping 命令测量 RTT：ping google.com 会显示到 Google 服务器的 RTT。

可接受的延迟阈值

不同应用对延迟的容忍度不同：

视频会议（最常见）

• 优秀：<100 毫秒（感觉即时，自然对话）
• 良好：100-150 毫秒（几乎察觉不到延迟）
• 可接受：150-250 毫秒（轻微但可容忍的延迟）
• 较差：250-400 毫秒（尴尬的停顿，频繁重叠）
• 无法使用：>400 毫秒（对话变得非常困难）

研究表明，延迟超过 150 毫秒会导致用户参与度显著下降，在需要实时交互的应用中，流失率会增加高达 20%。

实时互动游戏/拍卖

• 要求：<100 毫秒（竞技游戏需要近乎即时的响应）
• 可接受：100-150 毫秒（休闲游戏）
• 较差：>150 毫秒（明显的输入延迟影响游戏体验）

实时广播/网络研讨会

• 可接受：<1000 毫秒（单向通信，要求不那么严格）
• WebRTC 优势：200-500 毫秒（支持与主播的聊天互动）
• 传统流媒体：5000-30000 毫秒（HLS、DASH——太慢无法互动）

远程医疗/远程咨询

• 要求：<200 毫秒（医疗专业人员需要自然对话以进行有效诊断）

高延迟的原因

地理距离

光在光纤中的传播速度约为 200,000 公里/秒（真空中速度的 2/3）。纽约到伦敦（5,500 公里）的理论最小延迟为单向 27.5 毫秒。加上路由开销，实际最小值为单向 50-70 毫秒，RTT 为 100-140 毫秒。这是物理限制——除了选择离用户更近的服务器外，你无法改善它。

网络拥塞

当路由器和交换机过载时，数据包会在队列中等待，增加延迟。这在高峰时段（住宅区的晚上）或共享网络（公共 WiFi、办公网络）上尤其常见。

不良路由

互联网路由并不总是最优的。你的数据包可能通过多个 ISP 和对等点走一条迂回的路线。使用 CDN 或边缘网络可以提高路由效率。

WiFi vs. 有线

WiFi 比有线以太网增加 5-30 毫秒的延迟，还会增加额外的抖动。为了获得最低延迟，尽可能使用有线连接。

移动网络

蜂窝网络的延迟比固定宽带更高且更不稳定：

• 5G：10-30 毫秒（最佳情况）
• 4G/LTE：30-70 毫秒
• 3G：100-200 毫秒

编解码器复杂度

更先进的编解码器（VP9、AV1）压缩效果更好，但编码/解码时间更长。为了获得最低延迟，使用较简单的编解码器（VP8、H.264）并启用硬件加速。

大型抖动缓冲区

当网络抖动时，接收方会增加缓冲区大小以平滑数据包到达的变化。这是用延迟换取流畅度——更大的缓冲区意味着更高的延迟，但故障更少。

降低延迟

1. 使用边缘服务器/CDN

在靠近用户的边缘位置部署 WebRTC SFU 服务器。不要将所有流量路由到中央数据中心，而是使用地理分布式服务器。Cloudflare、AWS CloudFront 和专门的 WebRTC CDN 提供边缘部署。

2. 优化网络路径

• 尽可能使用网络之间的直接对等
• 避免通过多个 ISP 的不必要跳转
• 对于企业应用，考虑使用 SD-WAN 或专用网络骨干

3. 硬件加速

为 H.264 和 H.265 等编解码器启用硬件编码/解码。这将编码延迟从 40-50 毫秒减少到 10-20 毫秒，并降低功耗。

4. 最小化抖动缓冲区大小

自适应抖动缓冲区会根据网络状况动态调整。在抖动较低的稳定网络上，缓冲区可以缩小到 20-30 毫秒。确保你的 WebRTC 实现使用自适应缓冲而不是固定的大缓冲区。

5. 优先使用 UDP 而非 TCP

WebRTC 默认使用 UDP，其延迟低于 TCP，因为它不等待重传。只有在防火墙阻止 UDP 时才回退到 TCP。

6. 有线连接

尽可能使用有线以太网而不是 WiFi。WiFi 会增加延迟和抖动，特别是在拥挤的信道或信号强度较弱时。

7. 降低编码复杂度

将编码器配置为较低复杂度/更快的预设。你会牺牲一些压缩效率，但获得更低的延迟。对于实时通话，速度比最大化压缩更重要。

测量延迟

网络 RTT（Ping）

简单工具：ping [服务器地址] 显示到服务器的往返时间。这只测量网络延迟，而不是端到端 WebRTC 延迟。

WebRTC Stats API

在 RTCPeerConnection 上使用 getStats() 访问：

• currentRoundTripTime：通过 RTCP 测量的 RTT
• jitterBufferDelay：数据包在抖动缓冲区中停留的时间
• totalEncodeTime：累计编码时间
• totalDecodeTime：累计解码时间

端到端延迟测试

对于真正的端到端测量，使用回环测试：播放一个已知的音频信号，通过 WebRTC 录制它，并测量时间差。这捕获了所有延迟组成部分，包括采集、编码、网络、解码和渲染。

浏览器工具

• Chrome：chrome://webrtc-internals 显示 RTT 图表和时序统计
• Firefox：about:webrtc 显示包括 RTT 在内的连接统计

延迟 vs. 质量权衡

较低的延迟有时会与其他目标冲突：

• 抖动缓冲区大小：小缓冲区 = 低延迟但更多故障。大缓冲区 = 更高延迟但播放更流畅
• 前向纠错（FEC）：添加冗余以在不重传的情况下从丢包中恢复，但会增加 20-50 毫秒的延迟
• 编解码器选择：简单编解码器（VP8）= 更低延迟。复杂编解码器（AV1）= 更高延迟但每比特率质量更好

对于互动视频通话，优先考虑低延迟。对于广播或录制，你可以接受更高的延迟以换取更好的质量或纠错。

结论

延迟是自然对话的隐形敌人。虽然带宽获得了大部分关注，但延迟往往决定了视频通话是感觉"真实"还是令人沮丧地延迟。WebRTC 的低延迟设计——低于 500 毫秒，通常为 100-250 毫秒——正是使自然、互动通信成为可能的原因，而旧的流媒体协议根本无法做到这一点。

理解延迟可以帮助你诊断连接问题、优化基础设施并设定现实的期望。地理距离施加了无法克服的物理硬限制。但减少来自低效路由、大缓冲区或慢速编码的不必要延迟可以极大地改善用户体验。

在 2025 年，随着用户对实时响应的期望不断提高，优化 WebRTC 延迟不是可选的——它对于提供有竞争力、引人入胜的产品至关重要。

参考资料

• WebRTC Low Latency: The Ultimate Guide to Real-Time Streaming in 2025 - VideoSDK
• How to Reduce WebRTC Latency in Your Applications - BlogGeek.me
• Understanding WebRTC Latency: Causes, Solutions, and Optimization Techniques - VideoSDK
• Calculating True End-to-End RTT - webrtcHacks
• What is Round-trip Time and How Does it Relate to Network Latency? - Cyara
• Jitter vs. Latency: Understanding Network Performance in 2025 - VideoSDK
• What is Jitter and How to use Jitter Buffer to reduce jitter? - TRTC
• Measuring WebRTC Call Quality - Part 1 - 100ms