自己动手测量
本网站上的每个延迟数据都来自我们自己的探针，而这正是你不应轻信的那类说法。looking glass 运行在全部 34 个站点，无需账户，只回答一个关键问题：你和那个城市之间的路径现在到底是什么样子。
生成命令
选择站点和工具。这些命令从你的机器运行，针对我们发布的测试主机，这是唯一能反映你自己网络路径的测量方式。
mtr -rwzbc 100 lg-ams-01.paragonvps.com一个 1 GB 的不可压缩随机数据文件，用于测量吞吐量而非压缩率。
在得出结论前，请在不同时段各运行三次。在别人维护窗口期间的一次 traceroute 不能作为证据。
它是什么，不是什么
每个站点一台探针主机，与生产环境在同一 VLAN，位于同一过滤机制之后。
Looking glass 是每个站点的一台小型主机，它代表你运行测试并打印原始输出。它与客户实例位于同一网络，处于同一边缘过滤之后，因此它测量的结果就是你实际会得到的结果。没有优化的测试路径，没有独立上行，没有机架中安静的角落。
它不是基准测试，也不是营销工具。有些结果并不令人满意：悉尼到任何地方在毫秒级上代价高昂，约翰内斯堡的传输仍在稳定中。这些数字之所以存在，是因为当任何人都可以运行测试时，隐藏它们毫无意义。
全部 34 个站点，全天候
包括预购站点。约翰内斯堡在拥有第一个付费实例之前，就已经在应答探针了。
无需账户，无需注册
与服务的其他部分一致。唯一需要你提供东西的测试是 iperf3，而它需要令牌仅仅是为了防止该主机被用作流量放大源。
刻意限速
每个源地址每次一个测试，每分钟四个测试。如果操作者没有考虑过，looking glass 就是一个很好的放大向量。
结果归你
输出为纯文本，带有链接，有效期三十天。粘贴到工单中，或粘贴到与其他人网络团队的争论中。
你可以运行什么
五种测试，选择它们是因为它们回答不同的问题。全部运行一遍并不能证明什么；选择正确的一个通常在一分钟内就能解决问题。
从 MTR 开始，而不是 ping
一次 ping 只能反映某一时刻的情况。三百个 MTR 周期才能告诉你路径是持续糟糕、偶尔糟糕，还是本身没问题而你只是运气不好。
先用测试文件测量吞吐量
通过 HTTPS 下载 1 GB 文件可以模拟大多数真实工作负载。如果速度很慢而 iperf3 很快，问题出在拥塞控制或中间盒上，而不是带宽不够。
路径 MTU 值得花九十秒检查
相当一部分“网站能打开但大文件上传卡住”的工单最终都归结于此，通常是你与我们之间某个被遗忘的隧道导致的。
| 测试 | 它回答的问题 | 限制 |
|---|---|---|
| ICMP ping | 是否可达，当前往返时间是多少 | 每次运行最多 100 个数据包 |
| Traceroute（ICMP 和 UDP） | 离开该站点后，正向路径经过哪些跳点 | 最多 30 跳，每跳 3 个探测 |
| MTR | 随时间推移的每跳丢包和延迟，而不是单次快照 | 最多 500 个周期，约 8 分钟 |
| iperf3 目标 | 到该站点实际能获得的吞吐量 | 面板令牌，60 秒，最多 4 个流 |
| 测试文件 | 无需安装任何东西的吞吐量答案 | 通过 HTTPS 提供 100 MB 和 1 GB 文件 |
| 路径 MTU 探测 | 中间是否有设备丢弃了大的数据包 | 报告存活下来的最大大小 |
如何正确解读输出而不误读
Traceroute 输出并不是你的流量路径的完整图像。它只是一组来自路由器的响应，而这些路由器都有自己的事情要处理，把它当作延迟图来解读往往会得出自信但错误的结论。
我们收到的大多数路由投诉，症状描述准确，但对跳点的判断是错误的。
中间跳点会夸大延迟
路由器响应 traceroute 探测是在其控制平面进行的，控制平面很忙，而且 ICMP 是它优先级最低的任务。当某一跳显示 180 毫秒而下一跳显示 14 毫秒时，是那个路由器本身正忙，而不是它前面的路径有问题。
只有最后一跳是真实的
丢包出现在第六跳但第七跳消失，通常是速率限制导致的响应丢失，而不是真正的流量丢失。如果从第六跳开始持续丢包直到最后一跳，请把输出发送给我们。
反向 DNS 只是线索
跳点名称中的机场代码经常过时好几年。把它们看作是命名者对地理位置的意图，而不是实际的证据。
MPLS 会隐藏中间跳点
穿过标签交换核心的路径看起来会少三跳。延迟依然存在，只是缺少了关于延迟来源的准确信息。
物理距离决定了最低延迟
阿姆斯特丹到新加坡大约 168 毫秒，任何 peering 都无法显著提升。如果你的测量值接近我们公布的数字，说明路径工作正常，你需要的是第二个站点，而不是提交工单。
非对称路由——问题所在
Traceroute 只测量正向路径，不涉及反向路径。但它的每一个数字都包含了那个跳点响应返回的行程，而返回行程可能穿越完全不同的路径。
从我们到你的流量和从你到我们的流量是由不同网络作出的独立决定。我们选择发送路径，中间网络选择返回路径。多数运营商选择尽早交接流量，因此你的返回路径经常从我们的路径进入你提供商的不同城市开始。
可见的影响是某个跳点看起来慢，但你的实际流量没问题。更糟糕的是不可见的影响：返回路径的拥塞表现为延迟，你会花一下午在正向路径上查找原因。
始终测量两个方向
从你的机器到实例运行 MTR，同时从该站点的 looking glass 返回你的地址运行 MTR，最好同时进行。只有一半的证据，只能得到一半的答案。
非对称本身不是故障
互联网上几乎所有路径都是非对称的，而且绝大多数都工作正常。只有当某一方向拥塞、丢包或经过有状态的过滤设备时才会成为问题。
我们只能影响返回流量
我们的路由策略直接控制出站方向。返回路径只有在不同宣告、不同交接点或请求对等方的情况下才会改变。这三种方法都可行，但都不是立竿见影的。
有状态中间盒不喜欢非对称
如果您运行的防火墙期望看到流量的双向传输，而返回路径不再经过它，您会遇到间歇性重置，看起来完全像是网络故障。在指责任何人之前，请先检查这一点。
提交一个会得到处理的路由投诉
工单的首次响应中位时间为 11 分钟。路由修复需要更长时间，因为必须得到他人的同意。
- 01
排除您自己实例的问题
检查负载、连接跟踪、实例自身的接口计数器，以及您的过滤规则是否丢弃了流量。大约五份报告中有那么一份是您自己的问题，先检查能更快解决。
- 02
收集两个方向的数据
在相同的时间窗口内，从您这边至少运行 300 个 MTR 周期，并从该站点的 looking glass 运行同样数量的周期。附上永久链接而不是截图；我们需要数字，而不是数字的图片。
- 03
正确标记时间戳
使用 UTC 或明确标注时区偏移。'今天早上'对您来说是一个时刻，对我们来说却是一个长达十一小时的区间，针对它关联流量数据完全是猜测。
- 04
说明发生了什么变化以及时间
是一直如此，还是从周二开始。是持续性问题，还是仅在当地时间的 20:00 到 23:00 之间。这句话通常就能决定我们是在排查对等互连问题，还是别人晚上的拥塞问题。
我们能做的事情：调整路由、降低特定转接的优先级、要求对等方展开调查，或把您迁移到具有更好路由的站点。对于我们不触及的网络内部拥塞，上述四种方式均无效，我们将为您绕行该问题，而不会花费一周时间去证明自己是对的。
Looking glass 常见问题
可以，但每次只能持续六十秒。令牌的存在是为了防止主机被用作洪水攻击源，而不是限制诚实的测量。持续测试需要您在两端的实例。
不应该不同。如果确实不同，我们很希望了解情况。探测主机位于同一 VLAN，且继承相同的策略。真正的差异通常意味着应用于您地址的每前缀策略，这值得开一个工单。
不会在公开的 looking glass 上发布。如果有具体的地址前缀和合理理由，请开一个工单索取，我们将给您答复，包括我们正在优先选择哪个上游以及原因。
在速率限制范围内可以；这些测试是出站方向且在该流量级别上无碍。使用探针作为您不控制目标的测量源是可行的。但作为任何更大规模操作的一部分，则不行。
三十天，之后会与存储的输出一起过期。在链接仍可解析时附在工单中，或者直接粘贴文本，我们其实也偏好文本。