于 波，李炫杉，王 卫，徐福龙

1(中国科学院大学，北京 100049)

2(中国科学院 沈阳计算技术研究所，沈阳 110168)

3(东北大学 计算机科学与工程学院，沈阳 110169)

5G的到来让移动设备有了更低延迟的网络环境，也让实时通信有了更好的应用条件.实时通信的应用场景有音视频通话、在线会议、直播等，目前应用最广的是WebRTC框架，其本质是在对等连接下进行媒体流的交换.本文研究的重点是如何优化实时通信的传输，并将QUIC协议应用到了实时传输中测试，并针对性地对QUIC协议进行改进.

本文先分析WebRTC与QUIC两项技术的特点，然后设计出针对实时通信应用场景下的QUIC协议改进方案，最后将改进后的QUIC协议进行应用和验证.

1 相关技术简介

1.1 实时通信技术简介

实时通信(Real-time communications)是一种无传输延迟的信息共享技术，通常通过对等连接(peer-to-peer)，在源地址与目标地址之间的直径路径中发送数据[1].

目前实时通信技术中应用最为广泛的是开源项目WebRTC，该项目由Google，Mozilla和Opera等机构支持.利用WebRTC框架可以调用简单的API在浏览器和移动端应开发实时通信模块，实现几乎无延迟的媒体传输.

1.2 Quick UDP Internet Connection技术简介

Quick UDP Internet Connection技术即快速UDP互联网连接，简称为QUIC协议，该协议由Google开发，是工作在传输层的网络传送协议，目前传输层协议主要是TCP和UDP，QUIC是在UDP协议的基础上改进.QUIC相对于以往的传输层协议有着众多优点：改进了拥塞控制、可以更快地进行连接的建立、多路复用不会出现对头阻塞的情况、使用UUID作为连接标记可以更方便地对连接进行迁移等[2,3].

2 研究现状

目前实时通信技术被广泛应用于视频会议、直播等场景下.特别是WebRTC框架并不局限于Web环境，而是可以很方便地移植到桌面端、移动端甚至是物联网设备上.微软和苹果都在各自的操作系统及浏览器中做了适配和应用[4].另一方面，5G时代的到来使得移动端设备也拥有了更低的时延，这都是实时通信技术飞速发展的条件.针对实时通信技术的体验优化也显得更重要.因此有研究者使用了“动态优化多人传输音视频文件质量以提升体验质量”的思想来优化多对多实时通信场景，比如在视频会议中，参会人员之间传输的流媒体文件存在多种版本，根据每个参会人员使用设备的配置情况，对音视频文件的帧速率、色彩等进行差异化传输[5].文献[6]提出使用Network Functions Virtualization 技术(简称NFV)，发送音视频流媒体文件时让客户端自主地选择流媒体服务质量，为虚拟网络组件分配所需的资源，而且这个资源分配可以根据8实时网络波动进行定制化，节省了服务端资源的情况下保证传输质量.过去在音视频传输领域，流媒体文件的下载都是渐进式的，于是有些研究者提出了HTTP自适应流媒体技术，自适应流媒体的本质是对流媒体文件进行切片.通过不同质量的切片，音视频文件的传输过程结合客户端的网络情况变得更加动态，最终让音视频文件传输的过程变得更加流畅，并保证了最佳的传输质量[7].

但目前QUIC协议主要是应用在Google的产品，如Chromium、Gmail中.其实将HTTP自适应流映射到QUIC实现起来是很方便的[8]，因为QUIC的最初设计就是为了下一代HTTP，QUIC的低时延特性特别适用于实时通信这种媒体交换场景；但另一方面QUIC可以像TCP一样提供可靠性保证，这在实时媒体的传输中往往是不必要的，因为在带宽不足的情况下可以适当地牺牲媒体质量，允许少量的音视频抖动来确保服务质量.因此针对实时传输音视频的场景，对QUIC进行了改进，拓展QUIC协议使其具有“不完全可靠”特性，让实时通信达到最优的交互体验.

3 基于QUIC的实时通信优化

3.1 QUIC协议在实时通信场景的优势

