七牛云QRTC自研传输协议（QRTP），如何提升音画质量？

编者按： 自疫情开始席卷全球，人们对音视频的需求急剧上升。在需求上升的过程中，人们对网络延迟、音画质量的要求也在不断提高。LiveVideoStackCon 2022 音视频技术大会上海站有幸邀请到了七牛云资深开发工程师 —— 于佳老师为我们讲述 QRTN 的网络架构是如何提升用户体验度的，以及分析其中的 QRTP 协议是如何对音画质量进行提升的。

文 / 于佳

整理 / LiveVideoStack

大家好，我是于佳，来自七牛云开发团队，我今天给大家分享的主题是七牛云 QRTC 自研传输协议对音画质量的提升。今天的分享大概分成三个环节。首先我会以一个工程师的视角去给大家介绍和解析一下七牛云 QRTC 的实时转发网络 QRTN 的整体架构，然后进而带出今天的主题，也就是 QRTN 内部的媒体转发协议 QRTP 是如何对整个音画质量进行提升的。第三个环节会去结合实践经验和落地的场景，分享一些 QoE 提升的经验。

01、QRTC 实时媒体转发服务架构

1.1 网络传输对 QoE 的影响

整个流媒体从生产到消费，我大概简化为七个环节。其中的三个环节：发送、转发和接收，会与网络相关。大家都知道网络环境是一个很复杂的环境，相比于采集、编码、解码和渲染，它的环境更加复杂，更加的不可控。

由于网络环境造成 QoE 的下降，是我们日常生活中经常接触到的。比如我们经常感觉到在消费流媒体的时候，有卡顿、延迟和马赛克的现象。其实去溯源的话，多数都是因为网络的拥塞、丢包、乱序和抖动，从而导致了 QoE 的下降。所以接入到一个好的实时转发网络，是提升终端用户 QoE 体验的一个必要的环节。那一个好的 RTC 转发网络它应该具备哪些特点？我大概归纳了四个点。

1.2 面向 QoE 的 RTC 转发网络应具备的条件

以上这四个点是我总结出来的，可能不全，但是每一个都很有代表性。首先，节点覆盖会考虑成本还有用户分布等因素，但是在理想情况下肯定是越多越好。当然，节点覆盖的增多也会增加系统复杂度，加大了管理的难度。但是一个好的 RTC 的转发网络一定是节点覆盖很全面的，包括主要的省市、主要的网络供应商，还有海外的主流国家都是必须要有覆盖的。

第二个点是延迟。实时媒体转发网络相对于传统的 CDN 分发，有一个特点就是低延迟。它对延迟是非常敏感的。延迟大概分成两个层面，一个是接入延迟，一个是转发延迟。第二部分将分享的 QRTP 协议，就是去提升转发延迟的。

第三点高可靠是作为服务必须要具备的能力，体现在容灾能力、快速扩容能力，以及对故障的隔离能力。

最后一个是数据量化。数据量化是在把整个框架搭建好之后，才会去考虑的一个事情，但是它相对来说非常重要。为什么重要呢？因为数据在整个系统中，有三个层面的作用。第一个层面是数据可以为用户通话质量调查，还有日常的排障提供一个有力的依据。然后第二个层面，网络中产生的大量数据，可以帮助我们去提前发现转发节点、接入节点的一些故障和一些不利因素，从而进行预判并规避风险。数据使用的第三个层面，就是当拥有大量的数据之后，这个数据可以通过训练模型和一些合理化的清洗以及处理之后，去反馈给系统，对整个网络形成一个强反馈的机制，然后让系统更加稳定。

针对以上四个方面，整个 QRTN 网络也在不断地迭代，不断地优化。

1.3 QRTN 转发网络演进

这里我大概将 QRTN 的演进简化为三个阶段，包括：单点转发、分布式转发和智能分发。

单点转发比较简单，现在很多开源社区，在实现了整个 WebRTC 协议栈之后，一般都会去做这种单点转发的 SFU 来作为用户体验的一个接入点。单点转发的缺点也是比较明显的，比如单点转发去作为一个对外服务的话，它的容灾能力、承载能力，还有地域覆盖能力都会存在问题。但是由于它部署简单，所以作为功能验证的方式还是非常好的。

