Home 技术文章 如何使用RTT指标来提高流媒体性能
Applications

如何使用RTT指标来提高流媒体性能

About The Author

Outline

视频流的质量取决于数百万件事情的进展情况,例如管理不断波动的工作负载或处理大量观众同时进入流媒体时的”突发人群”。 这就是为什么作为付费服务的一部分提供可靠,高质量的视频流(观众期望获得类似于电视的体验)需要工具和指标来详细阐述性能挑战,以便您知道在哪里以及如何解决问题。

CDN是视频流中不可或缺的解决方案,因为它们可根据全球需求提供低延迟可扩展性。 除了可增强方式的优化之外,CDN还平衡了可能伴随直播流而来的混乱观众增长,为最终用户提供卓越性能需要额外的可见性,指标,工具和自动化层。

在这篇文章中,我们将回顾最近针对北美大型vMVPD流媒体服务进行的性能优化示例,包括:

  • 我们用于改进/修复性能问题的指标
  • 如何定义性能以及如何衡量性能
  • 我们持续进行优化以提高视频性能

自治系统编号:背后的复杂性

现代网络围绕着被称为ASN(自治系统编号)的多个互连网络层构建,每个层都包含一大组IP地址和CDN (内容交付网络),后者通过在边缘提供内容来减少拥塞。 从本质上讲,如下所示,Internet由一个网络组成,每个网络都有其独特的业务模式和优先级。

资料来源:Research Gate

伴随着ASN相互作用的内在复杂性,它们的范围和规模是绝对的。 vizas工具试图在每个国家的基础上可视化许多ASN之间的相互联系。 例如,仅在美国,网络中就有16,979个ASN和24,905个对等关系。 全球有90,000多个ASN。

https://stats.apnic.net/vizas/index.html

从我们作为CDN提供商的角度来看,连接到数千个ASN所涉及的复杂性因满足每个客户的性能要求,使用情况,流量类型以及许多其他因素的需要而变得更加复杂。 例如,Twitter这样的服务与推出重大更新的游戏公司相比,其使用情况或占用空间大不相同。 同样,直播体育赛事的广播公司与点播流媒体服务具有不同的配置文件。 即使是两个直播流媒体服务也可能具有不同的配置文件,每个服务都需要量身定制的性能优化。

在后台,我们有大量的配置设置,可以进行调整和调整,以帮助客户实现其性能目标和要求。 对于某些人来说,性能可能是他们一开始所期望的(或更好),我们不需要任何改变。 其他目标可能有特定的目标,例如更快的TTFB (第一字节时间),这是流媒体服务的一个重要指标,需要解决。

鉴于互联网的复杂性和规模,不可能通过”黑客攻击”或”散播”方法提供有用且一致的性能改进。 通过全面的数据收集和密集的数据分析来确定问题的根本原因或主动深入了解网络配置更改,从而使客户受益最大,从而获得真正的收益。

借助Stargazer提供RTT见解

RTT (往返时间)是确定网络延迟和总体性能运行状况的最重要指标之一。 这被定义为持续时间(以毫秒为单位),它需要一个数据包从源传输到目标,并需要一个响应返回源。 它可用于诊断和改善多个向量的网络性能,包括拥塞,硬件问题,配置错误和路由问题。

鉴于这一指标的重要性,我们建立了一个名为Stargazer的内部系统,用于汇总来自各种来源的RTT数据,包括我们的传感器,我们从客户导入的数据以及也监控RTT信息的第三方。 施塔尔加泽监视发送到客户端的出站响应时间。 其他数据源包括路由器的BGP (边界网关协议)表,路由器到地理位置的映射,客户端连接的RTT日志以及流量信息。 此外,系统还可以在必要时执行主动探测,如跟踪器和ping。

在监控活动的背后,Stargazer与我们开发的其他工具相结合,使我们能够查询我们收集到的所有数据,并执行深入分析,从而开启持续改进的大门。 我们的网络管理员可以使用此信息来隔离问题并确定网络路由或配置,以便针对特定的客户目标和要求优化性能。 此外,正如后面将讨论的,它还有助于了解新技术(如BBR (瓶颈带宽和往返传播时间)协议)对性能的影响。

优化源服务器

为了更深入地了解性能优化在实践中的工作方式,我们来看一个涉及最近添加的直播视频流客户的示例,该客户需要针对多CDN架构进行优化 。 在传统的CDN客户端架构中,客户端向我们的一个POP发出请求,然后Pop缓存从源站填充,如下所示。

但是,该客户选择利用多CDN架构来增加冗余和弹性,并可能提高性能。 图4中所示的Origin Shield体系结构启用了此功能。 Origin Shield提供了对如何路由各种客户端流量的更多控制,以获得最佳性能。

与传统的CDN关系不同,所有流量(包括由第二个CDN提供的流量)都流回我们位于亚特兰大的其中一个Pop (AGA)以进行缓存填充。 AGA Pop随后用作源服务器,或者更具体地说是源服务器屏蔽,减轻了客户源服务器的巨大负担。 AGA Pop被选为源站屏蔽位置,因为它的缓存命中率和性能高于第二个CDN。 然而,一个主要问题是优化两个CDN之间的性能。

