算法系列:实时事件缩放

在体育、音乐会、节日和其他面对面的聚会中暂停后在2020年的大部分时间里，随着我们进入2021年，对大型活动有大量被压抑的需求. 提供直播活动的公司将如何满足潜在的前所未有的需求? 算法系列的最新一期深入研究了用于大规模微调实时视频事件交付的数学和工作流决策.

单播传输

许多直播解决方案专注于单播交付, 在这种情况下，视频流服务器和最终用户的流媒体播放器(网络术语中的“客户端”)之间只有一个连接。.

在HTTP流传输出现之前, 在这种方式中，流被分解成一系列的段或块，这需要为实时流增加15-30秒的延迟(或延迟), 大多数单播交付都是基于实时传输协议(RTP)和衍生产品，如Adobe的实时消息传递协议(RTMP)。. 基于rtp的实时流的好处是，它们可以以非常低的延迟(足够低)交付, 事实上, 它们仍在某些形式的网络视频传输中使用, 如WebRTC), 但缺点是可扩展性. 对于每个需要接收直播流的终端用户, 服务器必须建立一个直接的传递连接(称为“状态”)才能对其进行转发. 这就意味着昂贵的服务器和大容量带宽通常只能在主要的互联网对等点数据中心使用.

P2P (Peer-to-Peer)交付

20世纪90年代末和21世纪初的研究主要集中在单播直播之外的扩展, 通过使用HTTP传递或对等辅助传递.

点对点(P2P)使用客户端之间的连接，这些连接要么与服务器协调，要么完全独立于服务器, 但是，一旦初始内容被播撒到一组对等节点上，它需要的服务器就会少得多. 有趣的是, 独立于服务器的P2P方式并非源于流媒体, 本身, 分散的P2P BitTorrent服务器被用来协调未经授权的文件共享，这些文件共享是高级可下载的媒体内容.

随着随后对文件共享网站的打击，P2P逐渐失去了人气, 这种对等辅助交付的效率和成本效益(服务器较少，对来自中央数据中心的大量带宽吞吐量的需求有限)引起了视频中心网络架构师的注意.

然而，P2P并没有解决所有的可扩展性问题. 一个原因是，并非所有的同伴都生来平等(甚至表现得好像他们是平等的)。, 由于, 在某种程度上, 不同的网络拓扑结构. 在“将拓扑信息用于质量感知的点对点多层视频”中流媒体”，2014年这篇论文发表在《百家乐软件app最新版下载》杂志上 国际通信系统杂志, 根特大学信息技术系的一组作者研究了利用网络拓扑来处理流媒体体验质量的问题. 以下是引言的节选:

在本文中, 在P2P框架中，我们引入了一个包含网络信息的模型. 视频流提供商的一个重要指标是最终用户感知的内容质量. 这里研究的优化是为了使接收高质量视频的用户数量最大化.
本文从流提供商的角度来解决优化问题, 能够访问网络拓扑信息. 提出了一种精确的基准优化方法目的和一种启发式方法来处理现实的网络大小.

鉴于本文的重点是cdn和isp等服务提供商，因此作者假设服务提供商将“在网络中精心选择的位置安装对等节点，并[租用]足够的网络容量来连接这些对等节点”，以实现最佳的直播传输.

这种方法中的对等选择对于保持直播内容的高质量吞吐量至关重要, 但作者也建议有四种节点类型是必要的:注入器, 哪一个 offer the initial video stream to the network; tracking nodes, 哪一个 coordinate the peers as they begin the download process; peering nodes, 哪一个 both receive content and seed it to other peers as well as the destination (end-user clients); and forwarding nodes, 哪些是服务提供者网络的关键拓扑的一部分.

早期对等辅助交付的一个问题是，当一个高带宽的对等点可用时，节点的贪婪. 这种方法让一些幸运的同行能够更快地下载内容, 但这意味着其他对等体必须寻找带宽较低的对等体. 虽然对于非法文件共享优质内容来说，这似乎不是什么大事，包括院线电影和高端电影桌面应用程序, 将这种贪婪问题应用于直播意味着, 潜在的, 并不是所有的同行都能接收到同样高质量的视频流.

贪婪的问题，正如《服务器保证上限:在异构覆盖中最大化流质量的激励机制瑞典KTH皇家理工学院的研究人员撰写的一篇论文， P2P网络没有考虑到吗因此，网络拓扑结构并没有达到应有的效率. 这篇论文比根特大学的论文早写了几年，并且在提到同行数据共享时使用了“自私”而不是“贪婪”这个术语. 然而，它带来了很多更令人生畏的结论是:“我们表明，同伴的自私行为导致了一种从社会福利角度来看不是最优的均衡, 因为自私的对等体对形成集群和在它们之间交换数据感兴趣."

