Home Blogs 使用重传率测量中间值
Applications

About The Author

Outline

在运营大型全球网络时,确保通过公共互联网进行通信的系统之间的良好连接和性能是确保积极用户体验的关键。 鉴于Internet的复杂性和最大努力性,即使是最可靠的提供商上配置最完善的链接有时也会出现问题。

有多种策略用于监控此类链路,包括 主动测量和被动测量,前者用于生成专门用于测量的流量, 后者用于监控现有流量。 在这篇文章中,我们描述了一种被动方法,它利用 我们的xTCP 套接字采样系统被动地监控我们的网络所依赖的许多这样的链路。

为了充分利用xTCP的数据,我们进一步开发了一种处理此数据的方法,该方法解决了与Internet监控相关的一些挑战。 特别是,我们引入了一个被称为重新传输率的概念 ,它提供了在内容交付网络(CDN)站点之间观察到的重新传输的严重性的相对度量 。 我们证明,高于特定级别的重新传输率对应于吞吐量的下降,直接影响用户感知的性能,从而使其成为网络自动化的良好基础,使我们能够解决网络性能下降的问题。

背景

CDN中的一个常见工作流涉及一个入网点(PoP)接触另一个以获取某段内容,例如,将某段内容提取到缓存。 这些交互通常是直接响应客户请求的,这意味着下游请求可能正在等待此传输完成。 通常,请求本身可能很小,大约只有几KB。 响应的大小可能变化很大,从千字节到多兆字节不等。

图1:请求流发送小的(订单KBS)请求,并收到潜在的大响应(可能是兆字节)。

为了监控接入点之间连接的运行状况,我们可以使用套接字监控工具xTCP,对边缘服务器上所有打开套接字的当前状态进行采样。 虽然这为我们面向客户端的套接字提供了关键可见性,但此套接字数据也为我们提供了POP之间数据的视图。

然而,衡量这一数据并非没有几个挑战。 首先,xTCP提供不同连接的时间点示例。 这意味着我们可能会在许多不同的传输点捕获许多连接。 因此,我们所做的任何评估都必须考虑更广泛的行为分布,而不是任何单一的价值观。

接下来,我们需要确保我们正在监控正确的方向。 虽然生成请求的POP (上图中的POP A)和接收请求并必须响应请求的POP (上图中的POP B)都有套接字信息,但它们的非对称工作负载意味着我们期望看到不同的行为: 客户端发送的大多数数据包将是控制数据包(初始请求,后续确认数据包),而服务器发送的大多数数据包将是数据包,这些数据包更可能包含有意义的数据量。

因此,如果路径上存在拥塞或其他问题,则承载数据的数据包(因此占用更多队列空间)更有可能遇到数据包丢失和重传问题,例如,由于繁忙路由器上的队列丢失。 为了证明这一点,我们考虑了在10分钟的时间内,在一对POP之间的请求和响应流中发现的数据包重新传输速率的分布(计算方法是:重新传输的数据包总数除以已发送数据段的总数,再减去重新传输)。

图2:响应流量遇到更多的重新传输,这可能是由于它们的大小较大。

在这里,我们看到客户端请求套接字在这段时间内几乎没有重新传输。 另一方面,响应显示近85%的套接字具有非零重新传输,但是我们注意到,对于绝大多数连接,重新传输速率远低于1%。 在测试期间,我们观察到几乎每对弹出的非零重传行为都是相似的。 因此,我们侧重于数据密集型的响应流程。 由于我们关注的是为原始请求弹出窗口提供请求服务,因此我们将这些请求称为”入站”流。

我们的最后一个挑战来自与重新传输有关的一些一般性复杂性,以及使用它们作为性能下降信号的难度。 实际上,重新传输可能会定期发生,而不会指示特定问题,因为它们只是反映发送方状态和重新发送数据包的次数。 这些最终可能是除了丢失之外的其他复杂协议行为的结果(例如 尾部丢失探测)。 我们观察到许多套接字从未观察到重新传输,这增加了复杂性。 这意味着naïve的总结(例如,取中位数)可能会导致重新传输率的非常保守的总结,而偏斜的总结(例如第95或第99百分位数)可能在很大程度上捕捉到对一般人群无害的行为。

重新传输速率

为了帮助简化这些挑战的影响,我们考虑了一个复合度量,我们称之为重传率。 受Meta’s HD Ratio的启发 ,该测量旨在量化能够流式传输高清视频的客户端的比例,该测量旨在描述正在经历不健康的重新传输水平的插槽的比例。 由于有时需要非零重传,因此我们将重传率定义如下:

