媒体传输协议的演进与未来

本次分享会从媒体传输协议的现状、快手在媒体传输协议优化上的实践和对未来的展望三部分展开。

近几年，音视频技术发展迅速，叠加网络、AI技术，音视频已无处不在，应用场景涵盖点播、直播、电商、实时互动、游戏、医疗和教育等多个方向。

从用户体验角度来看，音视频应用都需要在延迟、流畅度和清晰度之间寻找一个平衡点，对应到网络传输，本质就是需要在延迟、传输可靠性和带宽利用率之间找到一个平衡点。

基于此，音视频应用可以大致划分为三大类，即泛VoD、泛RTC和泛Live。

泛VoD偏重于点播类应用，对延迟不敏感，更注重传输可靠性和带宽利用率。泛RTC应用则对延迟非常敏感，在保证延时的前提下，才会追求传输的可靠性和带宽利用率。泛Live应用介于两者之间，对每个维度都有一定要求，并且不同的Live垂类场景，对三者（可靠性、延迟、带宽利用率）之间的平衡关系也有一定差异。

从架构上来看，泛VoD可以大致分为四个步骤。视频在采集和导入之后，叠加魔法表情等玩法，然后经过转码压缩上传到云端。在服务端进行审核和前处理等大量工作后，一般会进行二次转码，以进一步提高压缩率并生成多个质量的副本。最后，由CDN分发给用户，进行下载、解码、渲染和播放。

在生产端，创作者能否快速成功的发布作品，将直接影响他们的创作热情。

在消费侧，用户则更关注视频的清晰度和流畅度，这两个维度都需要可靠传输以及足够高的带宽利用率。提到可靠传输，最常见的就是HTTP协议和QUIC协议。此外，在消费侧，为了应对海量用户的差异性网络，一般会采用多码率自适应技术，例如DASH、HLS等。

泛Live应用架构与泛VoD较为类似。主播和观众都希望获得低延迟、高清晰度和高流畅度的体验。但直播流实时产生，对传输的平稳性要求较高，对带宽利用率和延迟方面会做一定的妥协。例如，当网络出现剧烈波动时，允许出现丢帧和丢包。业内直播主要采用RTMP协议，近年来也在尝试QUIC协议，例如RTMP over QUIC的方案。在消费侧，通常也会采用多码率自适应技术。然而，常见的DASH和HLS技术，都是基于分片的架构，在直播场景中会带来较大的延迟。目前，为了降低直播延迟，许多厂商也在尝试基于WebRTC的快直播方案。

泛RTC场景的目标非常明确，就是要实现超低延迟的互动。在满足低延迟的前提下，再提升清晰度和流畅度。目前使用最多的方案是WebRTC，很多公司也基于WebRTC进行了二次开发，形成自己的方案。

总体而言，每类应用场景目前都有各自比较成熟的协议，其稳定性高、各厂商支持好，但也存在灵活性差、跨层优化难和业务不感知等问题。

在快手的传输体系中，底层算法是最核心的部分，包括常见的拥塞算法、多码率自适应算法、弱网对抗算法等等。在此基础之上，我们设计了丰富的传输协议，例如KTP、LAS、AAS、KLP等。KTP是快手自研的第一个私有传输协议，用于直播推流、作品发布和RTC等业务场景；LAS是快手自研低延迟直播多码率自适应协议，目前已形成行标，几乎所有云厂商都支持；KLP是快手自研的直播拉流协议，用于提升直播拉流的传输效率；AAS是点播场景下的多码率自适应协议，包含短视频和长视频场景。

KTP在设计之初，就希望一个协议能同时支持支持点播、直播和RTC等多个业务场景，解决协议繁多、维护和优化成本高的问题。在架构上，KTP总体分为两层：底层是传输控制层，通过对协议的设计，支持在传输延时、可靠性和带宽利用率之间取得动态平衡。在其之上是业务感知层，感知业务特性，根据不同业务的特征，采取最佳的策略与算法。

通过实际测试对比发现，在直播推流场景，KTP在60%丢包率时，依然可以保持清晰、流畅的推流体验（左图），而RTMP在15%丢包率时，会发生严重卡顿，处于不可用状态（右图）。

在作品发布场景上，基于KTP的通用上传服务，已经用户快手各个作品发布/文件传输的场景，并显著提升了作品发布成功率，从最初的70%～80%提升到99%以上。此外，即便在用户网络越来越复杂、作品大小越来越大的情况下，其发布耗时也一直处于下降的状态。