“社会福利”的概念期望一切对等节点将为所有其他对等节点的利益而行动——这是可能的, 至少, 当节点跨越多个网络时，这是困难的, 包括无线, 无线网络, 甚至是移动蜂窝网络——通过一种激励形式，如服务器容量，来确保在高贡献和低贡献的节点之间平等地共享数据.

该算法对于度量节点间的总效用相当简单:

SWF =(1−α)·u (pc) +α·u (pnc),

正如皇家理工学院的论文所指出的那样， pc 表示贡献者的出场概率，和 pnc 表示非贡献者的出场概率.

至于社会福利的影响, 异构网络中的自私节点影响各种P2P系统. “我们认为，性能下降是由于对等集群是否仅局限于推送系统,皇家理工学院的论文说, ，但这是不协调的p2p传播算法所固有的."

优化社会福利, 这篇论文推荐了一种服务器保证上限(SGC)，它由两种类型的数据传递组成:P2P传播(根据某种转发算法在对等点之间转发新鲜内容),(我们将在本文后面讨论)和直接交付.

这些类型直接向服务器请求，在传统的P2P对等辅助方法中，这些节点可能会错过内容, 要求服务器计算某种程度的阈值概率(Tp)，并保留整体交付能力的一部分(mt)用作预备队(mr)直接派发. 当贡献者的数量在叠加和 mr 是已知的，服务器计算SGC和播放概率的阈值为 1 - mr /(1−α) · N. 完整公式如下:

西格林换算公式

不过，这个练习的最终结果是确定哪些对等体有资格获得直接交付. 这取决于布局概率等于或小于阈值的布局概率. 用数学术语来说，就是那些有 pi ≤ Tp.

根特大学的论文考虑到了KTH皇家理工学院没有考虑的一个概念:网络拓扑. 事实上, 根特大学的研究小组指出, “据我们所知, P2P(多层)视频流网络都没有利用拓扑信息来优化网络负载.此外, “我们在本文中提出的策略通过使用实际网络的拓扑信息来编排对等选择，从而形成一个未来证明和强大的框架，在互联网上分发(实时)视频流，从而最大限度地提高每个目的地的最低接收视频质量.作者提出了一个编排引擎来解释对等体之间网络拓扑结构的变化, 但也要承认单点故障的可能性, 这是所有同伴辅助解决方案都试图避免的.

根特大学的论文指出了P2P的另一个问题:潜在的缺乏同伴.g., 如果没有“大量的终端用户……观看相同的视频源”，P2P优化就无法实现.“虽然IP多播肯定是一个理论上的选择, 作者指出，“由于互联网上的稀疏部署，IP多播不是可扩展视频流服务的可行解决方案."

传统网络拓扑结构的一个修改——转发节点——对注入器和跟踪节点的工作至关重要正确. 这与KTH皇家理工学院论文的研究结果一致, 因为转发是同侪协助递送的基础.

提高效率和健壮性, 虽然, 根特大学的论文提出了环拓扑的数学公式, 它使用一个特定的R转发节点:“通过优化目标函数R, 对等节点是否有动力将视频层传输到似乎具有最高带宽连接的目的地, 哪一个, 原则上, 和有目的地完全一样吗选择(注入器或对等端)节点从具有最高带宽连接的节点下载.然而，与其允许完全不受限制的传送，尤其是在两者之间高带宽的节点, 本文为注入器对等节点引入了一个约束，“以防止在没有约束的情况下可能发生的节点之间不必要的数据传输”.

读者可能还记得关于内容交付的算法系列文章，我将介绍一种环方法，其中内容存储和检索在顺时针环上平衡. 然而, P2P的环形拓扑类型为不太类似于CDN决策，而更类似于以太网出现之前用于早期局域网(lan)的令牌环拓扑. P2P环拓扑的好处是，环上的每个可用节点仍然可以用作传统P2P树拓扑的根(参见图1).

图1. 环形网络连接R个转发节点. 每个环节点都充当树拓扑结构的根. (经报纸允许使用)基于拓扑信息的质量感知点对点多层视频流")

HTTP直播(HLS)

