OWT基于TCP以及QUIC的级联方案

大家好，本次我分享的主题是OWT中基于TCP和QUIC的级联方案。

本次分享将从三个方面展开介绍，首先介绍什么是OWT，然后介绍单集群内部的流是如何扩散的，最后介绍多个集群之间的流是如何扩散的。

OWT是Open WebRTC Toolkit的简称。我来自Intel的Web Platform组，我们组从2012年开始研究WebRTC技术，然后大概在2013年开始开发这个产品的原型——基于WebRTC的音视频的开发套件，最开始开发产品是为了达到基于WebRTC进行音视频会议的目的。我们在2014年发布了第一个版本（此前只在内部发布并不开源），为了让更多的开发者参与我们的工作，于是在2019年我们将开发成果开源了。

从2013年到2019年，我们收集了很多的客户需求，根据这些需求得到了现在的模型。这个开发套件主要分为两部分，一部分是Server端的实现，另一部分是客户端（终端）SDK的实现。

Server端主要提供了四大功能，常用的有Streaming，也就是流之间的传输。刚刚提到，产品最初的主要应用是音视频会议，所以Conferencing也是其中的一大功能。同时，我们还加入了转码和视频分析的功能。Server提供的这些功能大多是基于Intel的技术，且和Intel的硬件相结合使性能得到了更好的提升，因为Server里的Streaming支持SFU和MCU，所以可以有效地利用Intel硬件资源进行硬件加速，再进行视频分析。

在客户端，经过多年的演进，我们基本上在市面的大多数平台都提供了相应的SDK。由于这是Open WebRTC，因此支持WebRTC协议，同时针对不同场景下的用户需求，我们加入了RTSP、RTMP协议的流的接入，也支持通过RTMP往外推流。由于产品最开始用于视频会议，因此加入了传统的基于SIP终端开会的设备，因此支持SIP协议和SIP流的接入。

下面展示的是应用场景。经过多年的演进，我们基于架构进行了很多的补充，因此应用场景十分广泛。比如客户会使用视频会议、屏幕分享等基础功能，教育行业也会使用我们的产品来开会或做终端的机器。也有客户和我们进行医疗方面的合作。最近有客户和我们合作做Immersive VR相关的应用。此外，我们也有与Cloud Gaming和IoT相关的case。因为我们的项目是开源的，所以不同的客户或开发者可以根据不同的场景选择需要的功能来实现符合需求的部署和应用。

这是我们的开源的网址: https://github.com/open-webrtc-toolkit/ ，在GitHub上有相应的repository。我们合作的客户有阿里巴巴、爱奇艺以及Zealcomm等。

接下来介绍OWT Server端的基本架构。架构分为控制层和数据层，控制层包括信令交互和通过RESTful控制流，Conference可以管理整个会议，Cluster Manager作为中心管理者可以管理整个集群。这是控制层当前的结构，后面北京大会上会有进一步的内容分享，并以一种更灵活的方式供开发者使用。

数据层主要分成两大部分，一部分是数据接入模块，另一部分是数据处理模块。接入模块里，客户端通过WebRTC Agent将WebRTC流接入到Server，Streaming Agent作为接入节点可接入RTSP和RTMP流并进行推拉流的操作，Sip Agent接入支持Sip协议的流。同时，我们最近还加入了Quic Agent，WebTransport通过Quic Agent将客户端的流通过WebTransport接入到集群。将各种协议的流接入到集群后，可以进行额外的数据处理的操作。

数据处理模块里，Video Agent可以做视频的混流、转码，Audio Agent可以做音频的混流、转码。之前火山引擎的老师介绍了在大规模情况下选择几个音频流的功能，OWT里Audio Agent也支持这种功能，即在大规模用户使用的情况下，选择3个最active的用户的流让终端用户听到。

