rtp实例（如何设计一套RTCPaaS服务）

原文作者:angrychuan

原文地址:https://juejin.im/post/6881188316943908872

目前实时音视频通信RTC(Real-Time Communication) 服务常见的有两种形态：SaaS(Software as a Service)和PaaS(Platform as Service) [1]

SaaS服务往往是一个大的集合。如在线教育场景，不仅包含RTC服务，还包含一系列线上上课流程所需的基础服务保障和提升上课效率、体验的一些列教具，如即时通信IM服务、课程管理系统、互动课件和电子白板、点播回放等。

PaaS服务则聚焦音视频实时通信的能力，依托音频3A前处理(回声消除、噪声抑制和自动增益控制算法)、音视频编解码、信道传输、弱网对抗、网络调度等技术，为用户提供高可用、高品质、低延时的音视频通信服务。用户可通过集成不同平台的SDK，快速搭建多端实时应用，在项目中实现语音通话、视频通话、音频互动直播、视频互动直播等，适用于在线教育、视频会议、互动娱乐、音视频社交等场景。

首先从需求和问题出发，对于公有云RTC PaaS服务来说，先抛开不同平台音视频设备采集、编码、网络发送、网络接收、解码、渲染的差异不谈，主要围绕的问题就是如何在当前复杂、不稳定的公有云环境下提供高可用、高质量、低延时的音视频通话服务，而其中几个主要影响音视频 QOS(Quality of Service) 的因素 [2] 主要包含以下几个方面：

• 网络延时(Latency/Delay)
• 网络丢包(Packect Loss)
• 网络乱序(Out-of-order delivery)
• 网络抖动(Jitter)
• 网络拥塞(Bandwidth Overuse/network congestion)

所以如何设计服务的架构，提供一张优质、高效的网络传输链路和一系列保证弱网情形下音视频QOS的手段或策略，则显得尤为重要。对于网络这一层，往往是优先解决用户最后一公里的问题，这也是跟传统的边缘节点或者CDN的思路一脉传承。

按照功能划分，设计一套完整的RTC PaaS服务 [3] ，需要完成：

