算网融合是计算和网络两大学科深度融合形成的新型技术簇，是实现算网资源，即取即用愿景的重要途径. 面向算网资源共享的公平性原则是支持实际应用正常运行的关键因素之一，对于保证互联网的顺利运行至关重要^[1-3]. 当网络资源与应用需求发生冲突时，应该有一种方法来确保每个流都能得到合理公平的份额. TCP的拥塞控制框架遵循加性增加/乘性减少原则（AIMD），具有内置的公平性设计. 因此，新提出的拥塞控制算法在被广泛部署之前必须针对其TCP友好特性进行实验评估.

然而，随着视频应用的激增，公平性问题再次出现. 首先，根据思科VNI报告^[4]，视频流量占所有互联网流量的82%，并且其占比还在不断增加. 因此视频应用的公平性从根本上影响着整个互联网的公平性，了解视频流量是否遵循公平原则变得非常重要. 其次，为了获得更好的性能并提高用户满意度，内容提供商调整了他们的网络协议栈^[5]，例如，通过自定义TCP AIMD中的常量来更快地加速发送或更慢地降速发送. 对于在UDP上运行的实时交互类应用，开发人员能够直接在用户态中随意控制发送速率，而不依赖于底层系统（例如操作系统内核）中已构建的被证明表现良好的TCP启发式算法. 随着视频流量份额的增加，这些定制化的尝试可能会对互联网的正常运行构成威胁. 尽管这种自私操作可能在短期内对自己有利，但从长远来看，这些行为将对其他参与者和自身都造成危害. 此外，新提出的用户态传输工具，如QUIC^[6]使问题变得更加复杂，因为QUIC之上的应用为了提高自身的用户体验（QoE）能够自定义发送速率，这大大破坏了公平性原则. 尽管IETF RFC 5166^[7]中提供了公平性设计指南，在RFC 5348^[8]中规范了TCP友好的拥塞控制算法，但目前尚未被广泛采用^[9].

因此，分析这些视频应用的行为以了解它们是否偏离公平性原则并构成潜在风险非常重要. 然而，针对应用发送行为进行测量和理解的研究很有挑战. 首先，受拥塞级别、丢包类型和流量模式影响的高度多样化网络环境对应用行为会产生错综复杂的影响. 通过微观的方式在模拟环境中重现它们的行为非常有挑战. 其次，这些应用越来越多地使用具有端到端加密的专有协议，这使得它们对于外部人员来说就是黑盒子，很难准确地揭示它们的行为. 此外，关联分析应用的QoE与数据传输之间的关系也很困难. 然而，只有了解这种关系才能帮助应用改进其传输策略.

为了解决这些问题，本文构建了一个公平性测量系统并分析了具有代表性的商业视频应用Zoom的行为. 首先，该系统采用一种简化的方式，通过软件控制的网络损伤来模拟不同的网络环境，从而能够研究不同网络状况下的视频应用. 其次，系统能够根据数据包的相似性关联分析捕获到的数据包，将数据包分为不同的类别（媒体包、探测包、重传包、前向纠错包FEC等），在不同的加密级别下都可以正常运行. 最后，成功地将数据传输行为与QoE指标相关联，包括端到端视频及音频时延、视频帧率和视频质量，以确定重传和FEC是否真的提高了传输质量或根本没有. 在测量系统帮助下的主要发现可以总结为5点：

1）自私的带宽占用. Zoom在追求自身QoE的过程中，往往会自私地抢占带宽. 这些资源竞争行为复杂多变，Zoom在不同的场景下表现出不同的带宽抢占行为.

2）自拥塞. 随着丢包率的增加，Zoom显著加快重传或提高FEC比例. 这不仅会引入自身发包造成的拥塞（自拥塞），还会饿死其他参与竞争的TCP流.

3）使用过多的探测包. Zoom使用过多的探测包来探测可用带宽. 然而，就改善其自身的用户体验而言，Zoom过度使用探测包被证明是徒劳的.

4）对缓存区大小敏感. Zoom对具有不同缓存区大小的网络路径的反应不同. 当带宽时延积（BDP）较小时，它会寻求占用更多的带宽份额. 但是，它在较大的BDP值下将保持较低的带宽份额.

5）启动顺序不公平. 较早启动的视频应用不断抢占更多的带宽，而较晚启动的应用则无法取得公平份额. 这表明速率控制算法无法收敛到稳定点.

从测量研究中获得的这些发现启发我们提出一个重要问题，是否有可能设计一种能够平衡QoE目标与公平性原则的实时视频传输算法？事实上，每个应用的QoE目标与公平性之间的冲突经常源于不明智地触发重传，进而造成自拥塞. 通过避免这种“自拥塞”操作并合理地控制发送速率，应用可以同时实现这2个目标. 为此，本文提出了QLibra，这是一种速率控制算法，它可以适应网络波动，同时公平地对待其他参与竞争的流. QLibra采用启发式算法判断当前丢包是否是由于自拥塞，然后触发不同的速率调整逻辑. 我们已经实现了QLibra并通过实验证明它可以取得比现有视频应用更好的QoE，同时对其他参与流无害. 为了所有流的长期利益，应该鼓励负责任的视频应用部署类似QLibra的传输机制.

本文的贡献包括：1）开发了公平性测量系统并对典型视频应用Zoom进行了全面的测量研究；2）分析了若干导致不公平的重要操作，包括自私的带宽占用、自拥塞和使用过多的探测包等；3）提出了QLibra，一种在保持公平原则的同时实现QoE目标的速率控制算法. 通过分析丢包成因并消除自拥塞行为，QLibra能够在不损害其他参与流的情况下提高每个应用的QoE.

1.   挑战与方法论

由于视频流量的快速增长，多个视频客户端越来越有可能共同竞争接入网络中的瓶颈链路. 例如，家庭或校园WiFi网络可以为笔记本电脑、电视、智能手机和平板电脑提供服务，所有这些设备可以同时传输流式视频. 许多研究分析了最后一英里接入网络的性质^[10-11]. 无论是家庭中的WiFi网络还是公共场所中的LTE网络，最后一英里成为瓶颈链路的共识已经确立^[12]. 为了测量和分析这种越来越有可能广泛存在的场景，我们构建了一个测量系统让Zoom^[13]、Bilibili^[14]和iPerf^[15]在接入网络中相互竞争. Zoom^[13]是一款基于云平台的视频通信软件，可以进行虚拟视频和音频会议. Zoom可以被选择作为实时通信应用的代表；Bilibili^[14]提供直播服务，观众可以在其中与主播互动，Bilibili可以被选择作为直播应用的代表；iPerf^[15]是一种广泛使用的网络性能测量工具，它可以创建TCP流来测量两端之间的吞吐量，iPerf可以被选择作为传统TCP连接的代表. 当这3者共享相同的瓶颈链路并一起竞争时，测量它们的吞吐量表现. 事实上，视频点播应用与实时视频应用（如视频会议、直播）存在本质区别，视频点播应用的内容都是提前录制好的，因此其下载模式有鲜明的ON-OFF特征，即周期性地一段时间内持续下载视频片段，一段时间内不进行任何下载；而实时视频应用的内容都是实时产生的，因此其下载模式是持续下载视频内容. 为了更细粒度地进行视频应用竞争行为的测量和刻画，选择了2类在时间尺度上连续传输的实时视频应用和传统TCP流进行比较.

