qos 流控功能_浅谈流媒体中的流控与QoS

在流媒体传输中，流控和QoS是无法避免的话题之一。然而，在不同的应用场景和需求下，流控和QoS的策略一方面有很大的差异，另一方面在本质上又有很多的共性。本人在北大读博时的课题即为流媒体传输优化，工作后也一直从事流媒体传输相关的工作，本文仅浅谈自己对流媒体传输中的流控和QoS的理解和看法，抛砖引玉。

流控即网络流量控制(Network traffic

control)，百度百科的解释为：一种利用软件或硬件方式来实现对网络流量的控制。它的最主要方法，是引入QoS的概念，从通过为不同类型的网络数据包标记，从而决定数据包通行的优先次序。对于这种解释，我认同前半句，不完全认同后半句，不是因为他错，而是太过片面和局限，具体原因后面会解释。

QoS即Quality of Service，他与QoE的关系和差别，wiki上的定义比较好，有兴趣的可以参考https://en.wikipedia.org/wiki/Quality_of_service。

回到我们的正题，流媒体传输中的流控和QoS。在不同的场景和需求下，流控和QoS的策略差异较大，这主要是不同的应用场景，考虑的需求不一样，从而导致流控策略的设计需要因需而已，例如，在互动场景下，最需要解决的是延迟和卡顿问题，而画面的清晰度(码率大小)和平滑性(码率抖动)则可以稍微牺牲；而在直播场景下，针对不同的直播需求，流畅度、清晰度、延迟等的考虑也不一样。之所以需要区别对待这些需求，是因为当网络环境不好时(在天朝，网络环境极为复杂且着实难以保证网络一直很好)，这些性能之间是相互矛盾的，重此失彼，在动态不可预测的网络环境下，找到最佳的tradeoff并非易事(不然鄙人的博士课题就没得搞了)。本文不打算细究每种场景和需求下的具体策略，仅仅从最上层浅谈一些通用的做法和考虑，有兴趣的可以私聊细节。

流控中最难的是网络预测，即预测网络的可用带宽、丢包率、延迟等等特性。接下来结合自己的看法，简单谈谈目前预测带宽的主要策略的特点(包括优缺点)，关于其他的方面，以后有时间再写写：

滑动窗口：通过计算一段历史时间的数据传输量，用来近似作为当前可用带宽。

优点：简单

缺点：不准和不及时，体现在噪音信号大，需要考虑单个噪点的干扰；

时序性，即不同时间的带宽估计值对预测的影响不一样，需要采用加权平均或更有效的其他方式；

探测数据与否？发送探测数据浪费带宽，不发送探测数据，难以撑满可用带宽，也即难以估计出真实可用带宽；

波动性大，导致应用层难以使用；

历史估计未来，缺乏预判性，难以应用在对延迟要求高的场景，例如互动

其它，自行脑补~

基于丢包：受启发于TCP Reno的AIMD拥塞控制机制，后续有非常多的变种和改进

优点：简单

缺点：误判和不及时，体现在噪音信号大，真实网络的丢包率和模拟器的差别太大了，难以准确估计，可采用一些滤波器，但是效果依然一般；

丢包率与带宽有时没啥关系，导致误判。即丢包很多时候并非由于网络带宽不够用，这也是为什么TCP Reno的拥塞控制，在提出至今的一二十年里，一直在被改进，以及目前的操作系统早已不用TCP Reno的原因之一(注意是之一，还有很多其他原因，利于低效等)；

历史估计未来，缺乏预判性。假定丢包是因为带宽不够用导致，等感知到丢包，说明网络已经拥塞，这将导致视频卡顿等问题；另一方面，通过感知到丢包到应用层才去策略，需要一定的时间，这段时间将进一步导致拥塞。这在对延迟要求高的场景下，效果极为差劲~

基于RTT：用RTT反应带宽，即认为RTT越大，带宽越小，反之亦然

优点：RTT较容易获取

缺点：误判和不及时，体现在噪音信号大，RTT的估计值差异较大，可采用一些卡尔曼之类的滤波器或其他策略进行平滑；

RTT与带宽有时没啥关系，导致误判。一个反例，A和B之间的网络距离较远，中间路由器处理都有时间开销，将可能导致RTT较大或波动较大，但是彼此之间的网络带宽可以非常大，即传输不是问题；

RTT的全称是Round-Trip Time，即往返延迟，而在实际场景中，例如直播推流，考虑的仅仅是上行网络，而不用管下行网络，且在实际网络中，上下行网络本身也是不对称的，所以用RTT去估计带宽，并非明智之举

基于OWD

优点：反应单向网络的特性

缺点： 不易估计噪音信号大，可采用一些卡尔曼之类的滤波器或其他策略进行平滑；

时钟不同步问题；

与RTT类似的问题，即固有延迟

基于buffer

优点：直观。buffer数据过多发不出去了，带宽不够用，降低码率，反之亦然

缺点：不适用于UDP，不适用于低延迟场景，间接估带宽不准在UDP下，基本再多数据都能发送出去(不超过网卡限制)，不存在buffer里有数据的问题，除非自行设计流控，变成鸡生蛋的问题了；

