注：本文仅关注于技术的实现，简单证明其可行性，但也因能力有限不能通过实验验证技术的优越性，故不讨论测试部分，详见参考资料；

背景问题

  在直播服务等高时效性场景中，如果单纯依靠 On-Off 模式进行丢包恢复，即当发现数据包丢失后，如 CDN 会立刻重传丢失的数据，在这个过程中存在三个主要的问题：

  1. 通常为了保证时效性，重传的数据包会有冗余的副本数量，避免出现数据包连续丢失的问题，但当网络抖动导致相当一部分数据丢包后，重传的大量副本可能引发网络阻塞；
  2. 恢复机制的 低延迟 依赖于重传时间和接收端的 ack，与第一个问题相对立，即理论上想解决当前问题，则会无限放大第一个问题（冗余的副本数量会无限放大）；
  3. 队首阻塞问题，重传的数据需要在网络中按顺序传输，如果丢失了队首的数据，则整个队列的数据都会被阻塞在接收端的内核缓冲区中；

  核心在于重传的丢失导致丢包恢复缓慢；

商业 CND、客户端、服务端：

  服务端负责优化数据传输性能，CDN 服务商可控制服务端的发送策略，无法修改客户端逻辑；

  商业 CDN 是直播传输的中间层，负责将直播数据从服务端分发给客户端；

解决方案

  通过实现 AutoRec 的增强丢包恢复机制（基于 quic），核心理论在于在 off 期间，基于一定的策略 重新注入 少量副本 以尝试 更快 恢复丢失数据包；而策略部分是通过 在线学习 机制，基于网络当前的服务质量（QoS），即丢包率、延迟、带宽、抖动参数；

  详细来说，有两步：

  • 冗余适配：在线学习当前的丢包动态，确定重传的冗余副本数，满足 最小化带宽消耗的同时，减少丢包恢复延迟（少 & 够）；
  • 重传控制：通过重传队列管理，每个连接都有一个重传队列，丢失数据包会被追加到队列末尾等待重传，数据结构：Data_ID + Amount(当前数据包已经被重传的次数) + Tstmp（数据包最近一次被重传的时间戳）；
    • Off 模式重传：当直播流进入 Off 模式（发送队列中暂时没有新数据时），系统利用空闲带宽重新发送丢失数据包的副本；可避免重传包与正常流量数据发生争用，最大化利用空闲时段的带宽；
    • 机会性重传：在某些情况下，Off 模式 可能出现不及时或者分布不均，为了避免丢失数据包长时间未被重传，AutoRec 会基于丢失数据包的 沉默时长（距离上次重传的时间）决定是否重传；一旦数据包的等待时间超过一个阈值（Tthres），即便当前没有进入 Off 模式，系统也会立即重传该丢失数据包的副本，确保重传的时效性；

      注：基于 quic（可乱序接收数据包），故重传队列有移动、删除操作，即数据包多次丢失重传失败的情况下，会移动到队列，甚至直接移除；

  额外的优势在于 AutoRec 完全在服务端实现，可适配商业 CDN 服务，方便在多供应商环境下部署，客户端无需改动；

名词解释

On-Off 模式

  指网络中的一种 丢包恢复和重传 的工作模式（即 TCP 使用的模式），从字面上解释，当发生丢包时，触发重传机制 ON，当没有丢包时，重传机制为 OFF；

ARQ

  全称为 Automatic Repeat reQuest，自动重复请求，是一种丢包恢复机制（TCP 的重传机制正式实现于 ARQ），其原理是当发送方发现接收方发送的包丢失时，会重新发送该包，直到接收方收到该包为止；

  如 Stop and Wait（停止等待）、Go Back N、选择重传，不展开讲了；

  以 TCP 举例来说，实现了两种重传方式：超时重传、快速重传；

  前者意为在超时时间内未收到 ACK 时，会触发重传，后者意为当连续收到 3 个相同的 ACK 后，会立刻触发重传；

参考资料