然而，测量过程中存在3个挑战：1）网络参数（带宽、丢包率）不断变化，应用的竞争行为也随之变化，描述和重现不同网络场景下的竞争行为具有挑战性；2）商业视频应用是闭源的，它们使用专有协议加密传输，关于他们的架构和协议的公开信息非常有限，因此了解它们的传输内容和行为非常困难；3）测量和分析应用的竞争行为与相应的QoE指标之间的相关性很有挑战. 为了应对这些挑战，本文构建了一个测量系统来模拟瓶颈链路并观察不同网络场景中视频应用之间的竞争行为；开发了自动化测量工具来揭示这些应用在竞争中的网络流量和QoE特征. 如图1所示，同时启动Zoom、Bilibili和iPerf，它们的数据流经过网络模拟器构建瓶颈链路. 使用Wireshark软件^[16]捕获详细的数据包级别信息，并分析3个应用各自的带宽占用情况，通过改变网络模拟器的网络限制，分析网络参数对带宽公平性的影响.

图  1  公平性测量系统

Figure  1.  Fairness measurement system

下载: 全尺寸图片 幻灯片

为了评估视频应用对链路丢包的鲁棒性，测量了FEC比例和重传比例. 通过分析Wireshark捕获的数据包记录，首先根据数据包的协议类型区分数据包和控制/信令包. 然后将数据包相互比较，如果发现2个数据包的内容相同，则判断发生了重传. 其次将录制视频的码率与Wireshark捕获的吞吐量进行比较. 视频码率与捕获的吞吐量的差值就是重传包和FEC包. 去除计算的重传包后，就可以估计FEC包. 最后可以得到传输过程中的FEC包比例和重传包比例.

为了更好地了解这些视频应用的竞争行为，本文开发了一套自动化测量工具来理解这些视频应用的QoE：

1）为了评估视频质量，使用VMAF工具^[17]，它是Netflix开发的一种感知视频质量评估算法. VMAF根据参考和失真的视频序列预测视频质量. 本文使用虚拟摄像头软件指定特定的视频内容作为视频应用发送端的摄像头输入，这确保了传输的视频内容是一致的和可重复的；将接收端获取的非受限网络传输的视频作为参考视频，与受限网络传输的视频进行对比，在传输过程中视频应用自适应地调整分辨率和帧率；开发了一个帧对齐程序，可以自动对齐参考视频和失真视频的帧，将对齐后的2段视频输入到VMAF工具中，就可以得到通过受限网络传输的失真视频的VMAF分数，设视频帧编号为i（i=1,2,…,N），相应VMAF分数可以由训练好的支持向量机（SVM）模型获得，记为VMAF（i），则视频序列的平均${\rm{VMAF}}分数为\dfrac{1}{N}{\displaystyle\sum _{{i}=1}^{{N}}{VMAF}\left({i}\right)}.$

2）为了测量端到端视频时延和视频帧率，开发了一个二维码生成器^[18]，它以可配置的速率（例如，每秒30帧）不断生成二维码，并在二维码中存储相应的时间戳信息；还开发了二维码识别器，它可以不断识别二维码，自动获取时间戳. 在公平性测量系统中并排放置了4台电脑，如图1所示. 2台电脑是视频发送端，1台电脑是视频接收端，1台电脑是视频记录器. 将二维码生成器的内容和视频序列组合在一起作为视频源，指定为发送端的虚拟摄像头输入. 然后发送端通过网络将其传送给接收端. 视频记录器使用视频捕获程序同时记录发送端的原始视频和接收端的接收视频. 在任意给定时间，同时记录的发送端视频二维码与接收端视频二维码之间的时间戳差值就是端到端视频时延. 最后使用二维码识别器来识别录制视频中的二维码，并计算端到端时延样本. 端到端时延样本是实时视频捕获、编码、传输、解码和渲染所产生的时延总和. 此外，还可以通过计算2个二维码之间产生的二维码数量除以相距时间来计算视频帧率. 由于视频应用会根据网络情况调整帧率，并且网络传输本身会对视频内容造成一定的损伤，所以视频发送端和视频接收端的帧率是不一样的. 在实验过程中，由于识别速度快、全程自动化，可以在短时间内采集大量样本，统计计算出端到端的视频时延和视频帧率. 设记录到的发送端视频二维码对应的时间戳为${{t}}_{\mathrm{v}\mathrm{i}\mathrm{d}\mathrm{e}\mathrm{o}\_\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{i}}$，相应接收端视频二维码对应的时间戳为${{t}}_{\mathrm{v}\mathrm{i}\mathrm{d}\mathrm{e}\mathrm{o}\_\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{e}\mathrm{i}\mathrm{v}\mathrm{e}}^{{i}}$（i=1, 2, …, M），则平均视频时延为$\dfrac{1}{M}{\displaystyle\sum _{\mathrm{i}=1}^{{M}}{({t}}_{\mathrm{v}\mathrm{i}\mathrm{d}\mathrm{e}\mathrm{o}\_\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{e}\mathrm{i}\mathrm{v}\mathrm{e}}^{{i}}-{{t}}_{\mathrm{v}\mathrm{i}\mathrm{d}\mathrm{e}\mathrm{o}\_\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{i}})}$.

3）为了测量端到端的音频时延，使用声波分析软件^[19]. 在系统中也并排放置了4台电脑，如图1所示. 2台电脑是音频发送端，1台电脑是音频接收端，1台电脑是音频记录器. 使用重复的滴答声作为音频源，并使用虚拟麦克风将其指定给发送端，发送端通过网络反复向接收端发送滴答声. 音频记录器使用录音软件记录从音频发送端和音频接收端发出的声音. 可以在该软件中直观地分析捕获的音频信号. 由于将发送端扬声器的音量设置得明显低于接收端扬声器的音量，因此幅度较小的脉冲对应于发送端产生的重复滴答声；而幅度较大的脉冲则对应于接收端接收到的滴答声. 本文使用大脉冲和小脉冲之间的时间差作为端到端音频时延. 设记录到的发送端音频脉冲对应的时间戳为${{t}}_{\mathrm{v}\mathrm{o}\mathrm{i}\mathrm{c}\mathrm{e}\_\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{i}}$，相应接收端音频脉冲对应的时间戳为${{t}}_{\mathrm{v}\mathrm{o}\mathrm{i}\mathrm{c}\mathrm{e}\_\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{e}\mathrm{i}\mathrm{v}\mathrm{e}}^{i}$（i=1, 2, …, K），则平均音频时延为$\dfrac{1}{K}{\displaystyle\sum _{{i}=1}^{{K}}{({t}}_{\mathrm{v}\mathrm{o}\mathrm{i}\mathrm{c}\mathrm{e}\_\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{e}\mathrm{i}\mathrm{v}\mathrm{e}}^{{i}}-{{t}}_{\mathrm{v}\mathrm{o}\mathrm{i}\mathrm{c}\mathrm{e}\_\mathrm{s}\mathrm{e}\mathrm{n}\mathrm{d}}^{{i}})}$.