我们在内测阶段使用的是单点转发的方式，而在公测阶段，就进化到分布式转发的方式了。分布式转发就是让媒体在内部构建的实时分发的网络下去传输，这样可以降低整个端到端的延迟，并且也可以多点协同，有很强的容灾能力。但是分布式转发发展到一定的阶段之后，系统会变得非常复杂。首先是内部的分发路径，我们之前是基于经验去调整的，所以在管理上难度会有所提升。在结合分布式转发这些局限之后，我们又进一步迭代到智能分发阶段。下面我会结合某些点去讲我们是如何去做智能分发的。

1.4 QRTN 转发服务架构

我把 QRTN 整个网络抽象成四种类型的节点。这个是抽象的，因为可能具体的服务或者节点不是这样。抽象出的四种节点包括：接入节点、转发节点、调度节点和控制节点。这四种类型的节点分别有不同的作用，然后有机地构成了整个 QRTN 的转发网络。

首先接入节点是地域全覆盖的用户接入节点。转发节点负责将所有的接入节点进行连接，在转发节点内部进行跨 ISP 的、跨地域的、跨国家的连接。调度节点负责用户接入的时候应该分配到哪个节点，以及怎么去做容灾和成本的一些优化。最后控制节点去做动态的路由规划，转发节点内部的动态的路由规划是通过控制节点来去完成的。

这里讲一下调度节点在智能分发阶段我们做了哪些优化。早期在用户接入过程中做节点选择时，我们采用了基于地理信息的选择策略，比如某一个地域的用户，他应该就近接入到这个地区的接入节点里。但是经过大量的实践之后，我们发现这种模式是存在一定误差的。因为如果只从单维度去考虑地理信息的话，有些用户接入的 QoE 体验并不是特别的好。最后我们引入了大量的数据参考，结合历史数据做一个加权，再综合它的地理信息去做节点调度。这个是作为智能分发阶段的一个迭代优化点。

1.5 QRTN 智能分发网络

前面环节里面没有体现我们对于数据是如何整理使用的，我们针对整个网络产生的数据构建了鹰眼数据平台和 QoE 评估系统。鹰眼数据平台主要是帮助用户完成通话质量的调查。在实现排障和质量分析的前提下，鹰眼数据平台同时为系统提供了很多的参考信息，比如说动态的路由规划，还有最常用的场景自适应，即根据特定的场景需求在参数方面进行优化。

1.6 QRTN 转发网络 QoE 数据

以上是我以一个工程师的视角对 QRTN 网络做了一些介绍。七牛云整个 QRTN 的网络，对外的 QoS 大概有三个指标。登录时间小于 5 秒、卡顿达标率不低于 99.5%、端到端的延迟是小于 400 毫秒。这个卡顿是指单位统计时间音频 200 毫秒没有渲染记为一次卡顿，视频是 600 毫秒没有渲染记为一次卡顿。

大家可以先记一下 QRTN 网络的指标数据。这里面体现了两个关键字：卡顿和延迟。卡顿和延迟是在整个实践中追求的一个重点，接下来我也会围绕卡顿和延迟这两个点来分享 QRTP 协议针对这两个指标做了哪些优化和提升。

02、传输层媒体转发协议 QRTP

前面我大概分享了一下 QRTN 网络的结构。那么 QRTN 网络内部的流媒体转发该用什么样的协议呢？大家可以思考一下你所接触到的传输层的协议，比如说 TCP 或者 UDP。如果让你去设计一个 QRTN 网络中内部的流媒体转发协议，应该怎样去设计？

我给大家提示一下，有一条主线是：我们整个内部流媒体的转发要解决一个问题 —— 即在保证实时传输的前提下，尽可能大的提高带宽利用率。基于这一设计需求，想一想我们有哪些协议符合这个需求呢？

2.1 常规传输层协议的局限

以上是我整理的几个比较典型的传输协议。基于上面的需求我们来看一下 TCP，我有一个比较深刻的实践经验，有一次对一条跨国的高质量线路通过 iperf 基于 TCP 协议去做测试，1G 的带宽，用 iperf 去跑 TCP 测试大概只有 300 到 400 兆的带宽，为什么呢？是因为这种长肥网络，它的延迟相对较高，轻微的抖动就会导致丢包和拥塞。TCP 的带宽利用率并不高，因为它为了保证传输的质量牺牲了延迟和带宽利用率。其次 TCP 不能多路复用，这是一个很重要的概念。因为整个的连接里面会包含很多 stream，它们互相之间是不能干扰的。