与传输层的另一个主流协议传输控制协议进行对比，在连接建立上，传输控制协议(TCP)的连接建立过程被形象地叫做“3次握手”，这是由于TCP在传输层负责提供“可靠性”传输，3次握手的过程如下：第1次握手是由客户端向服务端发出，申请建立与服务器的连接；第2次握手由服务端发出，告知客户端收到请求；第3次握手是客户端确认建立连接以保证可靠性.显然，3次握手的流程为了可靠而涉及到多次的包传输，因此需要多个往返时间，这种场景无法满足实时通信的要求.而QUIC则更加能够升任实施交付的场景，因为QUIC协议建立连接不需要多个RTT(往返时间)，实现了零往返时间连接.

由于QUIC协议基于UDP协议，因此QUIC在建立连接的时候会携带一次会话中所需要的完整参数，这使得QUIC的连接是0RTT的：不会为了可靠性去确认已发送的数据包.这个“0RTT连接”的特性优化了参与会话的各个终端之间连接建立的速度，很适合用于实时音视频通话场景.更近一步地看两种传输协议在连接建立时的区别：为了保证数据包在传输过程中的安全性，传统HTTP协议使用了TLS作为TCP的安全附加层，因此这个过程其实包括了TCP的3次握手和TLS等多次RTT.而在QUIC协议中，其内置了TLS为客户端进行数据完整性校验和隐私数据防护，这使得QUIC协议既保证了安全加密的同时，还在传输速度上更胜一筹.

在会话标识上，TCP协议通过五元组进行标识，5个元素组成集合用以保证每个会话都有一个唯一标识，它包括：目标IP地址、源IP地址、目标端口号、源端口号、传输层协议.而QUIC的会话标识则更加有效便捷：只需要公共包头和一个唯一标记ID，这样一来QUIC协议便有了以下特性：连接转移，由于标识ID可以被保存，因此一个连接可以在端的网络发生状态时进行连接转移，比如实现无缝的网络切换；NAT重绑，在目前NAT广泛应用的背景下，NAT其实对实时通信P2P连接造成了障碍，因此实时音视频通信时需要通过NAT穿透技术建立连接，这时候会出现NAT竞争的情况.当多个端进行抢占NAT出口时，需要重新绑定端口，这时候QUIC的NAT重绑特性就显得尤其重要.QUIC的会话标识特点使得其对于实时通信场景有着先天的优势.

现在正处在移动互联网的时代，移动端设备成为了实时通信场景最主要的终端设备.移动端有一个特点就是网络环境波动更加频繁，比如由于地理位置的切换或者手机传感器的变化等因素，移动设备的IP地址、Wi-Fi状态、端口号会发生变化.QUIC的连接转移可以帮助移动端的通话场景无断网保持会话，改善通话过程的卡顿或延迟等体验[9-10].

3.2 针对实时通信场景的rQUIC

QUIC协议虽然有着零往返时间、低延迟、连接迁移以及安全等特点，但是在实时通信这种场景下，还是可以针对场景需求进行优化和改进.由于流媒体实时传播追求“实时”这一要素，因此实时通信的场景存在以下特性：面向音视频流文件，清晰度与流畅度之间可以根据网络状态进行取舍，最终达到可以优化实时通信体验质量的效果.考虑到QUIC协议是基于UDP协议进行改进的可靠传输协议，那么在网络状态不好的情况下，QUIC协议能否通过牺牲一定的可靠性以达到提高传输效率的效果呢？于是针对实时流媒体传输场景，直接使用QUIC在弱网的情况下进行测试，发现确实会出现通信方在音视频流上不同步的问题，使得整体表现不尽人意.

根据QUIC直接应用时的表现数据，尝试对QUIC协议针对于实时通信的特定场景进行改进.改进包括以下几个方面：设计一种“不完全可靠”的机制，设计相应的传输帧的格式以及优化拥塞控制策略，使得QUIC更胜任允许适度丢包的通信场景，将改进后的协议命名为rQUIC(r意为real-time).

3.2.1 改进帧格式的设计