2.   资源竞争测量

在测量这些视频应用的性能表现之前，首先描述它们的工作流程以及产生的流量类型. 通过查看数据包记录发现，Zoom使用了2种传输协议：用于传输控制消息的TCP协议和用于传输音视频数据的UDP协议. Zoom在应用层构建速率控制方案，根据网络状况调整其发送速率和FEC冗余度. 有趣的是，Zoom也将网络成本考虑在内，在可能的情况下尝试节省连接云端的通信成本. 我们发现，当视频会议只有2个与会者时，它采用点对点通信；但当有3个或更多与会者时，它就会切换到客户端—服务器架构. 由于客户端—服务器架构是Zoom中的普遍场景，我们在实验过程中主要是测量客户端—服务器架构. 对于Bilibili直播来说，主播总是把直播流媒体内容推送到云端，观众再从云端拉取内容. 因此，Bilibili中的这2个连接都是基于TCP协议运行的.

通过将3个不同应用（Zoom、Bilibili和iPerf）的接收端在同一设备上启动，强制它们的流通过一个共享的瓶颈链路. 然后分别改变带宽限制、丢包率、缓存大小和启动顺序来观察它们之间的资源竞争行为. 在测量过程中，我们希望获得收敛状态并避免瞬态阶段，因此通常在应用启动后等待1 min再开始测量，以便应用进入稳定状态，然后开始一个10 min的测量周期，在此周期捕获所有针对不同网络场景的数据包，每个场景重复10次，计算相应数据的均值和标准差.

执行此类测量能够揭示这些黑盒应用的内部处理逻辑. 结果表明在不同场景下它们的资源抢占行为不断变化，没有应用能够始终超过其他应用. 例如，Zoom在带宽受限的情况下压制其他应用，但Bilibili在BDP较大时则处于领先地位. 它们在不同场景中表现出不同程度的抢占行为，并且比传统TCP流iPerf更具攻击性，本文在2.1~2.4节中介绍主要的测量结果.

2.1   限制带宽

本文使用网络模拟器将带宽分别限制为0.5 Mbps、1 Mbps、2 Mbps、4 Mbps和8 Mbps. Zoom、Bilibili和iPerf的数据流都经过该瓶颈链路. 使用Wireshark^[16]抓取网络模拟器和无线接入点之间的数据包，并分析这3个应用的吞吐量占比. 设Zoom、Bilibili和iPerf的平均吞吐量分别为${\mathcal{G}}_{1}$、${\mathcal{G}}_{2}$和${\mathcal{G}}_{3}$，则总吞吐量${\mathcal{G}}_{\mathrm{s}\mathrm{u}\mathrm{m}}={\mathcal{G}}_{1}+{\mathcal{G}}_{2}+{\mathcal{G}}_{3}$，Zoom、Bilibili和iPerf的吞吐量占比分别为$\dfrac{{\mathcal{G}}_{1}}{{\mathcal{G}}_{\mathrm{s}\mathrm{u}\mathrm{m}}}$，$\dfrac{{\mathcal{G}}_{2}}{{\mathcal{G}}_{\mathrm{s}\mathrm{u}\mathrm{m}}}$和$\dfrac{{\mathcal{G}}_{3}}{{\mathcal{G}}_{\mathrm{s}\mathrm{u}\mathrm{m}}}$，结果如图2（a）所示. 当限制带宽比较低的时候，Zoom和Bilibili猛烈地抢占有限的带宽资源，其中Zoom抢占带宽能力最强，其次是Bilibili. 传统的TCP流iPerf被挤压到吞吐量占比低于10%. 具体来说，当限制带宽为0.5 Mbps和1 Mbps时，Zoom的发送速率分别接近0.6 Mbps和0.9 Mbps. 在这种情况下，Zoom的发送行为加剧了瓶颈链路的拥塞，这不仅抢占了竞争者的资源，降低了竞争者的性能，而且自身也无法获得收益（即出现自拥塞）. 当限制带宽达到2 Mbps及以上时，Zoom成功获取到它所需要的带宽（约1 Mbps）并保持在这个吞吐量. 当限制带宽达到4 Mbps及以上时，Bilibili也成功获得了自己需要的带宽（约2 Mbps）并维持这个吞吐量. 传统的TCP流iPerf占用剩余的带宽资源.

图  2  Zoom、Bilibili和iPerf在不同带宽限制下竞争时的吞吐量占比和Zoom的吞吐量构成

Figure  2.  Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted bandwidth, and throughput composition of Zoom

下载: 全尺寸图片 幻灯片

本文还分析了Zoom在这些限制带宽场景下相应的吞吐量构成，如图2（b）所示. 在不同的限制带宽条件下，Zoom通过发送FEC包来抵抗网络丢包，这是实时流媒体中实现可靠性的常用方法. 在实验中发现Zoom的FEC冗余包比例一般在25%~35%之间. 这说明Zoom为了保证自身的用户体验，发送了大量冗余的FEC包来抢占带宽. 与FEC不同，重传仅在需要时添加冗余，因此带宽效率更高. 从图2（b）中可以发现，Zoom采用了不同的重传比例来辅助传输. 与使用FEC相比，使用重传的一个主要缺点是在网络时延较大时效果不佳. 因此，当限制带宽降低到0.5 Mbps且相应的网络往返时延（Round-Trip time，RTT）增加时，Zoom会降低重传比例并相应增加FEC冗余包比例.