第二个是 KCP 以它为代表性的协议还有很多。这类协议的思路就是通过增加冗余的方式去提高整个传输的质量。KCP 会增加 40% 左右的带宽占用，这也是不符合我们的要求的，因为我们要尽可能高地提高带宽利用率。

最后一个比较典型的传输协议是 QUIC，经过调研之后，它是最接近于我们需求的协议。因为它的设计思路非常符合流媒体的转发，可以去自定义拥塞控制策略，我们可以在上面做很多优化，而且它还支持优先级的管理。但是 QUIC 也有一些的局限性，例如 QUIC 的抗弱网能力较弱，同时 QUIC 协议相对与 TCP 协议需要消耗更多的 CPU 资源和内存资源。所以它不太适合在服务节点之间进行转发，或者说我们可能会基于 QUIC 做一些改进和优化。当然我们不想去重新造轮子，因为我们看到了很多传输层协议的不足和局限后，才去决定自研 QRTP 协议。

2.2 QRT 的设计思想

用于 QRTN 网络内部的传输协议，它的设计思想要满足哪些要求呢？我大概列了一下，首先要业务解耦，它是传输层的，不能跟 RTP/RTCP 协议绑定。传输策略是可调整的，因为我们为了提高 QoE，在不同的场景下会有不同的传输策略。快连接用于提升服务间建联速度，因为这个服务间建联的速度直接影响了转发延迟。

2.3 QRT 的设计思想

上图所示是一个传输层协议的三角关系。分布式系统中有一个非常著名的 CAP 理论，就是一个分布式系统，它不可能同时较好的满足一致性、可用性和分割容错性这三个能力，只能较好地同时满足两个。在传输协议里面也存这样一个三角关系：低成本、低延迟和高质量，在一个传输层的协议中，只能较好地同时满足两个。

举个例子，右下角高质量这个点就是 TCP，它为了实现高质量，延迟会很高，成本也很高。然后再看三角左边这条线就是 UDP，是一个 datagram 传输，它没有针对网络中的丢包、拥塞、乱序、抖动做任何对抗机制。所以它的成本非常低，延时非常低，但是质量是没有保证的，是不可控的。基于这个三角，QRTP 的设计思想是如上图所示这条绿色的线，我们保证低延迟和高质量。同时又能根据场景去调整参数，在低延迟和高质量之间去做一个权衡。

2.4 QRT 协议堆栈

QRTP 的协议栈是基于 UDP 之上的，它既考虑了安全性，又可以在应用层做一些调整。

2.5 QRT 解决的两个核心问题

在前面我提到了一条主线：QRTP 要解决的一个核心问题，就是要在满足实时传输的前提下，尽可能高地提高带宽利用率。那么我给大家推导一下，把这句话拆成两个部分，就是首先要保证实时传输。那我们考虑一下，在传输层导致实时性变差的原因有哪些呢？

大概有两个点，一个就是拥塞，它会导致时延增大。其次是丢包，它会导致重传，从而导致时延的增大。先抛开丢包不提，那拥塞是什么呢？拥塞其实就是网络超发，也就是说发的内容 inflight 的 size 大于了整个网络的承载带宽就会产生拥塞，所以拥塞也就是带宽的超发。

然后我们再考虑刚才的下半句：要尽可能地提高带宽利用率。该如何提高带宽率呢？就是要尽量地多发。前半句说我不能超发，后半句又说要尽可能地多发，这是一个既要又要的问题。

所以再往下推导，为了满足设计需求，QRTP 协议要实现什么呢？就是要实现带宽的精准预测，也就是一定要能实时地预测一个连接的实际带宽是多少，必须要精准地预测带宽之后，才能去决定该如何去分配传输的流量，也就能够满足实时传输和提高带宽利用率这个需求。

那如何去做带宽预测呢？有研究过拥塞控制的同学应该知道，拥塞控制其实就是去做带宽控制的。我们推导之后，会发现整个 QRTP 协议想要去提升质量、满足需求，其实我们只要做好拥塞控制这一件事就好了。因为这个协议比较复杂，整个 QRTP 协议就不在这里赘述了。我着重讲一下它主要解决的问题。然后以这个问题为主线，去分析一下我们是如何去满足这个需求的。刚才推导到要去设计一个好的拥塞控制算法，当然我们还是不想去重新造轮子，所以要参考市面上已有的拥塞控制算法，看一下哪些是适合我们的，哪些不适合。大概的思路就是找到最适合我们的那个，然后在上面做一些调整，去适配我们的业务场景。