rQUIC的数据包格式中需要传输一个最大帧大小的参数dgram_size_max.这个参数用于通信多端进行数据流交换之前，参数类型为int，单位为B，通信多端之间除了告知对方dgram_size_max，还需要携带一系列参数.包括通信端自身可接收的帧长度、负载和类型等.使用rQUIC协议在多个通信终端之间发送“不完全可靠”的数据报时，rQUIC协议会生成一个新媒体流帧，该媒体流帧会被立刻发送，在发送的过程中该帧可能会与其他帧进行合并.rQUIC会尽最大努力交付这些“不完全可靠”的合并帧.当通信终端判定某一端发送数据有已丢失的可能的时，直接通知该终端某个帧已丢失.rQUIC数据报会在丢包时引起ACK帧延迟，但不会在帧丢失后进行包的重新传输，而是对包进行序号重排.通过ACK帧的响应时间控制媒体流的响应接收时间，丢失的数据帧可以在稍后的时间进行接收和确认.而为了防止数据流的尾部丢失而导致客户端无法确定数据流的传输结束时间，把流的结束位置加一个可靠性标记.当通信终端尝试使用的某个数据流已经丢失后，它将收到一个大小为0的流，即填补丢失的数据补充流.最终每个流的最后一个字节进行了可靠传输，则可以实现尽最大努力交付数据流.

3.2.2 部分可靠性标记

部分可靠性标记的设计很适合音视频这种传输场景，对每一帧都增加标记，仅使用一位来表示其可靠或不可靠.增加一个标识位表面上看可能会稍稍增加发送和接收时的开销，但其实造成的影响并不大.这主要是由于音视频这种流媒体文件在传输过程需要往往都伴随着编解码的过程.如图1所示，在传输音视频的编解码流程中，发送方的音视频流首先经过了编码，然后传输的是编码后的数据.在这个编码的过程中，部分可靠性标志位几乎不会增加发送方的开销.而针对于接收方，发送方编码后的文件通过P2P或服务器传输过来，需要使用接收终端的能力进行解码，解码的过程中也很少引起处理开销的增加，当然由于接收终端需要根据数据包中的可靠性标记来判断，对数据流做不同情况的处理，总体来说对于整个通信服务的体验是改进的.

图1 音视频传输编解码

3.2.3 拥塞控制策略优化

CUBIC算法是一种经典的拥塞控制算法，因此在传输协议的拥塞控制上，结合了实时音视频通信场景，对CUBIC算法进行了优化.在QUIC的官方代码中，/core/congestion_control目录下存放的是拥塞控制策略代码，其中CubicBytes即CUBIC算法，通过原理分析了CubicBytes在流媒体传输、实时通信场景的匹配能力.CubicBytes是以Bytes为单位进行计算的，它与CUBIC的区别是计算单位不同，因此分析其中一个算法的理论即可.在经典的BIC算法中，拥塞窗口的大小从最小值Wmin到最大值Wmax的增长过程使用了二分查找算法，其中如果用S代表拥塞窗口增长大小，W代表拥塞窗口大小，那么BIC算法有计算公式：

(1)

Wmin=Wmax×β

(2)

W′min=W

(3)

而CUBIC算法[11]则对BIC算法进行了以下改进，它用一个3次函数模拟BIC算法的拥塞窗口变化过程.由于二分查找算法会导致拥塞窗口增长速度过快，因此设置了阈值以限制其增长，而使用三次函数模拟则可以实现拟合这个曲线，该曲线由以公式(4)-公式(6)描述：

Wmin=Wmax×β

(4)

(5)

W′min=W

(6)

其中C和β为常数.由公式(5)可以看出，该算法对应的曲线增长级别是立方级的.当网络发生丢包时，立方级别的增长曲线会让拥塞窗口的值迅速上升至阈值.而目前实时流媒体传输场景发生在移动端的情况居多，移动端的网络情况常常伴随着波动，这使得拥塞控制必须根据网络状态的变化进行改进.对CUBIC算法进行了自适应算法优化，使CUBIC可以更好地利用带宽.由于QUIC协议的拥塞控制是可插拔的，因此客户端在应用层面可根据自己的需要，对拥塞控制进行定制化，可以方便地改进其拥塞控制.首先是网络状态进行评估，参考的网络参数有当前窗口大小、排队数据包数量、平滑往返时间、最近往返时间、往返时间的最大最小值、以及当前拥塞窗口大小等.使用下面的计算公式来量化网络状态：

RTTlast=a×SRTT+b×RTT

(7)

a+b=1

(8)

其中a和b为经验值，取a等于0.85，b等于0.15.RTT表示往返时间，SRTT表示平滑往返时间，RTTlast表示最新RTT值，公式(7)(8)用于更新最新的RTT值，该RTT值将用于计算下面的吞吐量差值DIFF.使用Exp表示吞吐量的期望值，Act表示吞吐量的实际值，Cwnd表示拥塞窗口大小，通过比较期望吞吐量和实际吞吐量来对拥塞窗口大小进行调整，则Exp、Act和其差值DIFF有计算公式：