此外，基于distributed pipeline的Analytics Agent做AI相关的视频分析，Analytics Agent可以基于Intel的OpenVINO架构进行人脸识别和视觉分析，经过视觉分析的流可在Web端或Client端进行实时订阅。Recording Agent是录制模块，在前端接入的流可以在服务器端进行录制存储。

以上就是我们的整体架构，这个架构目前也还在不断地演进。

这些就是控制层和数据层中的模块，模块间通过RPC Bus RabbitMQ进行通信，整个集群通过Cluster Manager进行管理。Portal、WebRTC Agent、Video Agent等数据处理模块和数据接入模块以及信令服务器可以独立部署，在集群里进行分布式部署后，可以用Cluster Manager进行调度，我们提供了5种调度策略，可以针对不同的使用场景对相应的模块部署不同的调度策略。

举一些例子，WebRTC Agent作为接入节点对带宽的要求较高，因此将带宽作为WebRTC Agent的资源使用率并将其汇报给Cluster Manager，假设有多个WebRTC Agent，当出现下一个WebRTC 接入请求时，Cluster Manager根据最少使用带宽策略将请求分配到使用带宽最少的WebRTC Agent上。针对Recording Agent，可以根据录像的剩余磁盘空间大小来进行调度。针对Video Agent或Audio Agent，如果有转码的需求，可以根据CPU的资源使用率来进行调度。

这是内部模块的连接方式，数据接入模块和数据处理模块通过转发等操作进行流的交互。接下来我们今天介绍内部的数据接入模块和数据处理模块之间的流是如何转发的。

这是一个流扩散的模型。Accessing Node就是WebRTC Agent、Streaming Agent、Sip Agent和Quic Agent，publisher和subscriber分别是发送流和接收流的客户端。流传送到Accessing Node后进行demux，将audio frame和video frame分别传送到Audio Node和Video Node并进行相应处理，再将处理后的流传送到Accessing Node，最后转发给订阅者。

整个过程中，可以根据用户的订阅需求来处理mixed stream和forward stream，我们有相应的RESTful API来控制，即用户可以调用相应的接口来控制是否将流加入mixed stream中，或者用户在订阅时控制是否进行transcode。

这是内部流扩散的pipeline。IP Camera通过RTSP协议接入到Streaming Node，接入的媒体包在内部通过Media Frame Constructor操作拆分成帧。由于内部在专网的条件下比较稳定，因此用TCP来实现内部的传输。这是一个扩散的模型，每个模块通过TCP将流扩散到另外的节点，节点对数据进行相应的处理并将其转发给用户或其他的节点，最终实现流的扩散。图中WebRTC流可以进入或出去，IP Camera和SIP可以作为输入，然后在Browser端进行订阅，实现实时观看的场景。

图中右半部分是数据处理模块，数据处理模块也有相同的接口。每个模块启动时会作为TCP server监听在一个端口，需要从其它模块拉流时作为TCP client从其它模块的TCP server端口将流接过来，这样就可以实现内部流的接入和接出。

流扩散的模型是以连接为导向，每个流在内部的扩散都有相应的TCP连接，每个模块间都可以进行双向地传流。同时，可以实现多路复用，即同一个流可以通过Server传给多个TCP Client，达到扩散给多个接入/数据处理节点的目的。由于是基于TCP的，因此可以保证可靠性，同时在内部我们做了HA的处理，比如当Audio或Video的节点故障时，在内部进行控制使其无缝切换到可用的Audio或Video的节点，用户感受不到服务器节点的崩溃。

内部的流扩散使用统一的原则，使用了publisher和subscriber角色，客户端会publish流或subscribe流，而内部的流从Accessing Node到Audio Node时，Accessing Node是publisher角色，Audio Node是subscriber角色，因此整个模型在是统一的。接入节点采用“1对N”原则，即一个发布者到多个订阅者。处理节点采用“N对N”原则，即多个发布者到多个订阅者。