• 调度服务器(Coordinator)因为无论如何优化压缩算法和代码，网络仍然是贡献大部分延时至关重要的因素，服务架构需提供一种机制，保证用户就近接入负载最低的最优媒体节点，来减少RTT(Round Trip Time)和尽可能保证用户最后一公里的网络质量，这就是调度服务器的价值所在。如上图steps 1、2所示，当新用户接入RTC服务时，首先请求调度服务器获取可用媒体服务器的列表，调度服务器通过请求中携带的用户的外网IP获取用户的地理位置和运营商信息，按照一定的策略返回媒体服务器列表，然后在step 3，客户端通过ping消息探测与所有候选媒体服务器之间的实时网络状况，从而选择最佳的媒体服务器进行推拉流。这些探测获取到的网络状况列表，特别是延时信息，将稍后被反馈发送至调度服务器，以致于它能够更加准确地分配最合适的媒体服务器，服务于后续新的用户。
• 信令服务器(Signaling Server)设计一个视频会议系统，信令协商和消息交互是一个必不可少的部分，不过我一直主张： 「轻信令重媒体」 ， 「在保证必要消息交互的前提下尽可能减少消息交互的次数和消息体的大小，怎么简单怎么来」 。对于信令服务器的设计，建议简洁、够用即可。如上图所示，建议一种思路，将 「轻薄」 的信令服务也放在媒体服务器这一侧，这样不仅维护起来比较方便，而且媒体服务器能够独立于其他服务对外提供服务，即使其他服务出现异常也不受影响。另外测试和排查问题也更加高效便捷。缺点就是对于调度服务器来说，获取到的用户媒体信息有限，对于负载消耗的预估、控制不能很精细。在这里，想讨论一个问题， 「RTC PaaS服务一定需要会议、Channel或者房间的概念吗？」对于这个问题，我认为可以抽象为 「长连接vs短连接」 的问题， 因为对于同一个会议或者房间这种概念，听的更多的是来自于IM即时通讯，在房间里的人能够立马收到或者消费其他人发送的消息，而且能感知其他人在线或者离线的状态。对于RTC PaaS服务来说，目前有两种方式供用户使用：「无会议、房间的概念，不打包长连接服务」。使用方在使用SDK进行推拉流时，不用先JoinChannel或者JoinRoom，只需通过调度服务器拿到媒体服务列表之后选择一个最优节点进行推拉流即可。而此时RTC PaaS服务本身无法感知与会者的加入和离开，对于拉流动作只能依赖SDK的定时不断重试去保证，不能提供消息的发布(Publish)和订阅(Subscribe)。好处当然是不用去新开发一个类似IM的服务，要做一个稳定高效的长连接IM服务同样不是很容易，而且开发逻辑和调用流程都很简单；相反，就必须牺牲一些东西，如SDK侧拉流动作需要不断重试，这个就显得不是很优雅，另外由于缺乏长连接，服务端无法感知端上的实际在线状态，如客户端Crash，很多消息无法正常触发。对于某些任务session或记录的销毁严重依赖端上消息的抵达，否则的话就只能依赖定时超时去清理。适合的场景：很多业务使用方往往有自己的IM即时通信服务，因为现在的app在线长连接和直播间内发消息、点赞、送礼物等基本上已成为标配，所以可以依赖偏上层业务的信道消息去实现消息的发布和订阅，从而决定推拉流的时机。「有会议、房间的概念，打包长连接服务」。与第一种情况相反，这种情况下就需要为使用方提供稳定高效的IM服务，一般情况下，可使用websocket 消息队列(如RabbitMQ)的方式来实现，使用方在使用SDK进行推拉流前，必须先JoinChannel或者JoinRoom，然后才能订阅或者消费消息，从而在其他人加入、离开房间或者推流时收到通知后去处理相应的回调。对应的由于长连接的存在，服务端能够准确感知客户端的状态，当用户离线时，及时清理任务session或记录。适合的场景：有些小公司没有能力开发自己的IM服务，从他们的角度来说，给我提供一整完整的解决方案即可，我不需要care其他的技术细节，只需要知道什么样的事件回调执行什么调用即可。在信令层面上，还想讨论的是在抗弱网的表现上，tcp明显不如udp，所以往往会存在媒体传输还可以信令却无法建立的情形，所以建议在信令层面上可以尝试udp的可靠传输，如 QUIC 等。
• 媒体服务器(Media Server或者Streaming Server)所有媒体服务器是完全独立的，当一个服务器加入或者离开RTC网络时，系统能自动调整它的分配，不让用户有感知和影响。在高负载的情况下，可以通过新增机器部署服务来进行 「水平扩展」 (horizontal scaling)。媒体服务器一般按照网络拓扑架构可以划分为两大类 [4] ： 「SFU(Selected Forward Unit) 「和」 MCU(Multipoint Control Unit)」 。

如图所示，SFU只负责媒体流的转发，不做太多复杂的媒体处理，瓶颈在IO，并发能力强；劣势是下行转发路数多，带宽占用高，对用户侧带宽和设备的要求高。MCU除了媒体流的接收/发送，还要进行转码和混流，对服务器性能要求高，服务部署成本高，瓶颈在CPU，并发能力差，转发流数少，而且实时传输系统中，转码会带来额外的延时，实时性稍差；优势就是下行带宽占用少，对用户侧带宽和设备的要求低。

对于实时性和高并发有强要求的会议场景，更多的是选择SFU架构。随着未来5G技术的推广，可以预见带宽越来越不是问题，SFU的优势会更加明显。

然而在实际业务场景中，服务架构往往是 「SFU MCU混合」 的方式去满足业务的需求。那么问题来了，是将MCU和SFU做在一起呢？即该服务既可以转发也可以混流，还是SFU和MCU完全独立，转发路径上的媒体节点都是单纯的SFU呢？

因为从媒体处理流程和功能层面上，SFU可视为MCU的子集，MCU支持一定的转发能力，比如混流完成后可选择不同的媒体封装输出方式，可直接被客户端拉流(这个就是MCU也具有SFU的功能了)。

