#原唯云四杰 🇭🇰可能真实存在“大包、小包走不同线路”的分流策略
近日，TG圈逐渐有人怀疑并讨论 #原唯云四杰 的大包、小包走不同分流策略。对此，我们利用Github的ping链接（404字节）以及从512KB到25MB不等的多种包大小进行了实测。
根据延迟（Latency）测试结果可以初步推测，imm、kuromis、nexitally三家机场在处理不同大小的数据包时，可能采用了不同的网络线路。具体来说，5MB及以上的大包延迟明显不同于404B、512KB、1MB和2MB的小包延迟，显示出大包和小包的延迟分布存在显著差异。这可能表明三家机场在处理大包时，采用了B线路，而小包则走A线路。
可以肯定的是，A线路在香港的延迟优化上表现确实出色，但在国际互联（peering）方面表现却较差，这导致A线路至Github新加坡CDN的小包延迟较高（中位数155ms），与B线路相差约25ms。这可能就是为了顶级香港延迟而产生的代价吧！
那么问题来了：你更愿意选择纸面延迟出色（小胜2ms RTT）但国际互联较差的 #局域网香港 ，还是选择纸面延迟良好但国际互联优秀（领先25ms RTT）的 #水桶香港 呢？
此外，原唯云四杰或将陆续更换BGP。这带来一个新的思考：即使国内段BGP可以压低1.3ms的延迟（以唯云对深联的优势为例），这与国际互联损失的25ms相比，似乎杯水车薪？
若非此次入口更换风波，这一问题或许不会引发关注。正如那句话所言：“只有潮水退去，才能看见谁在裸泳。”
近日，TG圈逐渐有人怀疑并讨论 #原唯云四杰 的大包、小包走不同分流策略。对此，我们利用Github的ping链接（404字节）以及从512KB到25MB不等的多种包大小进行了实测。
#复刻思路：
curl -o /dev/null -s -w $GITHUB不同大小链接
#记录 %{time_starttransfer} 延迟
省流剧透：情况可能属实！
根据延迟（Latency）测试结果可以初步推测，imm、kuromis、nexitally三家机场在处理不同大小的数据包时，可能采用了不同的网络线路。具体来说，5MB及以上的大包延迟明显不同于404B、512KB、1MB和2MB的小包延迟，显示出大包和小包的延迟分布存在显著差异。这可能表明三家机场在处理大包时，采用了B线路，而小包则走A线路。
一种猜测：
A线路：原为唯一入口至Jinx落地，现为深圳联通入口至Jinx落地（或许还有其他答案）
B线路：原为唯一入口至未知 落地，现为深圳联通入口至未知 落地。
可以肯定的是，A线路在香港的延迟优化上表现确实出色，但在国际互联（peering）方面表现却较差，这导致A线路至Github新加坡CDN的小包延迟较高（中位数155ms），与B线路相差约25ms。这可能就是为了顶级香港延迟而产生的代价吧！
那么问题来了：你更愿意选择纸面延迟出色（小胜2ms RTT）但国际互联较差的 #局域网香港 ，还是选择纸面延迟良好但国际互联优秀（领先25ms RTT）的 #水桶香港 呢？
此外，原唯云四杰或将陆续更换BGP。这带来一个新的思考：即使国内段BGP可以压低1.3ms的延迟（以唯云对深联的优势为例），这与国际互联损失的25ms相比，似乎杯水车薪？
若非此次入口更换风波，这一问题或许不会引发关注。正如那句话所言：“只有潮水退去，才能看见谁在裸泳。”