音视频应用近年来呈现出迅猛的发展趋势，成为互联网流量的主要载体，其玩法丰富，形态多样，众多繁杂的媒体传输协议也应运而生。LiveVideoStackCon 2022 北京站邀请到快手传输算法负责人周超，结合快手在媒体传输上的优化与实践，基于快手 KTP、KLP、LAS 等协议和标准，为我们介绍了媒体传输协议的演进与面临的挑战；还分享了最新的媒体传输标准 CMTP，探索未来更多可能。

文 / 周超

编辑 / LiveVideoStack

-01-

音视频大时代下媒体传输协议的繁华

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

近几年，音视频技术发展迅速，叠加网络、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 进行了二次开发，形成自己的方案。

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

-02-

快手在媒体传输优化上的实践

在快手的传输体系中，底层算法是最核心的部分，包括常见的拥塞算法、多码率自适应算法、弱网对抗算法等等。在此基础之上，我们设计了丰富的传输协议，例如 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 不能全场景支持等。

-03-

下一代媒体传输协议：CMTP

基于之前多个协议成功的经验和算法积累，我们期望设计一套全新的协议 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 生态。

LiveVideoStackCon 2023 上海讲师招募中

LiveVideoStackCon 是每个人的舞台，如果你在团队、公司中独当一面，在某一领域或技术拥有多年实践，并热衷于技术交流，欢迎申请成为 LiveVideoStackCon 的讲师。请提交演讲内容至邮箱：speaker@livevideostack.com。