通过分析Wireshark捕获的数据包记录，发现Zoom在网络带宽受限的情况下，在测量过程的早期阶段使用探测数据包来探测可用带宽. 在图3中展示了在1 Mbps限制带宽下竞争时Zoom的详细信息，包括Zoom的吞吐量、卡顿持续时间和探测数据包的数量. 如果2个相邻视频帧的内容完全相同，则判断发生卡顿事件. 为了更好地在时间序列中展示卡顿时长，将某个时间点的卡顿时长表示为该时间点前后10 s内的累计卡顿时长. 同理，某个时间点的探测报文数表示为该时间点前后10 s内发送的探测报文的累计数. 从图3中可以观察到吞吐量的突发与探测包数量的突发是一致的. 推测吞吐量突发是由探测数据包突发引起的，这也导致相应的卡顿持续时间增加. Zoom使用探测数据包来探测可用带宽，这不仅会占用额外的带宽资源，对其他应用造成不公平的影响，还会阻塞自身并导致自身的卡顿事件.

图  3  在1 Mbps限制带宽下竞争时Zoom的吞吐量、卡顿持续时间和探测包数

Figure  3.  Zoom’s throughput, stall duration and probing packet count under the 1 Mbps restricted bandwidth

下载: 全尺寸图片 幻灯片

2.2   限制丢包率

由于在实验中只进行了Zoom、Bilibili和iPerf这3个应用竞争行为的测量，这3个应用的总吞吐量需求较小，为了给它们构建竞争环境并更细粒度地观测它们之间的竞争行为，本文使用网络模拟器将带宽限制在了2 Mbps，并将丢包率分别控制在1%、2%、5%、10%和20%. 由于数据包是在进入网络模拟器之前捕获的，因此这些数据包的总吞吐量可能略微超过2 Mbps.

图4（a）展示了3个应用的吞吐量占比. 随着丢包率从1%上升到20%，iPerf的吞吐量占比从20%下降到4%，Bilibili的吞吐量占比从44%下降到24%. 不过在这个过程中，为了保持接收端的吞吐量，Zoom的吞吐量占比从36%提升到72%，发送速率从0.71 Mbps提升到1.42 Mbps. 可以看出，随着网络丢包率的增加，Zoom在带宽占用方面变得越来越激进，使其他参与的流处于饥饿状态. 另一方面，当丢包率达到20%时，Bilibili仍能保持24%的吞吐量占比，远高于iPerf. 可以推测，虽然Bilibili使用TCP连接，但它调整TCP协议栈中的参数以提高自身性能.

图  4  Zoom、Bilibili和iPerf在不同丢包率限制下竞争时的吞吐量占比和Zoom的吞吐量构成

Figure  4.  Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted packet loss rate, and throughput composition of Zoom

下载: 全尺寸图片 幻灯片

图4（b）展示了Zoom相应的吞吐量构成. 随着网络丢包率的增加，Zoom增加FEC冗余比例. Zoom将丢包率量化为多个不同的级别，并根据当前检测到的网络丢包情况来确定FEC级别^[20]. 结合视频帧中的数据包数量，Zoom最终确定相应帧中添加的FEC冗余数据包数量. 当网络RTT较小时，Zoom采用重传作为补充方案. 从图4（b）中可以发现，当丢包率达到20%时，Zoom显著提高了FEC比例，同时根据FEC抗丢包能力调整重传比例.

2.3   限制缓存大小

首先将带宽限制在2 Mbps以构建Zoom、Bilibili和iPerf相互竞争的环境. Zoom的吞吐量占用约为1.2 Mbps，RTT约为230 ms. Bilibili的吞吐量约为0.8 Mbps，RTT约为10 ms. iPerf的吞吐量和RTT极低，可以忽略不计. 因此估计1×BDP=1.2 Mbps×230 ms（BDP_Zoom）+0.8 Mbps×10 ms（BDP_Bilibili）=35.5 KB. 然后使用网络模拟器将缓存区大小分别限制为1/4 BDP、1 BDP、4 BDP、16 BDP和64 BDP.

吞吐量占比的结果如图5（a）所示. 当缓存区比较小时（1/4 BDP、1 BDP和4 BDP），Zoom会占用很大比例的吞吐量. 当缓存区增加到16 BDP时，Zoom的吞吐量占比下降，而Bilibili的吞吐量占比增加. 因此推测缓存区大小的增加导致排队时延的增加. 对时延敏感的Zoom不再参与带宽抢占，时延容忍度更高的直播应用Bilibili则继续抢占带宽，体现出变化的竞争策略. 当缓存区大小增加到64 BDP时，Zoom和Bilibili的吞吐量占比都下降了，传统的TCP连接iPerf占总吞吐量的81%. 这说明此时的缓存区大小也达到了Bilibili的阈值，Bilibili不再参与竞争. 结果表明，不同的缓存区大小将触发不同应用的不同竞争行为. 当缓存区较小时，Zoom占用吞吐量的60%左右. 随着缓存区的不断增加，Bilibili首先表现出抢占带宽的自私行为，然后是iPerf. 可见，竞争行为是复杂多变的，并且每个应用在不同场景下都有自己的自私行为.

图  5  Zoom、Bilibili和iPerf在不同缓存大小限制下竞争时的吞吐量占比和Zoom吞吐量构成

Figure  5.  Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted buffer size, and throughput composition of Zoom

下载: 全尺寸图片 幻灯片

图5展示 Zoom、Bilibili和iPerf在不同缓存大小限制下竞争时不同应用的吞吐量占比和Zoom的吞吐量构成. 当缓存区大小为1/4 BDP、1 BDP和4 BDP时，Zoom的吞吐量占比在60%左右浮动，这时候Zoom还传输了大量的FEC冗余数据来保证其用户体验. 当缓存区大小达到16 BDP和64 BDP时，Zoom的吞吐量占比显著下降. Zoom相应降低了FEC的比例以减少冗余. 同时，当缓存区大小增加时，RTT将继续增加. 这样一来，Zoom也降低了重传的比例，以减少时延的影响.

2.4   不同的启动顺序

在2.1、2.2、2.3节的3组实验中，首先在不限制带宽的情况下将3个应用全部启动. 当它们达到稳定状态时，开始限制带宽. 因此，实验中并没有讨论应用的启动顺序对竞争行为的影响. 在2.4节中研究启动顺序对竞争行为的影响. 为了构建竞争环境，首先使用网络模拟器将带宽限制为2 Mbps. 然后按照不同的顺序启动不同的应用. 用A、B和C分别表示Zoom、Bilibili和iPerf. 例如ABC表示先启动Zoom，然后是Bilibili，最后是iPerf. 其他表达式的含义可以类推. 本文测量了6种可能的顺序（ABC、ACB、BAC、BCA、CAB和CBA）.

图6（a）展示了3个应用的吞吐量占比. 可以发现，应用的启动顺序影响带宽占用，3个应用的吞吐量占比从大到小的顺序与其启动顺序基本一致. 也就是说，最先启动的应用具有占用更多吞吐量的优势. 还有一个比较有意思的现象是Zoom在先启动时的吞吐占比比Bilibili在先启动时的吞吐占比高，也比iPerf在先启动时的吞吐占比高. 这在某种程度上反映了3款应用抢占带宽的能力，即Zoom强于Bilibili，Bilibili强于iPerf. 该实验还表明视频应用的码率控制算法无法收敛到一个稳定点. 较早启动的应用不断抢占更多带宽，而较晚启动的应用则无法获得公平份额.

