测量结果
到 Cloudflare、Google、Netflix 与 Meta 的延迟
每个目标一个面板，各自固定在一段观测窗口上，与我们监控系统输出的完全一致。请分别看待每条曲线：各面板的窗口并不相同。
图表取自我们的 AS210699 Grafana 仪表板，显示在固定的观测窗口上：它们呈现网络的行为，并不会实时刷新。
这些曲线是固定的。若要在阅读本页的此刻，从我们的 PoP 发起 ping、MTR 或 traceroute： 在 lg.infrawire.net 打开 Looking Glass
读图
如何读懂这些曲线
读懂一张延迟图，三个概念就够了。第四点则避免你从中读出它并未表达的结论。
往返时延
每个点测量的是一次完整往返：数据包离开服务器、抵达目标、再返回。这不是单程耗时，而是整整一圈。
毫秒刻度
纵轴以毫秒标定。先看刻度再看曲线形状：两张外观相同的图，覆盖的区间可能相差很大。
稳定优先于最低值
一条低而平的曲线，胜过最低点更低却锯齿起伏的曲线。SSH 会话、在线对局或 API 调用中，让人有感的是稳定性。
回程同样计入
去程与回程未必走同一条路由。数值上升有可能来自回程路径，而那已在我们网络之外。
目标
为什么是这四个网络
它们都是公共网络，从任何运营商都可达，并且遍布在你的用户日常所做的一切之中。探测它们，能对从我们机器出发的接入质量给出清晰的画面。这里不暗示任何特殊关系：这些是测量，不是合作。
Cloudflare
挡在相当大一部分网站前面：CDN、公共 DNS 解析器、应用防护。到 Cloudflare 的往返时延，接近那些依赖它的站点的表现。
搜索、YouTube、Workspace、Play：你的用户最常在无意间触达的网络，也是通用的比较基准。
Netflix
超高吞吐的视频流媒体，对路径的平稳程度要求苛刻。到这类平台的延迟是否稳定，很能说明中转质量。
Meta
Facebook、Instagram、WhatsApp 及其 API：社交应用以及构建其上的商业集成所产生的流量。
方法
测量是怎么做的
没有任何玄妙之处：工具叫 smoke ping，它发送数据包并记录返回时间。全部价值在于持续地做，并把结果原样公布。
定期探测
从接入巴黎 AS210699 的一台机器出发，按固定间隔向每个目标的一个公共地址发送 ping（ICMP）数据包。
保留历史
每次读数都带时间戳并被保存。是历史让异常变得可见：没有过去，孤立的一个数值毫无意义。
Grafana 仪表板
数据序列绘制在我们的 Grafana 中。本页面板就是我们内部监控的面板，直接嵌入--既非截图，也未加修饰。
原样公布
我们不会为了让曲线好看而做任何修饰或裁剪：每个面板都按它在我们仪表板上的样子原样取用，包括那些不平整之处。
这项测量说明不了什么
- 它测的是从我们网络出发的路径，而不是从你的线路出发：你的延迟首先取决于你的运营商和所在位置。
- 它基于 ICMP。部分设备处理 ping 的优先级与应用流量并不相同。
- 它不说明带宽，也不说明你的应用负载：再短的路径也从未加速过一条索引糟糕的 SQL 查询。
- 它只覆盖四个目标。如果你的流量流向别处，请从你自己的机器上自行测量。
常见 问题
关于这些测量，我们被问得最多的问题。
这是一种反复进行的延迟测量：工具不是只 ping 一次，而是持续发包并绘制响应时间的历史曲线。这样看到的是路径的稳定程度，而不只是某一刻的数值。