buffer看到的数据量已经是是否拥塞的结果，在预测方面自然难堪大任；

在直播这种对延迟要求较高的场景中，不宜缓存较多的数据量；

量化难以控制，过多延迟大，过小浪费带宽或导致卡顿

基于Queueing delay：网络排队延迟，个人比较喜欢

优点：真实反应数据在网络中的排队/阻塞时间

缺点：难以估计，网络环境复杂，延迟的构成更是多种多样，需要提取最准确的Queueing delay部分

时钟不同步，即每个网络节点都有自己的时钟，如何去掉时钟不同步的干扰需要考虑

波动大，每个包的排队延迟受到整个网络的影响，难以直接使用，需要有效的预处理操

其他至少两个连续数据包测试法：优点是排除时钟干扰和带宽撑不满的问题，缺点是误差较大，经常会高估

探测法

…

以上简单列举了部分带宽估计的方法，更准确的说应该是估计带宽所采用的信号，这距离带宽预测还仅仅是开头，距离流控策略和QoS保证还只是万里长征第一步。

当准确获取上述信号量之后，接来下是如何根据这些信号量来预测带宽，即从定性转化到定量，这无疑是比较困难的一步，尤其像做好，门槛还是比较高的，需要精通各种坑在哪里，以及理解各种现象的本质原因，否则稍微换个网络环境，效果就会变得很差。以丢包率为例，在一些网络环境下，例如有线网络，丢包率可以用来作为评估网络拥塞的一个信号量，就像TCP Reno一样。那么有了丢包率以后，该如何操作呢？TCP Reno采取的是AIMD来从定性转为定量，但其性能的低效和波动是个大问题。就算该策略很有效，换到wifi下，其效果就差强人意，如果不能理解丢包和带宽之间的关系、有线网络和无线网络的特性，估计就会找不着北不知道从何下手了。同理，在无线网络下，4G网络和wifi网络也有区别，而在不同的场景和需求下，这些问题的考虑又不一样，所有这些都是设计流控时需要考虑的。这些细节三言两语也说不明白，本篇就不展开，后续有时间再聊。

关于从定性到定量，一般都需要基于一些理论框架，否则将会无从下手，更谈不上设计出效果高效的流控策略了。我个人一般喜欢用控制论、马尔卡夫理论和排队论，然后结合一些滤波算法来设计流控。

控制论，主要的考虑是流控本身就是一个动态的控制系统，需要根据动态的网络不断的自我纠错和自我优化，而不能寄希望于一个简单的模型。在控制系统里，又有很多工作需要做，例如作为控制系统的输入和输出，又需要更好的设计和预处理，因为直接用延迟或丢包等信号作为输入，一般情况不是明智的选择，因为直接获取的信号量一是波动较大，二是噪音干扰导致不准，三是这些信号是结果，难以达到预测的目的，因此，需要做一些预处理。另一方面，选择何种控制系统，例如PID还是PD，需要知道各种系统的特性，以及这些特性和应用需求是否匹配。再次，如何分析系统参数，系统参数的选择，直接关系着系统是否稳定，系统响应时间，系统在动态网络下的抗干扰能力等。关于基于马尔科夫理论的策略，有兴趣的可以参考本人发表的一篇IEEE Transactions on Circuits and Systems for Video Technology期刊http://ieeexplore.ieee.org/document/6662391/ 当然，这个主要是从理论介绍如何将马尔科夫用于流控，在真实系统中，还有很多工作要做。

马尔科夫理论，主要的考虑是流控在时间上是一个状态转换过程，经过一定的转化和抽象化，可以将一个会话过程抽象成一个成马尔科夫链，然后进行优化。针对这类做法，需要考虑的问题也不少，例如网络的带宽状态如何划分、时间上的依赖关系如何考虑、如何设计转移概率矩阵、如何考虑马尔科夫链中的各个状态、如何考虑动态不可控的网络等等。关于基于马尔科夫理论的策略，有兴趣的可以参考本人发表的一篇IEEE Transactions on Multimedia期刊 http://ieeexplore.ieee.org/document/7393865/ 当然，这个主要是从理论介绍如何将马尔科夫用于流控，与上述一样，在真实系统中，还有很多工作要做。

排队论，主要用于Queueing delay，因为Queueing delay本身就是排队延迟。排队论比较复杂，也有很多模型，这里不做展开介绍。

启发式的做法：例如类似TCP Reno一样的步进法、贪心法等

本文简单介绍了流控与QoS中的带宽预测，而关于QoS，这才仅仅是个开头。流控的终极目标是提高QoS，但影响QoS的因素太多了，远不止带宽，一般需要考虑应用层的应用场景、编码器的特性、网络类型和特性、客户端特性等等，采用信源信道联合优化，具体介绍将在后续讨论中]展开，感兴趣的可以先参考本文的一篇IEEE Transactions on Circuits and Systems for Video Technology期刊http://ieeexplore.ieee.org/document/6935097/ 。此外，除了推流发送外，还需要考虑客户端的自适应拉流，毕竟用户最直接的体验是来源于自身的观看视频的体验，因此，自适应拉流(质量自适应、CDN自适应等)必不可少。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！