之前提到，最初设计的架构以分布式部署为基础，每个模块可以独立部署，还可进行多instance部署。图中是一个常用的分布式部署的场景，外缘一周是接入节点，中间的数据中心有Media处理模块、录像模块和信令交互服务器。

整个分布式部署系统中，各个工作节点间有流的扩散。Cluster Manager主控整个cluster并提供服务发现和负载均衡功能，每个工作节点启动时就会在Cluster Manager中注册，Cluster Manager在调度时根据不同的调度策略将流或处理任务分发到不同的节点，实现服务负载均衡。同时，用户可以根据场景配置不同的负载均衡策略(last-used, least-used, most-used, round-robin ,randomly-pick)。此外，我们也有就近接入的功能，根据用户的region来选择较近的接入节点并进行连接。

这是我们部署的另一个场景，这张图展示了各个Module如何在多个location间进行部署。在数据中心，我们将主控模块，如management-api（作为RESTful Server）、cluster-manager和conference-agent等部署在云端Geo2。同时有三个场馆，第一个运动场馆接入一个360摄像头，对流进行拼接等操作后，在第一个场馆即Edge Server上部署一个接入节点streaming-agent。由于要对音频进行拼接等操作，将audio-agent和video-agent进行就近部署，然后对流进行处理。

其他场馆或其他地方的人想要观看时，可通过RESTful Server来控制，即发送RESTful请求就可通过streaming-agent接入到location 1的服务器。再者，有些用户想通过WebRTC来订阅前面的流，就可在Geo3部署Web Server、portal（信令服务器）和webrtc-agent（WebRTC的接入节点），然后在这个location里的用户通过手机或browser来订阅Geo1里Camera的流。同样，Geo4也可部署上述3个模块来订阅。这就是多个site下各个模块部署的应用场景，这满足了大部分用户的需求，虽然整个部分在四个不同的location，但这还是同一个集群，通过Geo2的模块主控来控制整个集群。

这种部署也存在一些问题。用户使用刚才描述的场景时，首先要保证内部网络状况良好，比如都是专网。同时在规模较小、部署的module较少时，不会有问题发生。但用户进行超大规模集群部署时（部署模块如WebRTC agent、数据处理模块很多），由于内部依赖RPC进行通信，且RabbitMQ本身有性能瓶颈，会出现Heavy load的问题。需要优化RabbitMQ。另外一个问题是，之前的假设前提是agent和agent间是专网，网络较好，但由于用户使用的场景较多，比如远距离通信等，可能出现网络不稳定的情况。

同时，在上一张图中，集群部署在四个地方，主控跟其它模块分别在不同的区域，若Geo2与Geo3之间的网络不通，那么Geo3的用户完全无法接入集群。在Edge network部署的场景下，无法进行区域的自治，即没有与cloud连接时，不知道怎样使本地的用户继续互连。单集群的方案无法解决这些问题，所以我们提出多个集群级联的方案。

跨集群的部署，在每个Edge端或某个特定区域内，部署整个集群，这样即使与云端或中心节点的网络断开，这个区域内服务也可独立地进行工作。但是，使用跨集群的部署也要考虑一些问题。比如要考虑用户的就近集群的选择。另外，我们有conference room的概念，那么要考虑如何同步房间的事件。同一个会议在不同的集群时，要考虑事件怎样进行同步，以及媒体流在不同集群间要怎样扩散。同时OWT是低延迟的音视频的解决方案，我们要考虑如何保证low latency streaming。

我们选择了QUIC来进行级联传输，那为什么我们选择QUIC呢？我先简单介绍一下QUIC。

QUIC是谷歌提出的新的传输协议，QUIC于2016年提出，去年在IETF上已有了相关的规范。QUIC基于UDP，与TCP和TLS方案相比有什么好处呢？QUIC天然自带TLS，因此是一个安全的协议，从图中可以看到，QUIC在UDP之上，带有传输控制和TLS功能，目前的HTTP/3是基于QUIC进行的。QUIC的连接建立时间较短，因此可以在更短的RTT内建立连接。另外，QUIC有拥塞控制，由于QUIC在用户层，因此可以做更多的控制，如拥塞控制等可进行配置。