重要的是,使用通过xTCP提供的数据计算此值特别容易。 根据我们的操作经验,我们发现在正常链路上,重新传输率的值通常很小,同时避免了原始重新传输速率测量中几乎始终为零的挑战。

我们还发现该测量值非常敏感,通常会在其他绩效监控系统之前生成警报。 这使得它在快速诊断网络性能下降时尤为重要,因为网络性能下降通常从小问题开始,最终会导致更大的问题。

验证指标

为了证明重新传输率与应用性能直接相关,我们通过考虑两个测量值来证明其有效性。 首先,我们显示在重传率高的情况下,客户端应用程序(请求者)的吞吐量低于重传率低或为零的情况。 其次,我们发现,高重传率通常与其它网络信号的降级相对应,特别是POP之间的ICMP探测器。

为了探索对应用程序性能的影响,我们转向从应用程序层明确获取的测量结果。 我们特别考虑在客户端POP测量的吞吐量,因为这些吞吐量代表数据发送过程中实现的功能交付率。 为了了解重新传输事件的影响,我们在一周的时间内对一对弹出进行了以下研究,在此期间发生了一个重要的提供商问题。

首先,我们考虑发生重新传输事件的所有期间 。 我们将重新传输事件定义为一对POP之间的重新传输比率在特定范围内至少连续10分钟的任何时间段。 虽然我们注意到这不包括短命事件,但它提供了对长命事件行为的洞察。 对于每个重新传输事件,我们会在事件期间收集相应的吞吐量值。 作为一种控制,我们收集数据的持续时间与事件相同,但三小时前。 这为我们提供了两组吞吐量测量:”在”重新传输事件和”正常”(在未重新传输时)。 然后,我们将”During”(期间)测量值标准化为正常时间内PoP之间达到的中位吞吐量。 对于我们的阈值,我们考虑四个范围:大于0但小于25%,大于25但小于50%,大于50但小于75%,最后大于75%。

图3:与非重新传输周期相比的相对吞吐量,在每次重新传输事件期间观察到。

上图显示了测量期间观察到的相对流量分布。 首先,我们发现,即使在最低范围内,60%的交易的吞吐量也低于中位数。 当我们考虑较高的再传输率时,吞吐量继续下降,较高的再传输率与较低的吞吐量相对应,最坏的情况导致相对中位数下降超过一个数量级。 这些测量表明,重新传输率成功捕获了受影响流量的不良性能。

接下来,我们将讨论这些事件与PoP之间的活动ICMP测量结果之间的关联。 在这里,我们考虑一些主动监控的行为,它在PoP之间执行常规ICMP探测,以测量延迟模式的任何损失或变化。 在此分析中,我们再次使用从吞吐量比较中提取的事件。 但是,这次我们查看每个阈值时间段的ICMP测量损失,在这种情况下,正常情况下未观察到损失。 我们注意到,ICMP探测的局限性导致这些特定测量的损失粒度为2%。

图4:每个时间段内观察到的ICMP丢失。 更大的重传率与更大的损耗相对应。

在这里,我们看到较低的阈值很少显示任何损失,90%的测量值未检测到任何损失。 相比之下,在0.75阈值时,80%的测量值观察到损失,并观察到相对较高的中位损失4%。 重要的是,我们注意到重新传输率与显著吞吐量影响(例如0.25)相对应的水平,导致ICMP度量的损失很少。 这些研究结果重申了测量路径性能的重要性,不仅限于简单的ICMP探测器,还强调了重新传输率能够提供互联网上实际流量性能的细致入微视图。

Conclusions and beyout

在这篇文章中,我们演示了重新传输率的值,这是一个方便的汇总度量,也可以使用xTCP套接字数据轻松计算。 我们进一步表明,它提供了对应用程序性能受到影响且必须进行网络干预的案例的清晰见解。

重新传输率已成为我们监控流程的一个关键部分,可提供对系统性能的清晰见解,无需处理更大,更笨重的应用程序日志,也无需依赖无法捕获某些影响的ICMP探测器。

我们正在进行的工作是探讨如何使该指标尽可能敏感,以便对降级情况提供早期预警,同时为更复杂的自动化系统提供适当的输入。

特别感谢架构和网络可靠性工程团队对此工作的支持!

对于有兴趣了解更多关于Edgio实验室和高级项目的研究人员,或有兴趣探索上述任何主题的协作工作,请联系团队: research@edg.io