(9)

(10)

DIFF=Exp-Act

(11)

公式(11)中的DIFF用于评估队列中数据包的多少，并根据此进行自适应网络状态的算法设计.参数e用于衡量当前网络环境的状态，将其初始值赋值为1，结合DIFF进行判断，自适应策略如下所述：如果e小于DIFF，则进一步比较最新更新过的RTTlast时间和平滑往返时间，当平滑往返时间比最新的RTTlast值大时，判定为网络状况不佳，于是对e进行缩小.反之增大e的取值.当e大于DIFF时，结合Cwnd值和RTT值进行动态自适应变化.如果e值为1则增大滑动窗口大小，如果e值不为1则根据其大小进行增减操作.最后设置拥塞窗口Cwnd的最大值等于300，判断是否达到阈值，以100为单位在算法中动态地增减拥塞窗口大小.当拥塞窗口值没有到达极限值时，可以继续对拥塞窗口进行大小改变.一旦发现拥塞窗口大小到达拥塞窗口的极限值，使用以上参数对网络状态进行判断，如果发现已经出现了网络拥塞情况，则不作出改变；如果发现网络状况还不发生拥塞，则可以对拥塞窗口的极限值增大100.这样就可以使CUBIC算法更快速地对网络状态的变化做出反应.自适应拥塞控制伪代码如算法1所示.

算法1.

输入：e，ACK， DIFF， Cwnd，MaxCwnd，SlowStartThreshold

1.VariableACK=ACK+1

2. Update Variableiable RTT；

3.ifCwnd

4. Slow Start()；

5.else

6. Check network status()； // 判断网络状态

7. Update parameters()； // 更新参数

8.endif

9.ifCwnd≥MaxCwnd

10.Break；

11.elseife>DIFF

12.ifMaxCwnd≥300

13. Update parameters()； // 更新参数

14. Go to Line 17.

15.else

16. Adjust Cwnd()； // 调整Cwnd

17.else

18. Increase Cwnd_Limit()； // 增大窗口极限值

19.endif

改进后算法可以更好地应对网络环境的波动情况，使得带宽得到更加有效地占用，进一步提高网络有效吞吐量.由于对rQUIC的帧格式增加了不完全可靠标记，因此在拥塞控制上进一步对带有不完全可靠标记的数据流的帧内容设置一个Expiration_time参数表示过期时间，当拥塞控制算法对数据包进行延迟返送后，执行以下两个操作，一是判断是否超过过期时间，二是选择性地发送.因为超过过期时间的包在音视频通话过程中及时重发也意义不大，而直接丢弃却很少影响传输后的的播放体验，还可以节省很多传输上的开销.在弱网的环境下，适当地丢包可以保证整个音视频通话的流程度和舒适程度.对过期时间进行判断、处理的伪代码如算法2所示.

算法2.

输入：x，Unreliable Tag，Expiration_time，max_ Expiration_time

1.// Set maximum expiration time设置最大过期时间

2.Variableiablemax_ Expiration_time=x

3.// Check Tag判断是否有不可靠标记

4.ifTag.isUnreliable()

5.ifmax_ Expiration_time > Expiration_time

6. Drop randomly()； // 选择性丢弃

7.else

8. Drop packet()； // 丢弃该包

9.Congestion Control()； // 正常拥塞控制

采用部分可靠性设计的新数据帧格式在对等连接中进行收发数据，可以在可靠的rQUIC数据流与不完全可靠的rQUIC数据流中共享一个握手和认证上下文，在0RTT时间上做更极限的优化；更快的丢包恢复时间，充分适应实时通信、对等连接的场景需要；rQUIC的“不完全可靠”数据流与改进后的拥塞控制算法，可以针对rQUIC数据流是否具有可靠性选择是否进行拥塞控制；鲁棒性得到了增强，改进后的rQUIC协议有着“部分可靠性”优势，仍可以根据序号重排算法对丢包这种不可靠的数据流进行ACK反馈，通信终端仍然可以得到确认信息以判断是否发送、接收成功.因此改进后的rQUIC可以更快地建立通信连接，有更低的延迟.

根据上述对QUIC的研究，将改进后的rQUIC应用到实时通信环境中进行测试，实时通信环境采用WebRTC框架搭建.

4 性能测试

