WebRTC研究：统计参数之往返时延

前面文章介绍了抖动，今天我们来看下chrome://webrtc-internals/页面中的一个重要统计参数：往返时延（RTT）。

什么是RTT

往返时延(round-trip time，RTT) 是网络请求从起点到目的地然后再回到起点所花费的时长（不包括接收端的处理时间）。RTT是分析网络性能的一个重要指标，我们通常使用RTT来诊断网络连接的速度，可靠性以及拥塞程度。

ping命令是最常见的一种估计往返时延的方法。下面是ping Google的示例，底部显示了rtt的不同表示：最小，平均，最大，平均偏差。

RTT计算方式

WebRTC中目前有两种方式计算RTT：

• 基于媒体流发送端的计算（默认开启）。通过Sender Report（SR）与Receiver Report（RR）携带的信息。
• 基于媒体流接收端的计算。通过RTCP Extended ReportsRTCP（XR）携带的信息。

这两种方式计算RTT的原理都一样。至于为什么需要接收端计算方式，这是因为在一些场景，媒体流传输是单向的，两个端点间一个只发媒体数据，一个只接收，例如客户端与SFU服务器间。假设客户端与SFU服务器上行推流场景，客户端推流，服务端收流，这种场景下作为接收端的服务端并不会发送SR，导致无法计算RTT。于是就有了通过RTCP XR在接收端计算这种方式。

媒体流发送端RTT计算

WebRTC中媒体流发送端RTT的计算是根据SR以及RR中携带的时间信息。这里我们回顾下Sender Report与Receiver Report RTCP两种报文。

Sender Report

• NTP timestamp：64bits。记录着发送该SR的NTP时间戳。

Receiver Report

• last SR timestamp (LSR): 32 bits。64位NTP时间戳中间的32bit（NTP时间戳指绝对时间，相对1900年1月1日00:00:00经历的时间，单位为秒。完整NTP时间戳用64bits表示，左半32bits表示整数，右半32bits表示小数，一般为了紧凑，取中间32bits表示即可，这时整数与小数分别16bits表示）。记录着上次源SSRC_n发送SR的NTP时间，从收到的SR记录的NTP时间戳获取。如果没有收到SR，值为0。
• delay since last SR (DLSR): 32 bits。以1/65536（2^16）秒为单位。记录着上次接收到源SSRC_n发送的SR到当前发送RR的间隔时间。如果没有收到SR，值为0。

计算原理

前面简单介绍了RR中记录的时间信息，下面我们看下如何根据这些时间信息计算RTT。

上图中$T_{0}$时刻媒体流发送端发送SR，SR中记录着send_time_ntp。媒体流接收端$t_{0}$时刻收到SR，$t_{1}$时刻回复RR，RR中记录着：1）从收到的SR中获取的send_time_ntp信息；2）接收端回复RR与收到SR的间隔时间delay_since_last_sr。发送端在$T_{1}$时刻收到回复的RR。可知：
$$delay\_since\_last\_sr = t_{1} - t_{0}\tag{1}$$
$$RTT = T_{1} - T_{0} - (t_{1} - t_{0})\tag{2}$$
$$RTT = receive\_time\_ntp - send\_time\_ntp - delay\_since\_last\_sr\tag{3}$$

代码导读

WebRTC中，发送端首先需要调用ModuleRtpRtcpImpl::OnSendingRtpFrame，这样才能触发发送SR。

接着收到反馈的RR后才能进行RTT计算。WebRTC中发送端RTT计算代码位于RTCPReceiver::HandleReportBlock。
主要代码流程如下：

RTCPReceiver::HandleReportBlock中RTT计算代码如下：

结合前面的公式，上面代码应该很好理解。最后得到一个ms表示的RTT，chrome://webrtc-internals/中RTT的单位是秒。

媒体流接收端RTT计算

RTCP XR报文

WebRTC中媒体流接收端RTT的计算是根据XR中携带的时间信息。这里我们看下XR报文格式：

时间信息存放在report blocks中。report blocks格式如下：

接收端RTT计算主要用到了Receiver Reference Time Report Block与DLRR Report Block这两种report blocks。

Receiver Reference Time Report Block(RRTR)

由媒体流接收端发送。报文格式如下：

• NTP timestamp：64bits。记录着发送该Receiver Reference Time Report Block的NTP时间戳。

DLRR Report Block

由媒体流发送端发送。报文格式如下：

• last RR timestamp (LRR): 32 bits。记录着上次源SSRC_n发送Receiver Reference Time Report Block的NTP时间，从收到的Receiver Reference Time Report Block记录的NTP时间戳获取。如果没有收到，值为0。
• delay since last RR (DLRR): 32 bits。以1/65536（2^16）秒为单位。记录着上次接收到源SSRC_n发送的Receiver Reference Time Report Block到当前发送DLRR Report Block的间隔时间。如果没有收到Receiver Reference Time Report Block，值为0。

计算原理

类似发送端RTT计算，只不过SR变为了Receiver Reference Time Report Block，由媒体流接收端发送。RR变为了DLRR Report Block，由媒体流发送端发送，最后在接收端计算。具体原理这里就不再啰嗦一次了。

代码导读

需要配置接收端ModuleRtpRtcpImpl中RtpRtcpInterface::Configuration的non_sender_rtt_measurement开启XR。
这里以视频为例，配置开启方式如下：

也就是检查SDP中某编码器"a=rtcp-fb"是否含有"rrtr"。例如：

最终这个receiver_reference_time_report配置会传给RtpRtcpInterface::Configuration中的non_sender_rtt_measurement配置项，最后传到RTCPSender中。

媒体流接收端首先发送RRTR，然后收到媒体流发送端反馈的DLRR Report Block进行RTT计算。WebRTC中接收端RTT计算代码位于RTCPReceiver::HandleXrDlrrReportBlock。
主要代码流程如下：

RTCPReceiver::HandleXrDlrrReportBlock中RTT计算代码如下：

代码类似前面发送端RTT计算，就不分析了。

注意事项

WebRTC中RTCP XR总是附在SR或者RR后组成Compound RTCP包发送。

总结

本文简单介绍了RTT以及WebRTC中两种RTT的计算，RTT作为网络性能分析的一个重要指标，在WebRTC中扮演一个很重要的角色，至于具体用途，后面有空结合其它再分析。

参考

[1] RFC3550.https://tools.ietf.org/html/rfc3550.
[2] RFC3611.https://tools.ietf.org/html/rfc3611.