此外，我们在图中可以看到，HTTP1.1和HTTP/2有队头阻塞的问题，因为它们都基于TCP，当出现丢包现象时，后面的流就会发生阻塞，所以存在队头阻塞问题。QUIC解决了这个问题，虽然在同一个连接内，但Stream 2里出现丢包时，Stream 1和Stream 3的包的传递不会受到影响，只会影响Stream 2的流的传递。以上提到的优点是我们选择QUIC的部分原因。

另外，之前提到内部模块间的传输是基于TCP的，我们也做了基于QUIC的内容与之进行对比。在相同的情况下，在Client端使用WebRTC，内部的传输使用TCP或QUIC，在30ms的delay下，控制不同的网络丢包，然后在Browser端用WebRTC Internal来观察指标，图中显示的是观察结果。分析图可知，在丢包率为0的情况下，TCP和QUIC的性能差别不大，性能都较好。但在丢包率为5%-10%的情况下，基于QUIC时，在Client端接收到的流更稳定。因此，我们选择了QUIC。

我们选择QUIC作为跨集群间通信的协议，在最上层有一个专门的控制模块，即控制Service，然后在每个区域部署一个集群，在每个集群内部新增两个模块，一个是Event Bridge，另一个是Media Bridge。

Event Bridge是事件传输级联的模块，可以使得两个集群中的相同的房间的信息同步。Media Bridge用于不同集群间的流扩散。中间有一个Relay Node，是可选的，这个我们暂时还未实现。在跨集群的方案中，内部与原来相同，比如Bridge和Local OWT Module间的流的扩散还是基于TCP的，而集群间的流的扩散是基于QUIC的。

刚刚的模式中包含主控模块和集群，那么主控模块需要做哪些事情呢？首先需要做到集群发现。还要进行集群调度，可以基于区域进行调度或基于集群能力进行调度，至于事件和媒体接入节点的调度，是每个集群内部通知中间节点采取怎样的调度。同时还需要做到cluster的状态维护。

我们来看一下跨集群的Event是怎么级联的。在每个QUIC Connection里有Stream，集群间用一个QUIC Connection，每个房间和一个QUIC Stream绑定，就实现了集群间每个房间的流的同步。比如两个集群的room 1通过Stream 1进行事件的传递，room 2通过Stream 2进行事件的传递，room 3通过Stream 3进行事件的传递。Event bridge可进行多个instance部署。

跨集群的媒体的级联也利用了QUIC的特性，不同之处在于每个房间与QUIC Connection进行绑定，每个房间的流与QUIC Stream ID进行绑定。当本地集群房间出现新流时，Event bridge会通知其它集群同一房间的Event bridge，Event bridge再将相应的新流事件通知conference模块再通知其它集群里的同一房间的用户。当房间收到新流事件时，其它集群不一定马上进行订阅，因此不需要马上把流级联起来，而是当另外的集群中有用户需要这个流时，再把流动态地级联传输过来。

级联后pipeline和前面内部流扩散的设计思路是一样的，集群间通过QUIC Transport级联到其它集群。在集群1中，RTSP流通过内部的Streaming Node传到Media Bridge Node，Media Bridge Node再把流传到另一个集群的Media Bridge Node，然后再接到WebRTC Node，最后在浏览器端进行查看。每个集群间流都是双向交互的。

跨集群部署扩展了OWT的部署场景，在边缘网络以及网络不稳定的环境下提供更好的流服务。之前的集群内部署方式也有不少适用的应用场景，用户根据实际的网络环境以及部署环境来选择是否需要跨集群部署。

以上是本次分享的全部内容，谢谢！