图  6  Zoom、Bilibili和iPerf在不同启动顺序下竞争时的吞吐量占比和Zoom的吞吐量构成. （A：Zoom，B：Bilibili，C：iPerf. ABC表示先启动Zoom，然后是Bilibili，最后是iPerf. 其他表达式的含义可以类推）

Figure  6.  Throughput ratio of Zoom, Bilibili and iPerf when competing with different start order, and throughput composition of Zoom (A: Zoom, B: Bilibili, C: iPerf. ABC means that we start Zoom first, then Bilibili, and finally iPerf. The meaning of other expressions can be deduced by analogy)

下载: 全尺寸图片 幻灯片

如图6（b）所示，当Zoom先启动时，Zoom吞吐占用量较高，对应的FEC比例也较高. 当其他应用先启动时，Zoom会降低自身的FEC比例. 另外，Zoom使用不同的重传比例来辅助FEC传输.

3.   QoE表现分析

为了更好地理解视频应用的竞争行为，本文使用自动化测量工具来测量这些应用的QoE指标，包括视频质量、端到端视频/音频时延和视频帧率. 和第2节一样，也构造了Zoom、Bilibili和iPerf相互竞争的不同网络场景，包括限制带宽、限制丢包率、限制缓存大小和不同的启动顺序.

3.1   限制带宽

使用网络模拟器将带宽分别限制为0.5 Mbps、1 Mbps、2 Mbps、4 Mbps和8 Mbps. Zoom、Bilibili和iPerf的数据流都经过这个瓶颈链路. 测量了Zoom和Bilibili的QoE表现，如图7所示.

图  7  在不同带宽限制下竞争时Zoom和Bilibili的QoE表现

Figure  7.  QoE performances of Zoom and Bilibili when competing under different restricted bandwidth

下载: 全尺寸图片 幻灯片

在不同的限制带宽条件下，Zoom的端到端视频和音频时延基本在百毫秒级别，而Bilibili的视频和音频时延在几十秒级别，这是由不同的应用需求造成的. Zoom是一个视频会议应用，需要很强的实时交互，而Bilibili是一个直播应用，观众对抖动更为敏感.

与视频相比，音频对用户体验更为重要. 我们发现Zoom和Bilibili的视频时延都高于音频时延. 因此推测当带宽受限时，应用会优先传输数据量较小且对时延更敏感的音频内容. 另一个有趣的发现是当限制带宽降低时，Zoom会降低视频帧率以保障音频时延，因为音频在在线会议环境中更为重要. 具体来说，当限制带宽从1 Mbps降低到0.5 Mbps时，Zoom接收端的平均帧率从10.5 FPS降低到1.5 FPS，而音频时延减少了0.2 s.

由于带宽受限导致的丢帧和卡顿事件，VMAF分数不是很高（满分为100分）. 当限制带宽从0.5 Mbps增加到2 Mbps时，Zoom的VMAF分数从25.54增加到48.14，略高于Bilibili. 这是因为Zoom抢占带宽的自私行为有效地保证了自身的视频质量. 但是，当限制带宽达到4 Mbps及以上时，Bilibili获得了它需要的带宽，相应VMAF分数在提高.

3.2   限制丢包率

首先使用网络模拟器将带宽限制为2 Mbps以构建竞争环境，然后用它来控制丢包率分别为1%、2%、5%、10%和20%. Zoom和Bilibili的QoE表现如图8所示.

图  8  在不同丢包率限制下竞争时Zoom和Bilibili的QoE表现

Figure  8.  QoE performances of Zoom and Bilibili when competing under different packet loss rate

下载: 全尺寸图片 幻灯片

随着丢包率的增加，Zoom的音频时延基本保持稳定，对应的视频时延略有增加，Bilibili的音频和视频时延不断增加. 由于Zoom会根据不同的丢包情况抢占带宽来保证自身的传输，因此其接收端的视频帧率保持稳定，FPS为13~16. 在丢包率为20%的情况下，带宽被Zoom严重占用. 此时，Bilibili占用的带宽相对较低，相应的接收端视频帧率也较低，约为6 FPS.

随着丢包率的增加，Zoom的VMAF分数也出人意料地增加. 如图8所示，当丢包率为20%时，Zoom的VMAF分数达到了50.68，属于比较高的得分. 这是由于它在网络恶化时激进地抢占带宽资源，表现出对其他竞争者不公平的行为. 在整个过程中，Bilibili的VMAF分数由于分配的带宽较小而不断下降.

3.3   限制缓存大小

为了营造竞争环境，首先将带宽限制在2 Mbps，然后将缓存大小分别限制为1/4 BDP、1 BDP、4 BDP、16 BDP和64 BDP. 本文测量了Zoom和Bilibili相应的QoE表现，结果如图9所示.

图  9  在不同缓存大小限制下竞争时Zoom和Bilibili的QoE表现

Figure  9.  QoE performances of Zoom and Bilibili when competing under different buffer size

下载: 全尺寸图片 幻灯片

当缓存大小持续增加时，Zoom的音频时延和视频时延急剧上升，接收端的视频帧率不断下降. 当缓存大小增加到16 BDP及以上时，Zoom的吞吐量占比已经很低了. 再加上缓存大小增加导致的RTT增加，整体时延较大. Bilibili的情况类似. 不同的是，当缓存大小为16 BDP时，Bilibili的吞吐量占比最高. 因此，相应的音频时延和视频时延都比较低，接收端的视频帧率也比较高. 但是当缓存大小增加到64 BDP时，Bilibili的吞吐量急剧下降，此时的QoE性能表现也比较差.

VMAF分数的表现与吞吐量占比表现基本一致. 当缓存大小增加时，Zoom的VMAF得分不断降低，Bilibili的情况类似. 但是因为Bilibili在缓存大小为16 BDP时吞吐量较高，所以对应的VMAF分数也较高. 当缓存大小增加到64 BDP时，Bilibili的VMAF分数在下降.

3.4   不同的启动顺序

首先将带宽限制在2 Mbps以构建竞争环境，然后按照不同的顺序启动不同的应用. 本文用A、B和C分别表示Zoom、Bilibili和iPerf. 例如ABC表示先启动Zoom，然后是Bilibili，最后是iPerf. 其他表达式的含义可以类推. 本文测量了6种可能的顺序（ABC、ACB、BAC、BCA、CAB和CBA）. Zoom和Bilibili的QoE表现如图10所示.