2.6 QRT 拥塞控制算法演进

可能大家在学习 TCP 协议的时候，里面大量篇幅都在讲拥塞控制。以 TCP 为例，TCP 里面最经典的就是 CUBIC 拥塞控制。它的算法是基于丢包的，当它发现网络丢包了，那就是发生了拥塞，然后就要乘性减窗去降低 congestion window，来降低发送速率。当降到不丢包之后，再去加性增窗，增到下一次丢包。那就又拥塞了，然后再去降，这样的一个机制，就会导致如上图所示的这条红线。这样的发送速率就会是一个锯齿状的，在一次临界值到下一次临界之间不断地跳。这种方式对于小流量的传输是没有太大问题的，但是对于服务间大流量的并且有实时性要求的媒体转发是不适用的。也就是说 TCP 这种基于丢包的拥塞控制肯定是要避开的。那比较流行的方式就是基于延迟的，当网络在达到临界饱和的时候，RTT 一定会上升的，基于这个理论去选择拥塞控制算法。很幸运看到了 google 发布的 BBR 拥塞控制算法，我们也实践了一下，确实比较符合媒体之间的转发。同时我们在实践中也发现了 BBR 算法的一些缺点，或者说一些不足。在用于适配场景的过程中，我们做了一些调优。

2.7 QRT 拥塞控制算法演进 BBR 原理

BBR 拥塞控制算法提出了 BDP 概念，就是可以把网络想象成一个圆柱形的管道。只要用底面积乘以高，大概就是这个管道的容量。所以 BDP 就是这个容量，它使用最小的 RTT 乘以最大的带宽去推算出一个 BDP 值，然后通过 BDP 去加权控制发送的速率，基本能够精准地预测应该发送多少量。但有一点要记住，它这两个参数：最小 RTT 和最大带宽，是不可能同时测量的。因为在带宽没有满的情况下才能测出来最小 RTT，然后只有在 RTT 开始上升的阶段才能测出来最大的带宽。

2.8 QRT 拥塞控制算法演进 BBR 状态

也是由于这个限制，BBR 有四个状态，它在开始阶段（Startup）会不断地去增加发送量，然后发送到一个临界值之后，进入到一个最排空的状态。排空状态（Drain）之后，这个时候一般就能测出来最小 RTT 了，然后进入到对带宽的探测。而对带宽的探测是一个不断的过程。上面这三个过程，如果任何一个阶段 RTT 超过 10 秒没有探测到，就会进入到 ProbeRTT 状态。这个状态是比较麻烦的，因为它认为这个网络可能发生了拥塞，它会进入一个排空的状态，那么我们后面也针对它进行了一些改进。

2.9 QRT 拥塞控制算法演进 BBR 整体流程

我把 BBR 的工作流程进行了超级简化，可以看到 BBR 其实在主动地做两件事情。前面讲到 TCP 的 AIMD 解决拥塞控制，它是一个非常被动的方法，丢包了我就减，然后没丢包我就增，这种方式会导致什么呢？很多丢包是发生在拥塞之后的，这时再去调整已经晚了。BBR 吸取了这个教训，它是非常主动的、非常实时的根据发送的、在 inflight 状态的、还有 ACK 回来的事件，主动地探测最大带宽和最小 RTT，然后通过这个去结合 pacing gain 的加权周期不断地去调整它的发送速率，然后达到一个精准的拥塞控制。

2.10 QRT 拥塞控制算法演进 BBR 存在的问题

在 BBR 整个的实现过程中，它的拥塞控制，可能在场景上比较适合突发流量的发送。但是对于大流量的媒体发送和服务间高带宽的这种场景，可能还是不太适用。

它的不足有两个点，一个是对于高丢包的情况下，比如很多跨国网络，丢包是比较严重的，对于这种高丢包的弱网环境下，它的表现性能是比较差的，带宽利用率很不高。可能百兆的带宽在 25% 丢包的时候就已经没有可用的带宽利用率了。这个也是因为它设计的场景导致的，后面会讲到。

然后另一个点是前面提到它状态机里面有一个 ProbeRTT 状态。这个状态是非常保守的，它会让 inflight 的 size 只有四个 packet，整个传输会处于一个拥塞的状态。

