Facebook 新拥塞控制算法的实验结果 - ，针对视频内容传输进行了优化。该算法是由麻省理工学院的研究人员提出的。提议用于测试的 COPA 原型是用 C++ 编写的， 获得麻省理工学院许可并包含在 — Facebook 正在开发的 QUIC 协议的实现。
COPA 算法专注于解决通过网络传输视频时出现的问题。根据视频类型的不同，对拥塞控制算法提出了几乎相反的要求——对于交互式视频，需要确保最小的延迟，甚至以牺牲质量为代价，而在播放预先准备好的高质量视频时，会优先考虑以保持质量。以前，应用程序开发人员只能根据质量或延迟要求应用不同的算法。开发 COPA 的研究人员试图创建一种用于管理 TCP 视频拥塞的通用算法，该算法可以根据视频要求进行定制。
拥塞控制算法的工作是确定发送数据包时的最佳平衡 - 发送太多数据包可能会导致数据包丢失，并且由于需要重新发送而导致性能下降，而发送太慢会导致延迟，这也会对性能产生负面影响。选择 QUIC 协议进行实验，因为它允许在用户空间中实现拥塞控制算法而不干扰内核。
为了防止通信信道拥塞，COPA 基于对数据包传输过程中延迟变化的分析来对信道特征进行建模（COPA 随着延迟的增加而减小拥塞窗口的大小，从而即使在丢包发生之前的阶段，延迟也开始增加） 。使用特殊的增量参数来调整延迟和吞吐量之间的平衡。增加增量会增加对延迟的敏感度，但会降低吞吐量，而减少增量则可以提高吞吐量，但会增加延迟。 Delta=0.04 被定义为质量和延迟之间的最佳平衡。
基于 Facebook Live 流媒体服务，对 COPA 进行了测试，与流行的 CUBIC 和 BBR 算法进行了比较。 Linux上默认的CUBIC算法是逐渐增加拥塞窗口的大小，直到发生丢包，之后窗口大小回滚到丢包开始之前的值。
CUBIC 在现代网络设备上的数据包缓冲方面还有很多不足之处，这会减慢数据包丢失的速度。拥塞控制算法不知道缓冲，并且即使信道已经发生物理拥塞，也会继续提高速度。未发送的数据包会被缓冲而不是被丢弃，并且 TCP 的拥塞控制算法仅在缓冲区已满时才会启动，并且无法平衡流量与物理链路的速度。为了解决这个问题，Google 提出了一种改进的 BBR 算法，通过顺序检查和往返时间（RTT）估计来预测可用带宽。
当 delta=0.04 时，COPA 指标接近 CUBIC 和 BBR。在通过低数据包传输延迟的高速网络连接进行的测试中，COPA 实现了比 CUBIC（479 毫秒）更低的延迟（499 毫秒），但略落后于 BBR（462 毫秒）。当连接质量下降时，COPA 显示出最佳结果 - 延迟比使用 CUBIC 和 BBR 时低 27%。
同时，在通信信道较差的情况下，与 CUBIC 相比，COPA 和 BBR 可以实现显着更高的吞吐量。与 CUBIC 相比，BBR 的增益为 4.8% 和 5.5%，COPA 的增益为 6.2% 和 16.3%。
来源： opennet.ru