#技术杂谈
好几天没更新了。我们最近在构思一个新的评测思路，后续将对专线机场增加一个有那么一点点🤌🤌创新的评测环节。

众所周知，不同人的评测/评价，往往容易陷入“公说公有理，婆说婆有理”、“刻板印象偏差”等逻辑困境🚧，而 横向对比 永远是逻辑学上的优选方法论——简练、粗暴、直观！

评测机场的水准几何，可能至少包括三大块拼图：
1️⃣针对带宽速率参数，展开机场间的横向对比。
✅已被Miaospeed、FullTclash等项目攻克

2️⃣机场节点的解锁、IP风险等参数的横向对比。
✅已被Miaoko、FullTclash、Koipy等项目攻克

3️⃣横向对比不同机场/专线的真实延迟❗️尤其稳定性❗️。
⚔️截至目前，至少缺乏一个可靠的标尺来直观对比
💡我们试图造个小轮子，解开这最后一块拼图：把 #顶级机场 当做计量单位对照组，待测机场视为干预组，横向比一比。

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

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

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

届时，我们将拿花云的复测来作为此项新环节的首秀。

Fig_FlowerCloud99_SS.png

455 KB