2.11 QRT 拥塞控制算法优化

针对这两个方面的不足，我们做了一些优化。

把 ProbeRTT 这个状态进行优化，让它变得更加激进，它的超时时间缩短。然后排空的方式更加的激进，以一个递减的方式去排空。至于这个排空过程的调参，过程比较复杂，但思路大概就是这样的。

另一个优化的点是改进它的弱网对抗性。弱网就是我前面提到的丢包，通常这种丢包是噪声丢包，有一个特点就是在发生噪声丢包的时候，网络的 RTT 值在统计上是基本不变的。根据这个结论，可以对在噪声丢包的时候给 pacing gain 做一个动态的补偿，也就是基于对噪声丢包的预判去做一个动态化的 pacing gain 补偿，这个也是改进 BBR 的一个很好的思路。我们也是在这上面做了很多的工作，虽然 BBR 理论相对简单，但改造的过程比较枯燥，同时改造的结果是非常明显的。

2.12 QRT 拥塞控制测试数据

上面是我们在百兆网络下做的一组测试， QUIC 使用默认的 BBR V1 拥塞控制，我们自研协议使用改进后的 BBR 拥塞控制，它们在 20 毫秒延迟和 200 毫秒延迟下分别对带宽利用率的使用情况对比。可以看到，淡颜色的 QUIC 在 20% 丢包的时候，已经没有带宽率可言了。而我们自研的拥塞控制算法在丢包达到 50% 的时候，还有 30% 左右的带宽利用率。这个已经基本符合设计目标了，再优化的话可能复杂度会比较高。

2.13 QRT 传输延迟优化

再回到前面提到的 QRTP 的设计思想，就是在保证实时传输的情况下，尽可能大地提高带宽利用率。那么现在带宽的利用率提上来了之后，就要去考虑实时性。其实只要拥塞控制方法做得好，保证传输正常，能够在一个正常的网络层的 RTT 里面去传输就已经没问题了。所以只要拥塞控制算法做好之后，时延问题已经解决了一半。另一半问题还是丢包，因为丢包就是会导致时延。

对于一些高带宽高延迟的网络，由于延迟导致的丢包我们要去做一些优化。这时增加冗余时一种非常有效的手段。FEC 就是一种增加冗余的方式，有很多协议都是通过 FEC 去提高带宽传输质量的。

但是 FEC 有它的缺点，就是开启了 FEC 之后，带宽占用立马就上来了，实际传输效率就不高了。我们结合实践之后，采取了动态 FEC 方法，根据丢包和延迟去做一个预判，从而配置 FEC 的权重。降低连接建立的耗时也可以降低传输时延，服务之间的建联借鉴了 QUIC 中 0-RTT 的方式，通过连接预热的方式能够让服务端之间的连接能够在 0-RTT 的情况下去传输，也就是第一帧数据里面就包含了安全验证和业务数据。

2.14 QRT 对卡顿率和端到端延迟的提升

上图所示是对时延优化后的结果。我们用 720P@25fps@1500kbps 的视频做了延迟优化的验证。可以看到这个数据里面，结合七牛云自研的拥塞控制算法和抗丢包机制后，在 50% 的丢包情况下，相比与 QUIC 协议 900 多毫秒的延迟较低到 300 多毫秒。已经基本符合我们对整个媒体转发的需求了。

2.15 QRT 展望

以上主要是围绕我们在设计 QRTP 协议过程中去解决的一些主要问题，以及如何去做技术决策的。当然，因为 QRTP 协议是基于提高 QoE 而产生的。基于 QoE 提升的技术演进与生俱来就会有一个特点，就是一定要不断地演进。因为 QoE 的定义就是终端用户对于应用或服务整体的主观可接受程度。这里面有个关键词是主观可接受程度，它是无止境、无上限的，所以我们 QRTP 的协议也是在不断地演进，大概演进的思路有两个点。

第一个方向是把 QRTP 协议尝试在接入层去做适配。大家如果调试过 WebRTC 协议多了的话，会发现这个协议还是有很多的槽点，比如它的带宽预测在弱网环境下非常的不可控。FEC 机制比较的臃肿等等。我们想去尝试让 QRTP 在接入层能够做一些改进，但是这个过程会很复杂。因为之前所有拥塞控制的调窗之类的，都是针对服务端的网络场景去做的。如果针对客户端的接入，在弱网、低带宽的情况，可能还要做更大的一些改进或者一些更高的抽象。

