尽管其他机场的广港更换深圳联通后，延迟已追平，但SLA与奶昔仍有差距。
#️⃣切勿小看1~2%的SLA差距，这在运营商/云服务商的定价表中往往相隔巨大价差！

节点入口可在官网二次更换

根据我们的延迟稳定性实测，🇭🇰节点的确言符其实，全天候99%！

因路途更远，且需经香港、美西、美东等多地交换并吃QoS

简单来说，就是200次延迟的离散/聚集程度。 箱子高度越矮、外根须越短、根须外离群值越少，都越好。

简单来说，个别机场的转发端使用了“超时即劫持”的激进策略，产生

实际已超时但看似未超时

的假象。
有效N，只统计排除假象后剩余的N：越接近100%，意味着被劫持的虚假延迟次数越少、极端超时情况也越少见。

通俗的解释是：
l 

卡顿

：由于网络延迟过高，数据传输的真实时间变长，导致画面、声音、或操作的响应变得迟缓。比如在网页浏览时，偶尔遭遇网页打开慢半拍；在视频通话中，会看到画面卡顿或声音断续；在游戏中，角色动作会延迟或跳帧。

l 

断流

：在游戏中，高 ping 会导致角色动作延迟；在视频通话中，高 ping 会导致声音和画面不同步或出现卡顿。在ChatGPT中，输入Prompt后报错Error或卡断，需要重复点regenerate刷新。

最近与唯云相比，已无可感知的延迟差距。但花云的日间、晚高峰分别存在约1.5%、3%的High Ping（图中标注的“离群值”），而基准机场则全天候为0%！
#️⃣ 值得注意，基准机场的🇭🇰晚高峰也非完美无瑕，虽无High Ping，但有1.5%无效HTTP Code并伴随异常低的"虚假Low Ping"。
#️⃣ 我们猜测，缘于服务器转发策略设定激进，一旦监测到可能有超时风险的数据包，就提前进行劫持，以避免表面上的延迟波动——类似现象也出现在花云🇪🇺晚高峰时段。
#️⃣ 上述可疑现象，都能被我们构造的统计图捕捉到，表现为“离群值=0个，但有效N<100%”。

沪日专线，花云RTT/HTTP与基准机场无人体可感知差距。
#️⃣ 但花云High Ping略多一点，约4~6%，而基准机场则为2~4%

中欧/京德专线的优势科目，所有方面都遥遥领先“绕港、转美、再入欧”的延迟和起手带宽。
#️⃣ 如果将常人感知极限的20ms定为一个档差，那么花云的RTT/HTTP在日间（或晚高峰）领先基准机场2/3个（或2/5个）档差。

📸大致的剧透：
我们将选取固定观测点，在软路由（主路由）上挂载shell脚本，定时间间隔地采集主路由到机场不同地区的代表性节点RTT和HTTP延迟。

⛔️基于失真的数据出发，无疑得不到可信的结论。然而由于众所周知的延迟劫持，想要拿某个机场和 #顶级机场 进行横向对比，困难重重：
1️⃣ 小包检测延迟的最佳链接，几乎都遭到了劫持
2️⃣ 未被劫持的链接往往由于路由层级较多，导致RTT失真
3️⃣ 使用不那么小的包来检测延迟，虽无劫持，但却不可避免导致HTTP(S)延迟的高估。

🍀幸运的是，我们终于找到2个极为合适的延迟测试链接，
1️⃣ 均为Google家的延迟链接，路由比CloudFlare少，RTT更真实
2️⃣ 这些延迟专用链接均为小包，不必担心高估HTTP(S)
3️⃣ 最重要的是，由于未被劫持，只要是在相同协议（如SS或Trojan）下运行的机场，均可进行横向比较。