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

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

About The Author

Outline

视频流的质量取决于数百万件事情的顺利进行,例如管理不断波动的工作量或在大量观众同时进入流时处理”突发的人群”。 这就是作为付费服务的一部分提供可靠,高质量的视频流的原因,观众希望获得类似于电视的体验,因此需要使用工具和指标来精确阐述性能挑战,以便您知道在哪里以及如何解决问题。

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

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

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

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

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

资料来源:研究大门

与ASN相互交互的固有复杂性相结合的是其纯粹的范围和规模。 VIZAS工具试图逐个国家/地区可视化许多ASN之间的相互联系。 例如,仅在美国,整个网络中就有16,979个ASN和24,905个对等关系。 在全球范围内,ASN超过90,000个。

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

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

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

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

通过Stargazer提供RTT见解

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

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

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

优化源服务器

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

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

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

该过程的第一步是考虑优化第二个CDN到AGA的路由,使其充当源站屏蔽。 一个直接显而易见的问题是CDN之间的性能不佳以及影响TTFB的大量连接超时。 为了深入了解性能问题,我们使用Stargazer将跟踪路由从AGA发送到预期目标,并捕获用于每个跃点的ASN。

如下所示,Traceroute从AGA发送到第二个CDN的IP地址,模拟客户端的路径。

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

在另一个示例中,我们使用Stargazer工具确定到位于东海岸的客户源服务器的最佳源站屏蔽路径。 为了有效减少客户源站的负载并提高交付性能,源站屏蔽弹出窗口应靠近源站。 有时候,它不一定是最接近的物理流行音乐,效果最好。 它结合了最少的ASN,最少的拥塞和低RTT时间。 如下图前后所示,Stargazer traceroute显示,从Nya (纽约)流行音乐移动到DCC (华盛顿特区)流行音乐将跳数减少到三个,从而使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调整

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

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

评估BBR

瓶颈带宽和往返传播时间(BBR)是Google开发的另一种TCP拥塞控制算法,该算法已开始获得一定的吸引力。 它不同于基于损耗的拥塞控制算法,如无处不在的TCP-cubic ,并引入了一种不同的操作模式。 它会根据会话迄今为止看到的最小RTT持续更新正在运行的数据量,以避免缓冲区膨胀。

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

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

图12. 在此示例中,从tcp-cubic更改为tcp bbr会导致重新传输减少

图13. 在本示例中,从TCP-cubic切换到BBR进行流量控制,用于AGA pop,减少了重传,并略微提高了平均吞吐量。

结论

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