如图所示，建议将不同能力分由不同的节点来实现 [5] ，如转发服务SFU节点负责媒体的转发和跨国级联，混流服务器MCU节点负载转码、混音和混流，因为这样服务的设计能尽量简单，耦合性低，同时对于不同类型的服务调度策略也能简单很多，降低整体系统的复杂度和提高效率。

对于一套完整的RTC PaaS服务来说，往往需要将各种能力补齐，除了上述的媒体服务类型以外，还需要：

「云录制服务器(RTP to flv or mp4)「和」 云转推服务器(RTP to RTMP)」 ，云录制主要用于回放点播，云转推主要用于旁路直播，在1vsN的场景下减少转发节点的压力，降低成本。如上图所示，SFU和MCU都可作为云录制和云转推的输入端，类比选择不同的媒体封装输出方式。另外也可使用CDN RTMP直播的录制来做回放点播，不过链路增加了，相应出现问题的概率也增大了，需结合着业务形态和研发阶段进行合理的选择。

如果是走的私有协议，为了支持Web端，还需要设计开发 「WebRTC网关」 ，进行信令和媒体的转换。

历史总是惊人的相似，可以参考RTMP直播架构的发展和演进，因为从本质上网络这一层面上RTMP直播和RTC要解决的问题是一样的。

• 第一阶段， 「单区域源站模式」 ，各个区域都从源站上进行推拉流。如上图所示，很显然跨地域跨运营商时推拉流效果是无法保证的。
• 第二阶段， 「多区域多线BGP 专线级联回源模式」 ，如上图所示，能有效改善用户与服务器之间的网络状况。阿里云ECS为多线BGP机房，不同区域间通过拉专线保持级联互通，相比运营商的主干网网络状况会稳定很多；但这种模式成本很高，多线BGP机房按照流量收费单价很贵，同时专线成本更高；另外对于阿里云ECS来说，并不是每个地区都有相应的VPC，存在一些区域无法正常覆盖，而且每引入新的节点，可能就需要重新购买专线，节点与节点之间的专线有的还受物理因素的限制，如国内到国外的出海光缆只有从华东上海出。这一阶段就需要根据实际的需求进行 「合理的区划」 、 「选点部署」 和 「定制一定的调度策略」 ，如同一区域一个room尽可能分配到同一台服务器上来避免级联；根据实际布点的网络拓扑动态生成路由，用户拉流时，通过调度服务器选择最优路径，动态回源；在一定情形下避免专线带宽的消耗，同时监控专线带宽的消耗，当超过一定阈值的情况下报警和使用外网通信，避免雪崩。

• 第三阶段， 「多区域边缘节点(ENS)接入 多线BGP(ECS)跨区域跨运营商中转 云企业网(CEN)模式」 。如上图所示(偷了个懒~:blush:)，同一区域同一运营商就通过边缘节点进行中转；不同区域或者不同运营商的情况下通过ECS进行级联中转，不同ECS通过云企业网进行彼此互通，专线连接。相比ECS节点，边缘节点ENS覆盖范围更广，成本更低，网络拓扑可扩展性更强；云企业网能够帮助用户在引入新的VPC节点时省去两两拉专线的麻烦，而且能共享专线之间的带宽资源，同时不用关心实际专线网络拓扑的结构和物理限制，将VPC之间的路由交由阿里云来保障，这样使用起来更加地便捷，节点扩展起来更加地方便高效。不得不说，阿里云确实是在想着解决用户的痛点，成就客户的同时就是成就自己。
• 第四阶段， 「边缘节点CDN WebRTC标准化模式」 。这个也是参考RTMP直播发展的历史规律来看的，还处于理想未实现的状态。据我所知，各大云厂商也在纷纷发力。云厂商在边缘节点CDN服务支持标准的WebRTC协议，用户不需要维护自己的源站和服务器，只需要就近接入最优的CDN进行推拉流即可，网络链路这一层由云厂商来保证。不过真正要实现仍需很长时间的等待。未来对于小厂来说，只需要按照标准进行信令协商和媒体推拉流，就可以进行实时音视频互动，不仅在开发和维护成本上大大降低，服务的稳定性上也有更大的保障，不过对于那些有特殊的定制化需求和场景的，则相应的灵活性会差一些。