图  10  在不同启动顺序下竞争时Zoom和Bilibili的QoE表现（A：Zoom，B：Bilibili，C：iPerf. ABC表示先启动Zoom，然后是Bilibili，最后是iPerf. 其他表达式的含义可以类推）

Figure  10.  QoE performances of Zoom and Bilibili when competing with different start order (A: Zoom, B: Bilibili, C: iPerf. ABC means that we start Zoom first, then Bilibili, and finally iPerf. The meaning of other expressions can be deduced by analogy)

下载: 全尺寸图片 幻灯片

随着启动顺序的变化，Zoom的音频时延基本维持在0.57 s左右，变化不大，这说明Zoom可以很好地保障音频时延. 同时，Zoom最先启动时（ABC和ACB）相应的视频时延较低，接收端的视频帧率也略高，因为此时它具有更大的吞吐量占比. 同样，Bilibili先启动时（BAC和BCA）占用的带宽也略高，这导致更低的音频/视频时延和更高的视频帧率.

Zoom先启动时，其VMAF分数较高，这是因为此时Zoom使用FEC包来保证其视频传输，占用了较高的吞吐量. 同样，Bilibili先启动时，它的VMAF分数超过了Zoom的分数.

4.   QLibra：QoE和公平性之间的平衡

第2~3节测量结果表明，Zoom倾向于抢占带宽来保证自身的QoE. 然而，其中一些发送行为被证明是无用的，并且对其他参与者和自身都是有害的. 造成这种情况的一个关键原因是Zoom总是将数据包丢失视为随机丢包，因此触发了一些不必要的重传行为. 如果网络真的出现拥塞丢包，那么就不需要这样的重传，这只会引入额外的拥塞并导致不公平问题. 我们将这类丢包称为“自拥塞”丢包. 基于这些发现，我们提出了传输算法QLibra，它既能够实现应用的QoE目标，同时又能保障参与流之间的公平性. 在本节中，首先介绍QLibra的设计并在本文的测量系统中对其进行实验评估.

4.1   QLibra设计

QLibra的核心思路是确定丢包是否由自拥塞传输引起. 与现有的拥塞控制算法不同，QLibra不会对所有数据包丢失做出同样的反应. 不失一般性，在下文中，我们将基于Reno描述QLibra. Reno基于AIMD等同对待每一次丢包.

QLibra对待自拥塞丢包与非自拥塞丢包完全不同. 具体来说，如果丢包被判断为自拥塞造成的结果，QLibra将触发正常的乘性减模块以快速降低发送速率. 但是，如果丢包不是由于自身拥塞造成的，QLibra将承担一些风险选择不降速，因为在随机丢包的情况下这样做是有意义的. 首先，QLibra将根据丢包率的变化按比例增加拥塞窗口cwnd，以便发送端尽快恢复. 为了更好地利用链路，QLibra也避免触发乘性减机制，但这不会损害公平性，因为丢包已经被推断为随机丢包.

QLibra采用启发式算法判断自拥塞状态. 如算法1所示，算法的输入包括丢包率loss_i、确定算法处理粒度的可配置阈值threshold以及自拥塞状态self_congested，这是一个初始设置为false的布尔变量. 本文将处理过程划分为一组连续的时隙. 一旦当前记录的丢包率loss_i与之前的丢包率loss_i-1的差值超过阈值，那么就触发算法的调节过程.

算法1. 确定自拥塞状态算法.

输入：第i个时隙的丢包率loss_i，丢包率变化的容忍阈值threshold，丢包率loss_i−1的成因self_congested_i−1（true代表自拥塞，false代表非自拥塞，初始化为false）；

输出：丢包率loss_i的成因self_congested_i；拥塞窗口cwnd.

① while |loss_i−1-loss_i|>threshold do

② 　if (self_congested_i−1==true and loss_i−1<loss_i) or 　　　　　(self_congested_i−1==false and (loss_i−2−　　　　　loss_i−1)×(loss_i−1−loss_i)<0) then

③ 　self_congested_i←false；

④ 　speedup_rate←loss_i/loss_i−1；

⑤ 　cwnd←cwnd×speedup_rate；

⑥ 　else

⑦ 　self_congested_i←true；

⑧ 　end if

⑨ end while

本文在图11状态转移机的帮助下介绍算法1.

图  11  状态转移机

Figure  11.  State transition machine

下载: 全尺寸图片 幻灯片

1）从自拥塞到非自拥塞. 如果之前的丢包已被确定为自拥塞丢包，QLibra会立即降低发送速率. 如果此时丢包率继续增加（loss_i−1<loss_i），那么丢包很可能不是由这个发送端引起的，所以状态会过渡到非自拥塞. （算法1中的行②. ）

2）从非自拥塞到自拥塞. 如果丢包率不断增加（即loss_i−2<loss_i−1且loss_i−1<loss_i），推测QLibra冒了太多风险，需要降低发送速率. 因此状态将切换回自拥塞；否则，QLibra将停留在非自拥塞状态. （算法1中的行②. ）

3）保持非自拥塞状态. 由于数据包丢失很可能是由随机网络丢包引起的，因此发送端可以通过向网络发送更多数据来承担一些风险. 它首先根据丢包率变化计算加速比speedup_rate←loss_i/loss_i-1，然后相应增加拥塞窗口，以便传输可以更快地从丢包中恢复. （算法1中的行④~⑤. ）

4.2   QLibra测量

基于QUIC协议栈实现了QLibra，修改其中原生Reno拥塞控制算法，并在上层实现了实时视频应用，接着在测量平台上进行了实验评估. 具体来说，探究了QLibra在与Zoom、Bilibili和传统TCP流竞争时关于保障公平性和QoE的有效性.

1）第1个实验测量了QLibra和Zoom在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量表现. 如图12所示，最初QLibra和Zoom各占有大约900 kbps的吞吐量. 当添加1000 kbps带宽限制时，QLibra和Zoom都出现了吞吐量突发增长. 然后QLibra和Zoom都进入稳定阶段，QLibra的平均吞吐量为590 kbps，Zoom的平均吞吐量为570 kbps. 基于此，可以推测QLibra实现了比Zoom更好的QoE. 当添加10%的丢包率限制时，QLibra和Zoom都会发送额外的数据包来保障自身的性能. QLibra的平均吞吐量为1160 kbps，Zoom的平均吞吐量为1180 kbps. 可以发现，当QLibra判断丢包是由于其他应用抢占带宽导致的时候，它也会主动提升速率以获得更好的性能. 总体而言，QLibra和Zoom一起竞争时，带宽分配相对公平.

图  12  QLibra和Zoom在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量

Figure  12.  The throughputs when QLibra and Zoom competing under 1000 kbps restricted bandwidth and 10% restricted packet loss rate

下载: 全尺寸图片 幻灯片

