chrome://webrtc-internal如何测量WebRTC往返时间(RTT)及相关问题

两类RTT字段的计算逻辑与准确性对比 #

目前在chrome://webrtc-internal采集的统计数据里，两类RTT指标分属不同的网络层级，测量原理完全独立：

• RTC Remote Inbound RTP Stream 对象的roundTripTime字段
  这是媒体传输层的RTT统计值，计算逻辑绑定单路RTP媒体流的传输过程：
  发送端定期向外发送带绝对NTP时间戳的发送报告（SR），接收端收到SR后，会在后续回传的接收报告（RR）中捎带两个关键信息：收到该SR报文的本地时间、距离发出当前RR报文的剩余驻留延迟。发送端拿到回传的RR后，用当前本地时间减去当初发出对应SR的时间，再扣除接收端的驻留延迟，最终得到的数值就是这路媒体流的端到端RTT。
• RTC IceCandidate Pair 对象的currentRoundTripTime字段
  这是底层网络连接层的RTT统计值，计算逻辑基于STUN连通性探测：
  ICE机制在选定当前生效的候选对后，会周期性在候选对之间发送固定长度的STUN Binding请求，等待收到对应的STUN Binding响应后，计算从发出请求到收到响应的时间差，经过平滑滤波处理后得到的数值就是当前ICE链路的RTT。

两类指标没有绝对的“谁更准确”，适用场景完全不同：

• 如果要评估真实媒体传输的实际体验表现，RTP层的roundTripTime更有参考性——它的测量路径和实际媒体报文的传输路径完全一致，测量结果会直接反映媒体流在网络中的真实往返延迟，不会因为探测包和实际媒体包的路径差异、长度差异引入测量偏差。
• 如果要评估底层网络的基础连通性质量，ICE层的currentRoundTripTime更有参考性——STUN探测包长度固定，不会受到视频帧大小、码率波动的影响，能更纯粹地反映网络链路本身的传输能力。

常见关联问题解答 #

• RTT是否逐帧计算？
  不是。RTT是传输层的网络统计值，和视频帧的处理粒度完全不绑定。它的测量触发仅和RTCP报文发送周期、STUN探测周期挂钩，两类探测的默认触发间隔都在数百毫秒到秒级，远低于常规视频逐帧的处理频率（30fps下每帧间隔仅33ms），根本无法实现逐帧粒度的RTT测量。
• RTT的测量路径是单向还是双向？
  所有上述RTT字段都是基于sender -> receiver -> sender的双向闭环链路计算的。因为WebRTC两端的本地时钟没有做全局同步，根本无法测出准确的单向传输延迟，所有RTT数值本质都是双向回环的时间差。
• RTT测量依赖哪种RTCP报告？
  RTP层的roundTripTime测量，真正的反馈载体是Receiver Report (RR) 接收方报告。发送报告（SR）仅作为测量的时间戳来源，接收端把测量反馈信息搭载在回传的RR中，才能让发送端算出端到端的RTT值。

WebRTC 中VP8编码的GOP长度 #

VP8的GOP（图像组）长度没有固定硬编码值，是编码器结合实时网络状态、视频输入内容动态调整的：

• 常规实时通话场景下，WebRTC内置VP8编码器的默认GOP长度约为1.5秒，对应30fps下约45帧；
• 当检测到网络丢包、带宽不足时，编码器会主动缩短GOP间隔，更快插入关键帧，帮助接收端快速恢复解码；
• 当网络状态稳定、带宽充足时，编码器会适当拉长GOP间隔，减少关键帧带来的码率开销，提升整体编码效率。

内容的提问来源于stack exchange，提问作者Ahmad Alhilal