link: 超低延迟实时流媒体传输技术

• 需要网络基础设施
• 目标——零缓冲、低延迟、大带宽
  • 让软件的传输延迟无线接近于物理延迟
  • 充分利用带宽，从利用buffer抗网络抖动到网络不抖动
• 结合应用的QoS来设计协议与算法

协议设计

可靠性

• 大码率场景下，单位吞吐大幅度增长，单帧大小大幅增加，导致丢包数大幅增加
  • 对丢包处理有了更高的要求、
• 低延迟要求需要更好的重传实时性

应用层丢包应是主动丢弃，而不是被动丢弃

• 能力不足丢弃可能会导致产生数倍的重传数据
• 尽可能主动丢，而不是能力不足丢

类FEC vs 重传

• 类FEC
  • 降低丢包造成的delay等影响
  • 浪费带宽，实际导致码率降低
  • CPU利用率高
  • 冗余不足怎么办？
• 重传
  • 带宽利用率高
  • 丢包场景下，会增加delay
• 融合FEC和重传
  • FEC需要与重传结合
  • 低rtt下，带宽优先
  • 高rtt下，冗余优先
  • 先验重传冗余是有可能的
    • 预测丢包，来降低使用FEC
    • 使用FEC可以做先验冗余，尤其是网络不好的情况下

SACK vs NACK

• NACK
  • 判断丢包，逻辑简单。只要接受端发现了hole，就知道丢包了
  • 问题
    • NACK包丢了
    • 发送方收到了NACK包，但是重传包丢了
  • 以上情况，接受端都不知道，只能依赖超时（对低延迟不友好）
    • 超时太大，会导致帧延迟和抖动增大
    • 超时太小，会产生很多重复包，浪费带宽，拥塞恶化
• SACK
  • 抗ACK丢包好
    • 一个ACK包丢了，后面的ACK包可以补上，所有丢任一个ACK不会影响整体判断逻辑
    • SACK有状态，可以做到判断丢包更准备、更实时
  • 判断丢包逻辑复杂
• SACK好于NACK

流控算法

• 快速收敛
• 高利用率

新的目标模型

• 场景不一样了
• 利用率可以不高，例如TCP目标是100，现在90就OK了
• 需要快速收敛
  • 因为没有buffer，当网络较差时，需要快速收敛，否则会卡顿

采集周期和精度很重要

• 超低延迟，需要更细粒度的采集
  • 延迟在100毫秒，采集1秒，即1秒才知道网络卡顿了，那么体验会很差
  • 采集粒度变小。如何保证准确性
• 帧粒度
  • 有逻辑、有状态，易于建模
• 发送端为主，接收端为辅
  • 接收端采集，需要上报，这太慢了
• 没有数据，也有意义

核心是吞吐

• 不基于delay、buffer等，基于吞吐（速率）有更好的收敛性
• 基于buffer
  • buffer易受应用的影响，容易产生扰动
    • 有些应用buffer小
  • buffer达到阈值已经晚了
• 基于丢包
  • 90%的网络卡顿首先时产生延迟抖动，然后丢包
  • 这也晚了
• TCP算法的不公平
  • RTT越大，速率越低？
  • 非瓶颈链路产生的丢包会导致连接速率上不去（丢包不是一个特别好的判断依据）
• 基于速率
  • 速率模型？

传输协议

• TCP与UDP
• UDP更灵活，可以使用FEC，可以实现非可靠传输，主动丢数据
• 客户端无法改内核代码
• 内核代码很难改
• 但是，高码率场景下UDP丢包率高于TCP
• UDP需要SDK支持

使用原则

• 多协议融合

• 低延迟使用TCP

• 高延迟使用UDP

• 高码率使用TCP

• 低码率使用UDP

• TCP做视频传输的劣势，应用层流控和内核拥塞控制会产生冲突

• 一个会话两个连接，一个TCP，一个UDP

多链路实现可靠

• 在不可靠的无线链路上，用多链路实现高可靠