2）第2个实验测量了QLibra和Bilibili在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量表现. 如图13所示，QLibra最初占有约900 kbps的吞吐量，Bilibili占有约1900 kbps的吞吐量. 当添加1000 kbps带宽限制时，QLibra和Bilibili都出现了吞吐量突发增长，然后它们进入稳定阶段. QLibra的平均吞吐量为560 kbps，Bilibili的平均吞吐量为500 kbps. 基于此，可以发现QLibra和Bilibili一起竞争时带宽分配相对公平. 当添加10%的丢包率限制时，QLibra和Bilibili都会发送额外的数据包来保障自身的性能. QLibra的平均吞吐量为1160 kbps，Bilibili的平均吞吐量为1960 kbps.

图  13  QLibra和Bilibili在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量

Figure  13.  The throughput when QLibra and Bilibili competing under 1000 kbps restricted bandwidth and 10% restricted packet loss rate

下载: 全尺寸图片 幻灯片

3）第3个实验测量了QLibra和原生Reno在不同限制场景下一起竞争时的性能表现. 如图14所示，最初QLibra和原生Reno各占有大约900 kbps的吞吐量. 当添加1000 kbps的带宽限制时，QLibra的平均吞吐量是540 kbps，原生Reno的平均吞吐量是470 kbps. 基于此，可以推测QLibra对其他参与的TCP流无害. 当添加10%的丢包率限制时，QLibra会发送额外的数据包来保障自身性能，而原生Reno则会迅速降低吞吐量占用. QLibra的平均吞吐量为1120 kbps，原生Reno的平均吞吐量为640 kbps. 可以发现，当QLibra判断丢包是由于自身抢占带宽行为导致时，并没有主动提速. 通过有效判断丢包成因的方式，QLibra可以与传统的TCP流很好地共存.

图  14  QLibra和原生Reno在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量

Figure  14.  The throughput when QLibra and original Reno competing under 1000 kbps restricted bandwidth and 10% restricted packet loss rate

下载: 全尺寸图片 幻灯片

通过以上3组实验发现，QLibra可以有效判断当前丢包的成因. 当QLibra发现已经存在其他流的攻击性行为导致丢包时，也会提高发送速率来保证自身的QoE. 相反，当QLibra发现当前丢包是自拥塞时，它会回退到原生Reno并与其他传统TCP流公平共存. 在第4个实验室中探索一个更实际的场景，即，在瓶颈链路中同时存在攻击性流量（例如Zoom）和传统TCP流量（例如原生Reno）时，我们测量QLibra在与这些不同类型的流相处时的行为.

4）第4个实验测量了QLibra、Zoom和原生Reno在不同限制场景下竞争时的吞吐量表现. 如图15所示，最初QLibra、Zoom和原生Reno各占有大约900 kbps的吞吐量. 当添加1000 kbps带宽限制时，QLibra和Zoom都出现了吞吐量突发增长. QLibra占用的平均吞吐量约为540 kbps. 同时，Zoom占有470 kbps的平均吞吐量. 至于原生Reno，它的平均吞吐量只有60 kbps. 由于Zoom的存在，传统的TCP流量几乎被挤死. QLibra目前能做的就是通过与Zoom抢占带宽来保证自身的QoE，结果是QLibra将自己也保持在高吞吐状态. 当增加10%的丢包率限制时，QLibra和Zoom都开始提高发送速率来抵抗丢包. QLibra的平均吞吐量达到了1130 kbps，而Zoom的平均吞吐量达到了1010 kbps. 原生Reno的平均吞吐量在10%丢包率的影响下有所下降，平均为640 kbps.

图  15  QLibra，Zoom和原生Reno在1000 kbps带宽限制和10%丢包率限制下竞争时的吞吐量

Figure  15.  The throughput when QLibra, Zoom and original Reno competing under 1000 kbps restricted bandwidth and 10% restricted packet loss rate

下载: 全尺寸图片 幻灯片

通过本节实验可以发现，当存在其他攻击性流量导致的拥塞丢包或链路随机丢包时，QLibra会提升发送速率以保证自身的QoE. 当瓶颈链路中存在的流都是TCP友好型时，QLibra的激进发送行为将导致自拥塞丢包. 这时QLibra将回退到传统的TCP流来保证公平性. 实验结果表明，QLibra可以实现比现有视频应用更好的QoE，同时与其他参与的TCP流很好地共存.

5.   相关工作

5.1   公平性测量

先前的研究集中在拥塞控制算法的公平性上，包括协议内公平性（同一算法的2个实例）和协议间公平性（2个不同算法的2个实例）. 对于协议内公平性，Ha等人^[21]报告说Cubic在具有不同RTT的流量之间实现了公平的带宽分配. Hock等人^[22]报告说BBR没有明确的机制可以让多个BBR流量收敛到公平的份额. 对于协议间公平性，Ware等人^[23]展示了当与多达16个基于丢包的拥塞控制算法竞争时，单个BBR流量可以消耗40%的链路带宽. Ha等人^[21]报告说，Cubic对Reno不公平，但这并不显著影响Reno的表现. Cardwell等人^[24]报告说BBR对Cubic不公平，他们正在考虑建模小缓存区的情况. Dong等人^[25]报告说PCC Vivace对Cubic不公平，但是随着Cubic发送端数量的增加，PCC Vivace可以实现公平性. Arun等人^[26]报告说Copa对Cubic不公平，但比BBR和PCC公平得多. 同时，Copa充分利用Cubic不使用的带宽资源. 还有一些研究讨论公平性的度量问题. Ware等人^[3]认为基于损害的度量方法比传统的公平性概念更加实用、更有前景，并且可以适用于更广泛的指标.

关于视频应用的公平性，Jiang等人^[27]测量了现有商业视频客户端的表现，并展示了不同商业解决方案的不公平、低效率和不稳定. Akhshabi等人^[28]重点关注2个视频客户端间的不公平问题，并依据视频应用的开关行为解释他们的测量发现. Huang等人^[29]展示了视频客户端和持久TCP流之间的不公平问题，他们归因于视频客户端很难估计出准确的可用带宽. 这些研究都集中关注传统的视频点播应用，而不是时延敏感型应用，比如直播和实时通信. 此外，Huang^[29]等人也没有分析在不同网络场景下视频应用的行为表现. MacMillan等人^[30]展示了视频会议应用定制的拥塞控制算法导致不公平的带宽分配. 他们还进行了Zoom的2个实例之间的竞争实验，实验结果表明2个实例在超过100 s的时间内都在激烈地抢占带宽，最终一个实例将另一个实例挤死. 即使是相同应用的不同实例，仍然存在不公平行为. Sander等人^[31]使用Zoom作为示例研究了视频会议拥塞控制算法的公平性问题，并研究了部署主动队列管理（AQM）机制的影响. 但是，他们没有将应用的传输行为与QoE指标关联分析，来确定这些发送行为是否真正提高了传输质量或仅仅是不必要的. 此外，Sander^[31]等人希望通过利用诸如FQ_CoDel之类的AQM机制将公平性由网络运营商来控制. 然而，将这种机制部署在网络边缘的数百万个设备上缺乏动力. QLibra设计具有“不伤害自己”的动机，更有可能被视频应用所采用.

