1. 首页
  2. 常规
  3. 服务品质 – 带宽和延迟测试的局限性

服务品质 – 带宽和延迟测试的局限性

用户在连接到 rixCloud 网络后,可能会选择进行各类速度和延迟测试以便选择符合自身需求的接入点。但是,这些测试都存在局限性,因而无法准确地反应出接入点的状态。本文将介绍常见测试方法的局限性以及相对可靠的测试方案。

共通

共享资源

所有 rixCloud 非 Express Link 服务性能保障型服务均为「共享资源池」的服务,这意味着你是与所有具有相同资源的订户共享这些资源。虽然 rixCloud 会采取合理努力来确保所有用户都能具有较佳的体验,但我们并不可能 100% 地做到这一点。

本地网络

rixCloud 的接入网络根据订阅等级不同而有所区分,更高级订阅的中国大陆接入网络具有更多的运营商接入,这意味接入网络可能更加贴近你使用的运营商网络。但是,仍然存在各种二、三级运营商不包含在内。此外,运营商城域网接入、汇聚、核心层与跨区域网络之间可能存在 QoS 和拥塞,这导致用户不一定能以宽带声称的最大速率访问 rixCloud 接入网络。

边缘网络

用户访问的目标内容可能接入了不同的 ISP,而 rixCloud 边缘网络(Edge Network)与其使用的 ISP 可能没有互联或没有足够带宽的互联,这导致网络必须绕行其他 ISP,这可能导致带宽下降和延迟上升,虽然 rixCloud 的边缘网络已经尽可能多地接入 Tier 1 ISP 和本地交换中心,但我们并不能保证目标网络的行为。

此外,为了满足用户多样化的需求,中继出口的部分网络并不属于 rixCloud 边缘网络内,例如直接由当地运营商提供的 IP 地址和网络,这可能仅在访问运营商网内资源时有足够优质的体验。

最后,所有边缘网络都不提供跨境访问的体验保证。例如使用香港的边缘网络访问美国的资源,会有更高可能出现较低的连接速率和较高的延迟表现。我们建议用户选择当地的边缘网络来访问这些资源。

跨境专线(IEPL)

所有 rixCloud 接入点(大陆 CN2 接入点除外)都使用跨境专线进行数据传输。这可以确保稳定性和可靠性。此外,Mithril 订阅和 Mithril Pass 订阅还使用全球多路径跨境专线,使其可以拥有更低的传输延迟。


带宽测试

用户可能会运行带宽测试来测试接入点的速率表现,但是不存在完美的测试方案,所有的测试方案仍然存在局限性,需要结合多种因素来进行判断。

Speedtest.net

Speedtest.net 是全球最流行的带宽测试方案。然而,Speedtest.net 的几乎所有测速服务器均是由 ISP / 主机服务提供商和其他组织捐赠的,这些组织可能出于成本原因限制测试服务器的带宽使用量,因而测试时可能无法达到最佳效果。

此外,测速服务器供全世界所有人使用,如果测试服务器已经被运行了较多的测试,则可能无法达到最大速率。

此外,相当数量的测试服务器仅适用于该运营商网内的用户,其他用户测试就会受限于不同运营商之间的互联带宽大小,而无法达到最佳效果。

Fast.com

Fast.com 是由 Netflix 运营和维护的带宽测试网站,其测试服务器均为 Netflix OCA,即用于串流 Netflix 剧集的服务器。使用该服务测试可以真实地反应出你在观看 Netflix 时可以获得的带宽表现。

然而,Netflix 的 OCA 服务器仅适用于运营商网内,如果一个运营商网内没有 OCA 缓存服务器,也没有与 Netflix 进行任何公共对等互联或私有对等,则该运营商访问 Netflix 资源就必须绕行美国或其他可以与 Netflix 对等互联的 PoPs,这将可能导致极差的测试结果,但并不代表访问 Netflix 以外资源的效果。

Cloudflare Speed

Cloudflare 于 2020 年 5 月 26 日发布了他们自己的性能测试工具。该工具可以测试到 Cloudflare 边缘网络的带宽和延迟表现。

