巴黎 → 法兰克福 · ~12 ms
没有人会说这条线路慢。
实测
十二座城市，按距离排序
按顺序排列而非按地区分组：读到自己所在城市之后即可停止阅读。
- 布加勒斯特 12ms
- 基辅 21ms
- 华沙 29ms
- 维也纳 33ms
- 法兰克福 35ms
- 伊斯坦布尔 38ms
- 阿姆斯特丹 42ms
- Milan 45ms
- 伦敦 48ms
- 斯德哥尔摩 52ms
- 迪拜 92ms
- 纽约 118ms
高亮单元格的数值低于 50 ms——在这一范围内，SSH、远程桌面和交互式操作都会有本地般的流畅体验。此列表中的每一座欧洲城市都落在这一范围内，唯有斯德哥尔摩以 2 ms 之差未能达标。
作为参照
35 毫秒不是妥协
数字只有在与您已知的数字相比时才有意义。以下是三条没有人认为慢的线路，以及我们的线路在其中的位置。
基希讷乌 → 法兰克福 · ~35 ms
我们的方案。是这个数字的三倍，仍低于人眼能察觉的门槛。
伦敦 → 纽约 · ~75 ms
伦敦金融城内的每家交易台都在使用，从无怨言。
法兰克福 → 新加坡 · ~160 ms
交互式工作真正开始变得吃力的地方。
测量方法
缺少测量方法的延迟数字，只是一个形容词
任何人都能发布一个好看的数字，真正值得阅读的是了解它是如何得出的，并且您自己也能得出同样的结果。
ICMP 探测来自我们自己的边缘节点，而非探测网络。
测量数据来自承载您流量的同一批路由器。第三方探测网络所在的数据中心，对等连接往往优于它们所声称代表的客户。
30 天中位数，而非最佳单次成绩。
凌晨三点的一个数据包说明不了什么。该数值取自持续采样的中位数，因此某个安静的夜晚也无法让它显得更好看。
精确到城市，而非最近的互联点。
测试目标是每个城市中知名的主机，而不是离我们最近的交换中心的边缘路由器。
而且您可以重复这一过程。
每个目标地址都是公开的，looking glass 工具在我们这一端运行相同的命令。如果您得到的数字与我们不一致，我们希望知道。
我的用户在美洲，这样可行吗？
对于前端有 CDN 的网站而言，完全没有影响——一旦资源被缓存在边缘节点，源站延迟就不再重要。但对于面向纽约地区玩家或交易员的交互式服务，118 ms 是真实存在的，您应当在下单前亲自感受一下。可以向客服申请试用并自行测量。
DDoS 过滤会增加延迟吗？
稳定状态下延迟低于 1 毫秒——过滤在上游、在路径上完成，而不是绕道其他地方的清洗中心。遭受实际攻击时可能会略高一些，这是所有替代方案都会做出的取舍，只是通常不会说出来。
为什么伊斯坦布尔比法兰克福慢？
因为地理位置不等于网络拓扑。目前前往伊斯坦布尔的流量经布加勒斯特和索非亚中转，而非直接穿越黑海，这增加了地图上看不出来的距离。第三家运营商的加入很可能改善这一点，届时我们会重新发布数据，而不是悄悄留着旧数字不更新。