第二个方向就是想把我们在整个 QRTP 演进过程中独立出来一些模块适配到公有协议上。一个典型的思路就是 QUIC 的拥塞控制算法是可以自定义的。我们想把优化过的拥塞控制算法移植到 QUIC 上，在内网中或者在业务上需要使用 QUIC 的时候，加载我们自己的拥塞控制算法，可以更好地提升传输质量。

03、基于 QoE 的优化实践

第三个环节结合我们在网络传输层面的一些实践经验，就 QoE 优化的来做一个分享。

3.1 不同场景的 QoE 需求

QoE 本身其实是一个主观性的概念，它的主观性可能体现在不同的场景。因为它是综合了服务层面、用户层面以及环境层面的考量。所以用户在不同的使用场景下，对服务提出的要求也是不一样的。也就是说，当脱离了场景，脱离了用户去谈 QoE 其实都是空谈。所以我们也去充分地调研了在不同场景下，用户对 QoE 需求的一些侧重点。

举一个比较简单的例子。在跨国的实时通话的时候，用户会对什么比较感兴趣呢？首先是时延，而且音频的时延体验是大于视频的。对于这个问题，我只要保证两个用户之间有一个清晰流畅的实时音频，即使视频出现一些轻微的卡顿、丢帧，其实用户的体验度也不会降低的特别多。所以我们在做网络传输的时候，会优先考虑实时性，以及优先考虑音频应该如何去优化。

3.2 基于场景的 QoE 优化策略

还有一个是直播场景，前面我们提到了 QRTN 网络中的一个指标是端到端延迟会小于 400 毫秒。对于直播场景下小于 400 毫秒的端到端延迟，观众是不会有太大感知的。即时发布端到订阅端的延时达到整个 QRTN 网络的最大值，用户也是几乎感觉不到的。也就是说在直播场景下，用户对端到端的延时并不是特别的敏感。其实直播场景，终端用户对播放是否流畅、画面是否清晰的要求是非常高的，所以在直播场景下我们需要做的是去优化流畅度。虽然我们在网络层没有办法去控制基于 ROI 的编码，但是可以在传输层去尽量地保证传输的流畅度。

3.3 实时会议场景优化实践

这里结合两个场景去看一下如何去做 QoE 的优化，即在接入策略和分发策略上，是如何去提升用户的 QoE 体验的。

首先在实时会议场景中，因为会议它是一个虚拟的房间，会分布在整个 QRTN 网络当中，所以我们要尽量地将同一区域的客户调度到同一个节点。这样会减少这个房间在整个网络中的分布程度，从而降低成本，同时还会提升用户的体验。然后尽量让接入端去开启大、小流。这样如果在订阅端不具备很好的网络情况下可以选择小流，或者在缩略图的情况下使用小流，这样用户体验感会有提升。分发策略方面尽量的短路径，要让路径尽量的短。因为发布者的订阅量是很少的，我们只需要去做一些边缘化的分发和转发就好了。

3.4 互动直播场景优化实践

与此相对的一个比较典型的场景就是互动直播。互动直播这个场景就是两个主播之间去进行互动，然后他们的流会被大量的用户订阅。对于这个场景从 QoE 体验来看，观众就是他们最终的终端用户，那么观众对于视频的流畅度以及整个的体验的要求很高。那么如何去提升呢？其实就是在发布端去增加冗余。

可以在发布端去做更激进的带宽预测的补偿。因为一般发布者会在比较专业的工作室，网络环境不会太差。然后再去增加 RED 和 FEC 等冗余编码机制。在分发的时候，因为主播整个的流会被大量的用户订阅，所以要首先完成主干节点的汇聚，让这个流尽量地去走主干的节点。这样对于分发的速度和用户的体验也是非常好的。然后在传输策略上尽量去保证传输质量，实时性可能就会被放到后面。

总结一下，首先，介绍了 QRTN 整个的网络架构。然后又分析了一下这个架构里面的 QRTP 协议是如何对音画质量进行提升的，最后分享了一些经验。其实所有的话题都是在围绕如何去提升用户的体验度，如何去提升 QoE 的质量。这个过程是没有上限的，我们也一直在路上，一直在探索。

谢谢大家，以上就是我本次分享的全部内容。