互联网的高速发展，加快了信息的传播，改变了人们的生活，同样促进着技术的不断更新与迭代。伴随着人们孜孜不倦地对于音频、视频感官体验的不断追求，各种形态的音视频应用应运而生，冲击着人们的生活，改变着人们的习惯。而价值驱动技术的发展，各种技术由兴起到盛行，再到大行其道，门槛由高转低，小作坊成本高昂变成统一白菜价。互联网不断革着世俗的命，技术的发展也在不断革着程序猿的命，抱着一门技术坐吃山空的时代早已不复存在，留下的都是大浪淘沙的不断前行者和35岁的伤痛。音视频行业相对于其他领域专业化程度相对较高一些，但依然逃不过社会化大生产的规律。

前前后后，国内音视频行业的人才积累大致来自于三个时代：

• 「播放器时代。「对应的应用形态是」 点播和短视频」 ，点播代表app有腾讯视频、爱奇艺、优酷、芒果TV，没落的搜狐视频，乐视、土豆等，短视频代表app有抖音和快手。需要的技术栈就是播放器 ffmpeg ，致敬ffmpeg，真是养活了不少人。
• 「RTMP直播的时代。「对应的应用形态是」 娱乐直播、体育直播、直播秀场、直播带货、在线教育大班课」 等，直播代表app有虎牙、斗鱼、映客，倒下的熊猫等，今年疫情以来，直播带货很火，各家电商似乎不做都不太好意思。直播兴起的早期有自建源站和CDN的，到有专门做CDN的厂商，如网宿、蓝汛、帝联、白云山等，渐渐地腾讯云、阿里云、金山云、华为云等巨头入局CDN，直播研发的人力、维护成本越来越低。直播客户端比较成熟的开源项目首推 OBS ，服务端常用的是 nginx-rtmp-module 和 SRS 。
• 「RTC的时代。「对应的应用形态是」 连麦、音视频通话、视频会议、在线教育1vs1和小组课」 等，老牌传统的视频会议厂商有思科Cisco、宝利通Polycom、华为HuaWei、新晋新秀Zoom，还有低调的Vidyo等。视频通话软件有Apple FaceTime、Microsoft Skype、Google Hangouts & Duo等。国内比较有名的RTC PaaS厂商有声网Agora、即构科技Zego、腾讯云和阿里云等。虽然VOIP和视频会议在国外已发展多年，但在2017以前仍然是小众市场，技术人才积累有限。不得不提的就是Google 2011年开源的 WebRTC ，在WebRTC出现之前，音视频实时通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过WebRTC来深入了解RTC技术。我也有幸在2014年与她相遇，期待着WebRTC标准大一统的时刻到来,跟着Google老铁混有肉吃。参考上面“网络架构演进”中第四阶段阐述的那样，如直播的发展套路一样，渐渐地RTC只剩下两种形态：云厂商的WebRTC CDN，用户只需要使用云厂商的SDK或者自己定制SDK，就近推到最优的CDN节点，网络链路由云厂商去保证，既支持私有云也支持公有云部署，用户可选择附加的云录制、云转推、转码混流服务等。不触及底层，结合RTC技术app前端业务形态的不断创新和小厂特殊化或者安全性的需求，选择自建。

在当前这个时代，永远不变的就是变化。从一个技术开发者的角度，我们阻挡不了历史的洪流，能做的唯有顺应和适应，打铁还需自身硬，我们能做的就是打好基础，不断地迎接挑战，力争精通和专业化。

[1]IaaS，PaaS，SaaS 的区别:

http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html

[2]preparing-ip-network-video-conferencing:

https://support.polycom.com/content/dam/polycom-support/products/uc-infrastructure-support/management-scheduling/dma/other-documents/en/preparing-ip-network-video-conferencing.pdf

[3]Open Source Cloud Gaming with WebRTC:

https://webrtchacks.com/open-source-cloud-gaming-with-webrtc/

[4]从入门到进阶｜如何基于WebRTC搭建一个视频会议:

https://zhuanlan.zhihu.com/p/130406233

[5]即构实时网络调度系统如何应对跨国场景挑战:

https://zhuanlan.zhihu.com/p/47951276

原文作者:angrychuan

原文地址:https://juejin.im/post/6881188316943908872