有一些研究讨论TCP友好的速率控制（TFRC）. Floyd等人^[8]提出了一种在互联网环境中运行的拥塞控制方案，可以做到在中等时间尺度上与TCP流量公平竞争. Yan等人^[32]提出了用于可扩展视频流媒体的TCP友好速率控制算法，该算法在不同拥塞环境中的表现优于TFRC. 然而，出于自私的原因，目前大多数视频服务都与TFRC的原则偏离^[9].

一些研究提出了QoE公平性，用来衡量不同用户观看体验的相似程度. Nathan等人^[33]使用视频客户端状态和视频特征信息来调整拥塞控制行为以优化QoE公平性. Georgopoulos等人^[34]提出了一个OpenFlow辅助的QoE公平框架，旨在共享网络环境中公平地最大化多个竞争客户端的QoE. Chen等人^[35]认为客户端和网络必须协同以实现QoE公平. Mu等人^[36]引入了一个用户级资源分配模型，该模型可以最大程度地实现自适应流媒体间的QoE公平性. 李杰等人^[37]提出了一种基于资源共享公平概念的多资源公平分配机制. 尽管这些研究关注新算法和已部署算法之间的公平性问题，但仍缺少有关真实互联网公平状况的研究. 为了解决这个问题，本文探讨了视频服务提供商的真实互联网流量是否遵循公平性原则.

5.2   视频应用测量

一些研究测量了商业视频应用，包括视频点播（VoD）、直播和实时通信. Xu等人^[38]对流行的视频点播服务开展了详细的测量研究. Li等人^[39]基于大规模视频点播系统中提取的日志研究了移动用户的行为及相应的视频观看模式. Ghasemi等人^[40]对雅虎的流媒体服务进行端到端特征的刻画，并发现了一系列性能问题. Dimopoulos等人^[41]提出了一种用于检测加密视频流QoE问题的新方法. Wang等人^[42]对直播流媒体应用Periscope的设计和性能进行了详细的分析. Siekkinen等人^[43]也探索了Periscope服务并提供了一些关于关键性能指标的发现. Chen等人^[44]提出了一种工具用来支持移动应用QoE的可重复测量和分析. Dimopoulos等人^[45]开发了一个框架，用于借助机器学习诊断移动视频QoE问题的根本原因. Shafiq等人^[46]介绍了移动视频流性能的表征，并从网络运营商的角度对用户参与的影响进行了建模. Hohlfeld等人^[47]从影响最终用户体验的角度研究了缓存区大小选择的影响. Yu等人^[48]对3款流行的移动视频电话应用进行了测量研究. Xu等人^[49]针对3款视频电话系统开展测量研究. Jansen等人^[50]在模拟网络条件以及实际的有线和无线网络环境中对WebRTC进行了性能评估. Chang等人^[51]测量比较了3个主流的视频会议系统：Zoom、Webex和Google Meet.

这些研究针对一些流行商业视频应用的关键设计和性能开展独立测量，它们没有考虑当多个应用竞争网络带宽资源时出现的公平性问题. 本文提出的机制可以用来测量视频会议软件，实时直播平台和传统的TCP流在不同网络环境中的竞争行为.

6.   讨　　论

互联网作为共享媒介而诞生，必须禁止任何一方滥用. 如果单个应用发送行为过激，不仅会导致不公平，还可能出现网络版本的公地悲剧^[52]. 早期的互联网设计者已经注意到这个问题，并在拥塞控制方面的持续研究中建立了坚实的技术基础和经验教训^[53]. 这些经验已经融入到操作系统提供的套接字接口等底层系统软件中，使得大多数应用开发者不需要重新发明这些算法. 但是，一旦应用开发者获得了自由，如果他们不从历史中吸取教训，那将是危险的. 因此为应用提供合适的抽象接口很重要. 针对视频的场景，定制化的实时通信软件实现肯定比标准WebRTC带来更高的风险，因为后者使用API隐藏了速率控制算法细节. Zoom也正从专有实现切换回WebRTC^[54]，希望Web传输和RTC PaaS等方案可以起到帮助的作用.

以5G为代表的蜂窝网接入技术具有10 Gbps的高吞吐量和约1 ms的RTT，为VR和8K直播等沉浸式应用提供技术支持. 但是，仅靠带宽增加并不能消除风险. 不断增长的需求和设备将更快地填满增加的容量. 如果接入网容量无法以相同的速度发展，这很有可能会将拥塞点移至其他地方，例如骨干网中，进而造成更大的危害.

TCP友好速率控制（TFRC）^[8]是一个不错的设计，但是缺乏部署的动力. Briscoe认为拥塞控制在某种程度上决定了公共互联网上的带宽分配^[55]. 因此，这些分配应该是由一些潜在的经济模型驱动的，而流量公平性没有这样的模型基础. 也就是说，流量不是互联网上的经济参与者，因此没有理由平等地对待它们. 寻找一种符合当前互联网经济模型的带宽分配方式是一个很有前景的方向. 根据我们的测量研究，通过避免对发送者自身有害的发送行为（即自拥塞）可以有效地在QoE和公平性之间保持平衡. QLibra的设计中含有“不伤害自己”的激励机制，这符合视频应用的部署动机.

7.   结　　论

视频流量的显著增长使得人们了解它们的公平属性非常重要. 我们对典型视频应用Zoom进行了广泛的测量研究，并揭示了它如何在不同的网络条件下寻求更好的QoE. 我们发现它的某些行为偏离了公平性原则，尤其是当链路质量恶化时通过发送冗余数据包来饿死其他参与的TCP流. 这些冒险行为源于应用QoE目标与公平性原则不能很好地平衡. 因此，本文提出QLibra来解决这个问题，通过适应不同的拥塞信号来平衡QoE和公平性目标. 实验证明QLibra可以比现有视频应用获得更好的QoE，同时对其他参与的TCP流无害. 为了长期利益，负责任的视频应用应该积极部署类似QLibra的方案.

作者贡献声明：王子逸负责提出关键算法，设计实验方案并撰写论文；胡晓宇负责完成实验并采集分析数据；王歆负责指导实验设计、实现及结果分析；张行功负责指导关键算法的设计；曹振、郑凯负责论文修改与结构设计；崔勇负责指导论文算法和实验的设计并参与论文修改.