WebRTC 中RTT实现方法

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标,表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延。
一般认为单向时延=传输时延t1+传播时延t2+排队时延t3
t1是数据从进入节点到传输媒体所需要的时间,通常等于数据块长度/信道带宽
t2是信号在信道中需要传播一定距离而花费的时间,等于信道长度/传播速率(光纤中电磁波的传播速率约为2*10^5 km/s,铜缆中2.3*10^5 km/s)
t3可笼统归纳为随机噪声,由途径的每一跳设备及收发两端负荷情况及吞吐排队情况决定(包含互联网设备和传输设备时延)
综上:时延并无标准值只有经验值。某运营商规定网内路由器间时延1000公里之内<=40ms,2000公里之内<=60ms,3000公里之内<=80ms

如果我们自己来设计一个计算网络时延的算法的话,我们可以这样处理。

大写S代表发送时间,R代表接收时间,D代表延时
                             S(a0)
A------------------------------------------------------ > B  R( b0)

                        S(a0)  D(b0)
A<--------------------------------------------------------B   D(b0) = S(b0) - R(b0)

1,A先发一个数据包,在本地记录下发送时间 S(a0),并把 S(a0)放在数据包中发给B
2,B收到数据包,在本地记录下数据接收时间R( b0),并把数据包发回A,发送时把本地处理延时时间
   D(b0)也记录到数据包中,D(b0) = S(b0) - R(b0)
3,A收到B的回应后,记录到数据接收时间R(a0)
4, rtt = R(a0)  - S(a0) - D0

RTCP中如何计算Rtt

rtcp协议中计算rtt主要依赖发送者报告(SR)和接收者报告(RR)
原理和上面我们自己设计的协议一样。
A先发一个发送者报告给B,上图中的S(a0)在发送者报告中用NTP TimeStamp表示,占用8个字节
B再给A回一个接收者报告,数据包中带上S(a0)和D(b0),在接收者报告中分别用 LSR和DLSR表示
LSR和DLSR都是四个字节。
在这里有一个要注意的地方,SR中时间是8个字节,RR中LSR是四个字节,哪他们如何对应起来呢?
在WebRTC代码中处理如下:

bool ModuleRtpRtcpImpl: astReceivedNTP(
    uint32_t* rtcp_arrival_time_secs,  // When we got the last report.
    uint32_t* rtcp_arrival_time_frac,
    uint32_t* remote_sr) const {
  // Remote SR: NTP inside the last received (mid 16 bits from sec and frac).
  uint32_t ntp_secs = 0;
  uint32_t ntp_frac = 0;
  //部rtcp接收方要最新的发送者报告时间
  if (!rtcp_receiver_.NTP(&ntp_secs,
                          &ntp_frac,
                          rtcp_arrival_time_secs,
                          rtcp_arrival_time_frac,
                          NULL)) {
    return false;
  }
  //因为计算Rtt精确度到毫秒级别就够了,这里把ntp_secs年,月,日这些时间都去掉了,因为rtt不可能达到小时级别的延时,把ntp_frac中毫秒精度以下的也全去掉了
  *remote_sr =
      ((ntp_secs & 0x0000ffff) << 16) + ((ntp_frac & 0xffff0000) >> 16);
  return true;
}

WebRTC中如何计算Rtt
//初始化rtt为0
  int64_t rtt_ms = 0;
  //上一次发送者报告时间
  uint32_t send_time = report_block.last_sr();
  if (!receiver_only_ && send_time != 0) {
   //接收方处理延时
    uint32_t delay = report_block.delay_since_last_sr();
   //当前时间,转换成四字节
    uint32_t receive_time = CompactNtp(NtpTime(*_clock));

    // RTT in 1/(2^16) seconds.
    uint32_t rtt_ntp = receive_time - delay - send_time;
    // 转换成毫秒级别的时间
    rtt_ms = CompactNtpRttToMs(rtt_ntp);
    if (rtt_ms > report_block_info->max_rtt_ms)
      report_block_info->max_rtt_ms = rtt_ms;

    if (report_block_info->num_rtts == 0 ||
        rtt_ms < report_block_info->min_rtt_ms)
      report_block_info->min_rtt_ms = rtt_ms;

    report_block_info->last_rtt_ms = rtt_ms;
    report_block_info->sum_rtt_ms += rtt_ms;
    ++report_block_info->num_rtts;
  }
### WebRTC 中 BBR 拥塞控制的调优最佳实践 #### 1. 带宽估计精度调整 BBR 的核心优势之一在于其带宽估计机制更为精确。然而,在实际应用中,可以通过调整参数来进一步提升带宽估计的准确性。例如,`bottleneck_bandwidth_estimate` 参数决定了 BBR 对瓶颈带宽的估算方式[^1]。开发者可以根据具体的网络环境动态调整该参数,从而更好地适应不同的网络条件。 #### 2. 收敛速度优化 相较于 GCC,BBR 在收敛速度上有显著改进。但在某些高延迟或不稳定网络环境下,仍需对收敛过程进行微调。一种常见方法是通过修改 `probe_rtt_mode` 和 `startup_mode` 的切换阈值实现更快的稳定状态过渡。这有助于减少初始连接阶段可能出现的丢包率波动。 #### 3. 可编程策略支持 基于 GRTN 的实践经验表明,采用可编程策略能够极大增强拥塞控制算法的表现。对于 WebRTC 来说,这意味着可以利用类似的框架定制化 BBR 行为模式。比如,针对不同类型的媒体流(音频 vs 视频),设置差异化的发送速率上限以及缓冲区大小限制[^3]。这种灵活性使得系统能更精准地满足特定应用场景下的 QoS 需求。 #### 4. 测试与验证流程建立 尽管理论分析很重要,但真实世界中的表现往往取决于复杂的交互因素。因此,构建全面而系统的测试方案至关重要。可以从以下几个方面入手: - **模拟多种网络状况**:包括但不限于低延时、高抖动、突发性丢包等情况。 - **收集详尽的日志数据**:用于后续深入剖析性能瓶颈所在之处。 - **持续迭代改进**:依据反馈不断修正模型假设并完善相应配置项。 ```python def adjust_bbr_parameters(bandwidth, rtt): """ 动态调整 BBR 参数以适配当前网络情况 :param bandwidth: 当前检测到的有效带宽 (Mbps) :param rtt: 往返时间 (ms) :return: 新的启动模式和探测 RTT 模式的触发条件 """ startup_threshold = max(0.8 * bandwidth, min(1.5*bandwidth, 10)) probe_rtt_interval = int(rtt / 2) return {"startup": startup_threshold, "probe_rtt": probe_rtt_interval} ``` 上述函数展示了如何根据实时监测的数据自动计算合适的切换点位,进而达到最优效果。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值