性能测试采用开源测试工具Augmented Traffic Control(ATC)，将rQUIC协议应用到RTC，对比基于TCP的RTMP协议.其中流媒体源文件码率为800kbps，分辨率1280×720，编码格式采用H.264，完全使用硬件编码的方式以保证实验稳定性，测试所用硬件服务器(CPU Intel(R) Core(TM) i5-8400，16GB RAM，240G SSD RAID10)与macOS 10.14操作系统的笔记本MacBook Pro一台和Android 9.0操作系统手机一部.通过模拟不同程度的丢包率和延迟来测试不同协议的表现.

图2是测试环境下所使用的网络拓扑结构，实验的测试过程如下，首先对比的是改进后的rQUIC和QUIC，实验变量为往返时间和带宽.经过几轮测试后，使用每轮结果的吞吐量求平均值作为吞吐量参考值.结果如图3所示，当变量是往返时间RTT时，可以看出在往返时间不大的情况下，两种协议的表现情况并无悬殊，吞吐量也基本都可以保持在峰值附近.但是随着往返时间的不断增大，原始QUIC出现了吞吐量的下降，由此可以推论出，当网络拥塞发生后，原始QUIC的处理能力不如改进后的rQUIC.由于rQUIC针对实时通信场景改进了拥塞控制算法，可以配合“选择性发送”的策略使得网络状态不佳时仍然可以有平稳出色的表现.而当变量为带宽时的实验表现结果如图4所示，当带宽不断增加时，两种协议的平均吞吐量都增加了，但是对比两种协议发现，rQUIC更快地发挥出了对应带宽下的最佳表现，而原始的QUIC则是相对更缓速地增加到了最优的状态.可以推论出拥塞控制算法的改进和丢包策略起到了作用.使得rQUIC协议主动丢掉了一些重发的、没有意义的数据包，传输开销上相对更少，因此在带宽相同的情况下，rQUIC协议的平均吞吐量更优.

图2 网络结构

图3 RTT不同时的实验结果

图4 带宽不同时的实验结果

图5模拟的时rQUIC协议和TCP协议在实时通信场景下的表现对比，测试网络环境的预设丢包率为1%，预设延迟为50ms.通过结果分析，在连接建立的初期，TCP协议率先达到最大的吞吐量，但TCP并没有稳定维持这个最大吞吐量.而rQUIC协议的表现则是平均吞吐量平稳上升，稳定持续维持在不错的吞吐量上，较少地出现了下降情况.随着时间的推移，TCP却出现了多次卡顿的现象，导致有效吞吐量的平均表现一般.由此可以得出以下结论：TCP属于可靠传输协议，通讯时间不断增长的情况下，网络可能会进入拥塞状态，这时TCP传输性能会受到不小的波动，进而影响到通信的质量.“不完全可靠传输”的rQUIC协议虽然舍弃了部分可靠性，但是稳定性得到了增强，传输性能可以持续维持在较高水平，网络性能得到了更加充分的发挥.

图5 丢包率1%延迟50ms时的实验结果

然后对比rQUIC协议和TCP协议在弱网场景下的表现，图6是测试环境预设网络丢包率为10%，预设网络延迟为250ms时的结果对比.由于模拟的网络情况较差，结果显示TCP协议出现了多次传输卡顿，受到丢包的影响，有效吞吐量波动大，导致通信体验不好.相反在此情况下rQUIC协议则更具备优势，rQUIC发挥出了其不完全可靠的特性，丢弃了不需要重传的包以减少网络质量的波动.改进后的rQUIC拥塞控制算法也表现不错，可以针对网络状态的波动进行自适应调整.因此在弱网情况下，虽然也出现了卡顿的情况，但没有使有效吞吐量有太明显的下降，整个通信体验是令人接受的.最后可以得出结论：rQUIC很适合应用在实时音视频通信和类似的流媒体传输场景下.

图6 丢包率10%延迟250ms时的实验结果

5 结 语

本文通过研究传输层协议QUIC的适用场景，将QUIC协议应用到实时通信环境下，并根据QUIC协议可靠性的特点，针对视音频通信做出改进.提出对QUIC进行改进使其在特定环境下表现出“不完全可靠”的特性.改进后的QUIC应用到实时通信场领域可以充分地发挥出QUIC低延迟等特性，为音视频通信提供更优质的体验，这种特性还可以进一步应用到游戏等领域.但由于QUIC协议目前尚未有最终定稿，以后还需根据更新版本后的QUIC进行更进一步的研究、测试和优化.