由于 Cloudflare 在全球有超过 200 个数据中心,因此在大部分国家或地区,使用 Cloudflare Speed 都能较为真实地反应网络的带宽和延迟表现。

然而,这也存在着相当的局限性。如果服务器所在的城市没有 Cloudflare 数据中心,则必须绕行到其他数据中心,这甚至可能需要跨国访问,将会导致较差的带宽和延迟表现。

此外,如果 Cloudflare 数据中心受到攻击或进行维护(这是常有的情况),则 Cloudflare 会将原本访问该数据中心的流量重新路由到其他数据中心,这就将导致上面提到的问题。

最后,Cloudflare 的带宽测试采用小文件进行测试,这意味着可以较为真实地反应你访问网页时的表现,但你进行大文件下载时的带宽表现一般会优于 Cloudflare Speed 显示的带宽值。同时,Cloudflare Speed 的带宽测试结果采用 90% 分位,这意味着 Cloudflare 会将多次测试的结果去掉 10% 的最高值,这个值反应的是较为平均的带宽测试结果。


延迟测试

上文提到的带宽测试工具都可以显示延迟,但实践中一般认为 Fast.com 显示的延迟误差和波动较大,Speedtest.net 和 Cloudflare Speed 的延迟测试结果相对更加准确。

然而,用户接触最多的延迟测试工具一般是各类客户端的「速度测试」或「存活性测试」功能,例如 Surge / Clash 均提供这一功能。

但是,这些客户端测试的延迟结果包含这些数值:

  • DNS 解析(如果接入点地址为域名)
  • TCP 握手(1.5 个 RTT)
  • TLS 握手(如果测试目标为 HTTPS,则为 2 个 RTT)
  • HTTP 握手(1 个 RTT)
  • 传输和接受数据(1 个 RTT)

这意味着,即使不考虑 DNS 解析所需的时间,且测试目标地址为 HTTP 地址,也需要消耗 3.5 个 RTT,也就等于 3.5 倍与你到服务器的延迟,而一般 DNS 解析需要消耗 5 – 3000ms 不等的时间(视本地和上游 DNS 是否存在缓存而定)。

因此,客户端测试的延迟应当仅供参考,在本地网络不佳(例如使用蜂窝网络)时会因为 TCP 重传而消耗更多的 RTT。

如果一定要使用客户端进行测试,则至少应当:

  • 配置 DNS over HTTPS 进行接入点地址解析,避免常规 DNS 因为短时间查询太多域名而失败(Surge 更容易发生此问题)。
  • 多次测试,有助于减少 DNS 解析和 TCP 握手消耗的 RTT。

但是,我们始终不建议用户使用客户端进行延迟测试,特别是选用 Auto 策略组(即按延迟进行切换的策略组类型)。一方面是截至本文发稿时,Clash 的 Auto 策略组仍然没有提供切换阈值的功能,这意味着即使波动了 1ms 延迟,也会发生策略组切换,频繁切换代理将对你的正常访问产生极为严重的负面影响。另一方面,过于频繁的全接入点测试,将可能触发 rixCloud 的反滥用机制而导致订阅被限制。


扩展阅读

TCP 握手

图:Cloudflare: SYN Flood Attack

TLS 握手

图:Cloudflare: What Is Transport Layer Security (TLS)?

在目标服务器使用 TLS 的情况下,且不考虑应用程序响应和处理数据所需的时间时,建立 TLS 连接需要消耗 3 个 RTT 的时间。这意味着,如果你到 rixCloud 的 HK Edge Network 延迟为 30ms,则建立 TLS 握手就需要 120ms。而一般完整的 HTTPS 握手完成则需要至少 4 个 RTT。

更快的 HTTPS 连接

图:Cloudflare: Even faster connection establishment with QUIC 0-RTT resumption

在使用 TLSv1.3 协议的情况下,完成整个 HTTP 连接需要的 RTT 次数被降低到 2.5 RTT。

更新 六月 21, 2020

相关文章

发表评论