这是合乎情理的苹果的HTTP直播(HLS)不需要HLS特有的算法, 因为它使用小文件(称为块或段——从HTTP服务器传递. 但最近出现的低延迟HLS产生了一种特殊的算法，罗杰·潘托斯在他的书中提到了这一点 HTTP直播第二版规范，该片于2020年4月30日上映. Pantos已经成为HLS设计和采用不可或缺的一部分, 自2009年HLS问世以来，他撰写了所有规范草案, 这在业界通常被称为“Pantos规范”."

这个最新版本将取代原来的RFC 8216, 预期的标准现在包括低延迟HLS. 作为rfc8216bis-07版本的一部分, Pantos在附录C中包含一个算法，用于通过CDN实现低延迟交付. 客户端应该支持通过cdn和其他HTTP缓存传输低延迟流,潘托斯写道。. 正确实现PART-HOLD-BACK，服务器推荐的实时播放延迟，要求客户端首先获得最新版本的媒体播放列表. 客户端可以采用多种方法来获取最新版本的媒体播放列表. [一个]算法[例如]通常需要两个播放列表请求来获得当前播放列表的一个部分目标持续时间. ..."

回到RTP

正如我在文章开头提到的, 基于rtp的流媒体是流媒体头20年的标准, 但是，在带宽和专用媒体服务器软件方面，大规模的传输成本令人望而却步，这是该行业与传统无线广播公司竞争的一个障碍. 像这样, 而cdn解决了这个问题(花费了很大的成本), 随着P2P和基于http的分段传输的出现，RTP的使用逐渐消失.

然而，RTP仍然以WebRTC的形式存在, 它使用标准的网络浏览器来传送实时音频和视频通信——有些是一对一的单播模式, 但其他人则采用非常低延迟的双向方式，允许视频会议或视频聊天. 就像经典的RTP一样, 以一对多或多对多的方式扩展WebRTC也需要大量的服务器(称为选择性转发单元), 或在WebRTC中使用sfu)来解决扩展问题.

使用基于云的服务器平台似乎是动态扩展sfu以在端点之间路由视频的理想方法. 但是“webbrtc云架构的媒体流分配和负载模式，一篇关于SFU的论文优化—根据拓扑考虑不同的优化方法—编写, “为了满足百家乐软件需要, 需要为通信云平台中的所有会话提供足够的SFU单元，无论它是基于云的还是本地SFU池.

在基于云的基础设施中，使用来自数百个流并发处理的真实数据, 作者从服务器的前提开始 load可以很容易地等同于每个SFU管理的流的数量(参见图2). 从这个点, 他们使用服务器负载对每个以前定义的云服务器类别(例如.g., 特定CPU的EC2实例, 内存, 和SSD容量)，然后从每个服务器采样以验证基准. 他们写道:“我们解决数十万流如何随着时间的推移影响通用媒体流处理应用程序的整体质量的问题, 数百个流同时被同一个SFU处理."

基于云的WebRTC基础设施

图2. 基于云的WebRTC基础设施的系统概述. (经报纸允许使用)webbrtc云架构的媒体流分配和负载模式")

使用自动回归(或运行平均)模型对真实世界的WebRTC流量, 作者使用覆盖延迟观察值的线性回归方程计算了数据中心内的服务器负载(参见图3).

数据中心总负载滞后图

图3. 数据中心1个月的总负荷滞后图(经论文许可使用)基于WebRTC云架构的媒体流分配和加载模式)

Yi+1 = 0.9974 ∗ Yi−1 + 2.8282

方程中是0.9974为参数斜率，2.8282是截距.

在回归斜率的基础上，提出了一种算法来保证每一个 SFU提供最少数量的流，这提供了更好的负载平衡(参见图4). 他们还警告说，算法倾向于找到一个最佳点，并始终坚持下去随后的流程实际上可能会适得其反. “尽管我们有能力预测一个已定义数据中心的总负载,他们写道, 百家乐软件分配算法仍然可以得到一旦会话的第一个流被分配给一个服务器，该会话的所有其他流将被分配给同一服务器的限制下的问题."

保证SFU使用最少流数的算法

图4. 提出了一种算法来保证每个SFU服务最少数量的流, 哪个提供更好的负载平衡. (经报纸允许使用)基于WebRTC云架构的媒体流分配和加载模式)

结论

在我们所涵盖的每个类别中，仍然有相当多的研究正在进行实时事件扩展:传统RTP, P2P交付, HTTP低延迟交付, 和Web-RTC. 它们都有减少网络流量的共同目标，无论是通过优化服务器(RTP和WebRTC)，还是通过将流卸载到通用服务器(HTTP)，或者通过减少总体服务器占用(P2P). 但什么对一个人有效一个地理区域的方法不一定适用于另一个地理区域. 这可能是由于多种原因, 我在本期的“思想之流”专栏中探讨了其中的一些问题(见第12页)。. 然而，所有这些研究的关键因素是如何降低整体延迟, 在过去的一年里，每一种交付方式都在这方面取得了重大进展.

在下一期, 我将深入研究2020年算法系列的最后一个主题:数字版权管理. 毕竟, 如果我们能够以比传统的无线广播更好的延迟将优质的现场活动内容传递给付费观众, 在通过OTT向全球观众“播放”这些内容时，将比以往任何时候都更需要保护这些内容.