技术干货 | 海量并发低延时 RTC-CDN 系统架构设计（下）
导读：随着近几年音视频流媒体行业的持续发展，海量并发、低延时和低成本作为三大核心诉求依旧需要不断深挖，同时随着 RTC 和 CDN 这两种技术的界线越来越模糊，因此有必要从底层架构层面重新思考 RTC 与 CDN 的融合之道。本文将重点分享：网易云信如何构建 RTC-CDN 服务架构，深入剖析这套架构是如何解决海量并发、超低延时与低成本三大行业核心诉求，并结合低延时直播和元宇宙两大场景，为大家讲解 RTC-CDN 的核心技术和最佳实践。
文 | 吴桐
网易云信
2023 年 2 月，网易云信首席流媒体架构师吴桐受邀参加 QCon 全球软件开发大会-北京站，并于大会上作出主题为《海量并发低延时 RTC-CDN 系统架构设计》的专题分享。
本次演讲共分为 5 个部分。
背景介绍
构建海量并发流媒体服务架构
构建低延时 RTC-CDN 架构
低延时 RTC-CDN 场景化技术实战
总结与展望
本次演讲将会分为上半部分与下半部分两篇文章，上半部分：技术干货 | 海量并发低延时 RTC-CDN 系统架构设计（上）。
本文为下半部分内容。
低延时 RTC-CDN 系统的架构
传统 CDN 直播发展多年，为了优化延时，业界基本上朝两大优化方向：优化传输层协议和在传输层协议的基础上优化应用层协议。
RTMP 和 HTTP with FLV 以及 HLS 底层均使用 TCP 作为传输层协议。针对 TCP 协议的优化在一定程度上可以达到降低延时的效果，比如使用全链路 TCP 加速方案以及替换使用 BBR 在内的更好的拥塞控制算法。
苹果在 2019 年推出了 LL-HLS（Low-Latency HLS），采用 chunk 编码传输模式，将延迟降低到 3 秒左右。目前基于 TCP 方案的 LL-HLS 和 LL-DASH 方案的极限延迟在 2-3 秒左右。
为了优化 TCP 协议，业界在可靠 UDP 协议上做了很多探索。随着大家对 Google QUIC 协议研究的深入，有不少项目和开发者，开始用 RTMP over QUIC 替代传统的 RTMP over TCP。QUIC 是一个非常优秀的协议，现在它已经成为 HTTP3 的标准协议。但 QUIC 作为一种通用协议，它对音视频媒体不友好，也就是它没办法理解音视频媒体数据的具体含义，它以一视同仁的角度来对待这些媒体数据，这也是它不能彻底解决流媒体传输难题的根本原因。
这几年 SRT 也得到了广泛的应用， SRT 底层使用 UDT 协议，UDT 协议也是一个老牌的基于 UDP 的可靠传输协议，当然原生的 UDT 传输延迟是比较高的，SRT 在此基础上做了不少的拥塞控制策略的相关优化以降低传输延时。
近两年随着 WebRTC 成功推广，利用 RTC 技术实现的低延时直播技术越来越成熟，我们来看看云信 RTC 低延时核心技术要点。
网易云信 RTC 低延时核心技术
首先是抗弱网，为了对抗极限场景下 80% 的丢包，像业界常用的 FEC RED 以及 HARQ 技术大家都很熟悉，云信除此之外还利用基于机器学习的 PLC 算来进一步提高音频丢包后处理，并使用长参考帧 LTR 技术进一步降低视频的单帧丢失后连续参考导致的卡顿。
在去抖动部分，利用 Jitterbuffer和NetEQ 技术也是非常成熟的方案，我们花了很多的精力在做 Jitterbuffer 和 ARQ 以及音画同步模块的配合策略，在抗住 2000ms 的抖动情况下，还需要保证音画通话还是有不少工程方面的挑战。
在智能流控部分，首先一定要有优秀的带宽估计和拥塞判断算法，云信这几年对 GCC、BBR 和 PCC 等算法深入研究，融合各算法的优势，自研了一套稳定可靠的拥塞控制算法，可以保证带宽利用率在限制网络下达到 90%+；同时流控要做好必须做好全链路的反馈和源侧的响应，云信利用多层 Simulcast 和 SVC 技术增加了增加了调控的维度，同时利用全链路 VQC 技术保证视频全链路的效果。
除了端侧的 QoS，云信这几年在服务端全链路分段 QoS 部分也做了很多实践。所谓分段 QoS，其实总结来说就是上行和下行的抗丢包要分段，带宽估计要分段，只要这样才能在服务端上针对每个用户的下行网络做最优的适配。
另外，第一公里加速是做好上行 QoS 的重点，包括根据地理位置的就近接入、动态调度以及 MultiPath 的多路径都是很关键的技术。
要做好 QoS 一套完善的云端下发与自适应参数配置服务是必不可少的，除了适配数千款各机型的参数，还需要做差异化场景的自动适配，各个客户端的差异化能力需要做好能力协商和能力降级，保证各个客户端都能有一个最优体验。
如何构建低延时 RTC-CDN 分发网络
在前面介绍云信的流媒体服务器架构时，已经提到了云信媒体服务器使用的无向图的拓扑结构，同时为了提升用户就近接入的效果，云信在全球各地部署了大量的边缘节点，边缘节点之间利用 WE-CAN 大网的路由节点来保证节点之间的网络传输效果。
常规的 RTC 房间，为了尽量减少端到端的延时，基本上采用的是 Full Mesh 的网状拓扑结构，尽量让用户就近接入。但是在房间人数不断上涨，到达万人乃至十万人大房间以后，网状拓扑的分发压力和级联成本都会大大上涨，在这种场景下网状拓扑已经无法满足业务的需求。为了解决这种问题，就需要采用类 CDN 的树状拓扑结构，针对一路上行流使用一棵树来做订阅者的分发。在云信实现的方案中，利用 WE-CAN 大网的路由节点和边缘服务器节点，可以自动适配网状和树状结构，通过流级别的调度策略自动调整每条流的分发拓扑。该方案在低延时直播场景下特别适用，低延时直播将延时控制在 1 秒左右，也为了控制成本采用多层的树状结构，并做一定的边缘聚合，在牺牲一定“最优接入“的情况下，做到了成本和延迟的平衡，同时也满足了低延时直播超大频道的需求做到了无限扩展的能力。因为大网路由节点和媒体边缘节点原来的拓扑组织形态就是无向图，所以天然能够兼容网状和树状拓扑，而且可以复用所有的边缘节点和路由节点，做到最佳的资源利用率，去平衡体验和成本。
低成本
大家或多或少都能感受到 2022 年的互联网多少有点“寒冬将至“的氛围，所以大家对于成本越来越敏感，在我看来低成本主要有两个维度：接入低成本和价格低成本。价格低成本很好理解，而接入成本降低可以节省人力成本，因此这两个维度总结起来都和”钱“相关。对于云服务提供商来说只有做到了低成本也才能让我们的产品竞争力提高，让用户更爱用。
接入低成本
直播 CDN 的接入特别简单，究其原因主要有两方面：一个是直播使用的协议非常标准，比如 RTMP、HTTP with FLV 和 HLS 都是非常标准且通用的协议，各个 CDN 产商都支持；第二是有大量优秀的开源软件在支持直播，比如大家熟知的 OBS、FFmpeg 和 IjkPlayer 等等。标准的协议和优秀的开源软件，都大大降低了 CDN 接入的难度。因此我们认为低成本 RTC 也需要努力探索这两个方向。
云信目前在低延时直播场景进行相关方向的探索和落地，在这里先简单介绍一下云信的低延时直播能力，在推流侧支持第三个推流工具和云信推流工具，将流用 RTMP 或者 WebRTC 协议推到边缘加速服务器，再根据配置如果是开通了低延时能力的就通过 WE-CAN 进行分发，否则就通过融合 CDN 分发。相比于 CDN 直播动辄 4s 以上的延迟，低延时直播延迟更低，最低可以达到 600ms，同时基于自研的 WE-CAN 全球智能路由网络，可支持千万级高并发拉流，并且首帧和抗弱网表现优势明显，让用户用接近 CDN 的价格体验到 RTC 的效果。
说回接入低成本，从开源和标准协议的角度，云信都做了探索，首先我们来看看云信已经开源的基于 WebRTC 的开源低延时直播播放器，大家可以在 github 上搜索 LLS-Player（https://github.com/GrowthEase/LLS-Player），找到这个项目。
上图是云信开源的低延时播放器的框架。云信低延时播放器是一个传输层的 SDK，最底层是 WebRTC。因为我们旨在打造一个通用版的 SDK，所以我们将 WebRTC 全量包入，通过 PeerConnection 层接入，里面是一些主要模块，例如 JitterBuffer、NetEQ、RTP/RTCP、Transport 等。中间是 RtdEngine 层，主要作用是对 WebRTC 进行封装，包含 API、引擎创建、信令建连、 媒体数据的接收回调等。最上层是 FFMPEG 插件。直播已经发展了数些年，各厂商都有一些存量的播放器，市面上大多数播放器都是基于 FFMPEG 开发，为了降低用户 SDK 接入门槛，云信将 API 封装成 FFMPEG 插件，这样只需要在原来的播放器里面就可以实现低延时直播的拉流。
除了开源的低延时直播播放器，云信还支持使用由 Millicast 开放的标准信令 WHIP 进行 SDP 协商后向云信音视频服务推拉流。同时，未来云信还有计划开源包括低延时推流插件在内的其它 RTC-CDN 产品。
价格低成本
这个章节是各个产商的核心，如何优化成本，我这里提供几个思路，供大家参考。
提高资源利用率——CPU 算力错峰利用率，边缘接入节点复用率，大网内部使用组播来提高带宽复用率。
降低带宽开销——各业务带宽错峰（带宽规划），聚合调度，95 峰值成本调度，通过节点的赛马机制去寻找更多优质的低成本边缘节点。
低延时 RTC-CDN 场景化技术实战
低延时直播在线教育大班课
大班课大多都是通过传统的直播解决方案实现的，主要会面临两个问题：白板与直播画面的同步以及答题系统与直播画面的同步，传统直播由于底层传输层协议的固有问题，所以是很难攻坚的；而 RTC 方案虽能解决上述问题，但其高昂的成本让人“又爱又恨”。因此低成本的 RTC-CDN 架构在这个场景下就演化出了低延时直播的解决方案，去平衡效果（也就是清晰度、端到端延时、流畅度）与成本。上文已经分享了低延时直播就是利用了 RTC-CDN 的 QoS 机制、低延时树状分发网络以及低成本方案等，各类技术保障，就是让用户用 CDN 的价格体验到了 RTC 的效果。
云游戏
与之类似的低延时直播场景还有“云游戏“，也是要将实时操作与画面做到极致的同步，特别是在云游戏直播的场景下，低延时直播可以大大提高观众侧的体验，当然云游戏除了延时要求以外，还对视频的清晰度和帧率提出了很高的要求，需要在编码策略和 QoS 机制上做更多的适配。
直播
除了“云游戏“以外，近两年弹幕游戏直播也作为一种新型的直播形态在不少平台取得成功，弹幕游戏直播天然是与低延时直播场景匹配的，因为所有观众发的弹幕都希望尽快在直播画面上看到弹幕的结果，需要做到秒级延时的体验。
IoT 机器人
低延时 RTC-CDN 除了在教育、游戏、娱乐社交等场景得到落地以外，云信这两年还将它应用在了远程操控与 IoT 机器人的场景，所谓远程操控其实就是利用低延时流媒体技术实现对设备的远距离操控。
云信和网易伏羲机器人团队的合作的远程挖掘机就是其中一个落地实践的方向，为了实现远程开挖掘机，我们需要有一套超低延时的控制信令系统和超低延时的实时音视频系统，再配合云端的 VR 渲染。这些超低延时的传输能力，不仅要考虑户外网络较差信号较差的情况，还要面临超大流量的上行流量传输，因为同时传输很多个摄像头的数据，很多传统 RTC 的场景下的 QoS 机制还是需要针对性做较多的优化以适配这样的场景。
元宇宙
除了挖掘机以外，云信还在近两年特别热门的元宇宙场景进行通用传输能力的探索。元宇宙如今已成为全球科技业的下一个风口。在元宇宙琳琅满目的各种应用场景中，无论是如电影《头号玩家》中的那种体感交互设备，还是医生利用 VR 医疗，远程做手术，元宇宙强交互的基础是数据的低延迟传输和同步。
云信与网易瑶台合作研发的瑶台是国内首批元宇宙落地产品，区别于传统视频会议的呈现方式，瑶台更具虚拟的沉浸感。去年网易曾将全球投资者大会的举办地搬到了瑶台虚拟世界，来自全球几十个国家的 200 多位投资者，通过自己的虚拟形象，交流网易业务的最新动态。整个互动场景便是基于网易云信的低延时 RTC-CDN 能力打造。
MPS 云端实时转码
除了通用传输技术，云信也在探索通用的远端媒体处理技术，使用云信自研的 MPS 高性能媒体处理服务器，云信能够在云端实现虚拟人、转码、超分、场景渲染等能力，来满足不同客户和场景的实际需求，我们认为云端的媒体处理构建，也是音视频在元宇宙时代的一个非常重要的组成部分。
总结和展望
总结
我们探讨了全球分布式多单元流媒体服务器架构，利用分层架构和统一调度来支持了海量并发以及流量蜂拥。
我们基于多单元流媒体服务器架构，并深度打磨低延时技术，打造了 RTC-CDN 系统，针对 RTC-CDN 系统探索了低成本服务架构，同时拥抱了标准化和开源。
我们利用 RTC-CDN 优化了低延时直播、元宇宙的传输、云渲染以及远程机器人控制等场景。
这里我们对 RTC-CDN 这个新词做一个总结：什么是 RTC-CDN 系统？就是在一套系统里同时具备 RTC 和 CDN 的能力，并让 RTC 的接入与使用如 CDN 一样低成本。
展望
系统架构的融合和多样性是未来，而全面的 RTC-CDN 时代，应该会在未来几年内到来。
未来的音视频编解码还是会不断的迭代创新，比如 8K 的新一代视频编码器 AVS3 和 VVC 和谷歌基于 AI 的音频编码器 SoundStream。
传输技术会继续迭代，不仅是已经得到广泛应用的 QUIC 和 HTTP3，5G 和 6G 这些底层通信技术也会不断演进，这些都会推进 RTC 技术不断迭代。
AI 与大数据挖掘，会不断在 RTC 领域中发挥重要作用。
技术是永无止境的，我坚信技术是可以改变世界，音视频领域未来有无限可能。
推荐好友计划