该过程的第一步是研究如何优化第二个CDN进入AGA的路由,并将其用作源站防护。 一个显而易见的问题是CDN之间的性能较差以及影响TTFB的大量连接超时。 为了深入了解性能问题,我们使用Stargazer将traceroute从AGA发送到目标目的地,并捕获每个跃点使用的ASN。

如以下摘要所示,从AGA向第二个CDN的IP地址发送了traceroute,模拟客户端的路径。

我们注意到ASN 7018中有几个跃点,这不是首选路由,因为它涉及更多跃点,并且拥塞更多。 使用星加泽,我们可以快速确认问题并进行适当的网络更改。 如下面的traceroute摘要所示,在进行网络更改后,我们通过切换到ASN 7922来减少跳数并改进RTT,这也解决了TTFB超时问题。

在另一个示例中,我们使用Stargazer工具确定到客户位于东海岸的源服务器的最佳源站屏蔽路径。 为了有效减少客户源站的负载并提高交付性能,源站防护罩弹出应靠近源站。 有时,它并不一定是最接近的物理流行最有效. 这是最少的ASN,最少的拥塞量和低RTT时间的组合。 如下图前后所示,Stargazer跟踪路由显示,从Nya (纽约) Pop迁移到DCC (华盛顿特区) Pop会将跳数减少到三个,从而全面提高RTT性能。

使用Sweeper Fish进行更深入的分析

我们的CDN在全球范围内拥有7,000多个互连和300多个POP,因此有大量的持续优化工作。 为了避免我们在可能没有太大影响的任务上纠缠不清,我们需要一种有效的方法来确定我们的运营团队所采取的行动的优先级。 这一需求导致Stargazer开发了一个名为Sweeper Fish的配套工具,它为存在问题的地方打分,并使我们能够以优先的方式将问题泡起来。

Sweeper Fish还可用于确定路线是否拥挤以及是否可能导致问题。 回到多CDN示例,我们使用Sweeper Fish发现哪些路由存在拥塞。 为此,Sweeper Fish测量了通往AGA Pop的所有路径上所有客户端RUM (真实用户测量)数据的第25和第75百分位数之间的增量,重点关注通往我们的第二个CDN路径ASN7922 通过此ASN的所有流量的标准偏差如下所示。

我们还确认以前通过ASN7018进行的配置不是理想的选择。 Sweeper Fish分析表明,由于这条路由的拥塞,IQR (四分位距)飙升到20 -60到毫秒(见图9)。 IQR (也称为中点差或中点50%)为快速分析路线和标记问题提供了一种有用的方法。 IQR越低越好。

相比之下,AGA Pop在我们最终使用的路径ASN7922上一直在10 -22毫秒之间,如下所示。 通过比较不同的ASN,Sweeper Fish使我们能够选择最佳,最不拥挤的路线和/或识别问题进行补救。

TCP调整

拥塞还会导致数据包被丢弃并重新传输。 当PoP之间的路径是遥远的并且TCP算法未优化时,就会发生这种情况。 由于AGA是我们的例子,因此到达AGA的远距离持久性有机污染物有可能出现这一问题。 尽管分布在多个PoP中,但下面的聚合CDN日志使我们能够识别由方框指示的问题区域。

图11 聚合服务器日志可快速识别数据包被丢弃和重新传输的问题区域。

评估BBR

瓶颈带宽和往返传播时间(BBR)是谷歌开发的一种替代TCP拥塞控制算法,已经开始获得一定的牵引力。 它不同于基于丢失的拥塞控制算法,如无处不在的TCP立方算法,并引入了不同的操作模式。 它会根据会话到目前为止所见的最小RTT不断更新可以传输的数据量,以避免缓冲区膨胀。

我们的分析发现,BBR对于提高RTT性能非常有用,但未达到通用解决方案。 有一些时候你想使用它,而其他时候你不使用。 Stargazer通过跟踪各个时间段内目的地RTT的一致配置文件,帮助我们确定何时需要使用它。 这使我们能够确定应用BBR的最佳位置,以帮助减少重新传输并改善流量控制。

根据下表所示的分析,我们得出结论认为,转换到BBR将略微提高AGA Pop到第二个CDN和客户来源的性能。 第一组图表显示从TCP立方转换到TCP BBR会导致重新传输减少,而第二组图表显示,从TCP立方转换到TCP BBR会使平均吞吐量略有增加。

图12 在此示例中,从TCP立方改为TCP BBR会导致重新传输减少

图13 在此示例中,从AGA Pop的TCP-Cubic切换到BBR以进行流量控制,减少了重新传输,并略微提高了平均吞吐量。

结论

互联网是庞大而复杂的–它本质上是一个网络网络。 对于Edgecast (现在是Edgio)来说,如果没有深入分析来深入了解问题区域并测试可能的配置更改,则几乎不可能优化客户使用案例的性能。 为了提高客户的绩效,我们开发了一套强大的工具来持续监控RTTs,以便我们可以快速,高效地在整个网络中进行改进。 对于直播视频流服务,我们找到了针对其独特要求优化性能的方法,同时还评估了BBR在其应用中的使用情况。 结果是一个 利用两个CDN的高性能流媒体解决方案 。 我们还没有完成。 随着网络拥塞不断增加,我们将不断优化我们的网络,以确保我们的客户及其客户获得最佳的在线体验。