最后，在RTC场景，KTP支撑着快手内部所有的RTC业务，例如PK、连麦、会议、StreamLake等等。基于先进的算法与架构，基于KTP的RTC解决方案，在体验和性能等多个维度上，都显著领先竞品。

此外，在2021年ACM Multimedia的低延迟传输挑战赛中，快手也以巨大的优势取得了第一名的好成绩。

协议是桥梁，支撑各种功能与业务需求，但其传输性能主要取决于底层算法。例如网络领域的核心算法之一的拥塞控制算法，在过去几十年一直是研究的热点与难点，直接影响着协议的传输性能、带宽利用率、弱网抗性等。快手一直持续在算法领域深耕，例如自研的拥塞控制算法IA2C，性能远超BBR；基于强化学习的NNCC，在带宽利用率上取得新的突破；最近正在准备上线的下一代拥塞算法AQDC，在带宽利用率和延迟上，均取得显著收益。

KTP广泛用于作品发布、直播推流和RTC等场景，并取得了很好的收益。但由于历史原因，在下行链路上，KTP并未很好的做支持和优化。于是，在2020年，我们复用了KTP的底层传输控制，并在此基础上，增加了适用于直播拉流特性的策略与算法，形成了KLP协议。KLP在海外上线的时候，取得了非常好的效果。

在消费侧，为了应对用户差异性的网络特性，一般会采用多码率自适应技术，来平衡流畅度和清晰度，例如国际标准DASH和HLS，其大致原理为将视频文件转码成多个档位，每个档位进行分片处理，消费侧依据实时网络状况选择不同的分片，最终拼接成一个完整的视频。这两个标准成熟度高，但最初都是为点播设计，直接用于直播场景，会带来较大的延迟。

在经过充分的调研和讨论后，快手决定自己建立一套低延迟的直播多码率标准，也就是LAS，目前LAS已经正式成为行标，也被业界广泛采用，相关细节可参考官网介绍（https://las-tech.org.cn/#/）。

在点播多码率上，我们同时考虑了短视频和长视频之间的差异，形成了快手点播多码率自适应标准——AAS。在协议描述上，参考了MPD和DASH的设计，最核心的是快手自研究的多码率算法，包括传统基于模型的算法、基于深度学习的ABR等，这些算法在不同场景，均取得了非常好的效果。

此外，在2022年ACM Multimedia的短视频传输挑战赛中，快手也以巨大的优势取得第一名的好成绩。

目前，快手的网络传输主要依托于自研的一系列协议，但仍存在一系列问题，例如下行场景覆盖不足、业务耦合、生态封闭、无法赋能行业、三方CDN不能全场景支持等。

基于之前多个协议成功的经验和算法积累，我们期望设计一套全新的协议CMTP，可适用于所有场景，并能解决覆盖不足、生态封闭等问题。总体而言，CMTP具有以下四个特性：架构通用、全场景、高扩展性和特性丰富。

在架构上，CMTP分为五层：

UDP/TCP层：底层IO使用的网络协议，默认采用UDP，UDP灵活性高，易扩展，可以支持多种算法与策略，对于UDP Block的情况，则采用TCP。

传输控制层：支持UDP和TCP两种模式。基于UDP规范了协议字段、组包拆包方式、会话管理等，支持ARQ、FEC、拥塞控制、0-RTT、加密、多路复用等功能。基于TCP也规范了协议字段、组包拆包方式等，并支持加密、多路复用等功能。

传输表示层：规范了传输控制层所需要提供的接口和功能，包括媒体会话、媒体流的定义，以及媒体数据、控制信令的表示方式等，同时支持协议优选。

应用感知层：以组件化的方式组织，感知业务的不同需求，并通过对应的组件提供专属优化功能，包含直播组件(Live)、点播组件(VoD)、实时通信组件(RTC)和通用组件。各个组件功能独立，可插拔、替换或新增，从而保证其足够强的扩展性、兼容性和业务适应性。

通用接口层：规范了对外的标准接口和配置，包括客户端和服务端接口，元信息和通用配置的格式等。

目前CMTP已经在快手落地，也取得了显著的收益。此外，很多厂商也已经支持CMTP，并与快手一起推进标准化。未来，希望有更多团队加入我们，共同建设良好的CMTP生态。