由TG散户群体自发形成的测速社区。专注*用户测*的体验：单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
#深联十三太保 再见， #前海四杰 你好！
《对AS135061 深圳前海IXP的观察》
#技术杂谈
今日， #原唯云四杰 新换了 #深圳前海IXP 的BGP。从目前本频道掌握的信息来看，梳理如下几个常见疑问和可能的答案：
1️⃣ 深圳前海IXP是什么？
2️⃣ 新型IXP相对于旧的16个NAP有何优势？
3️⃣ 一个自然而然的问题，新型IXP入口的疗效究竟如何？
4️⃣ 补充
#唯云四杰 #新疆电信 #深圳前海IXP
《对AS135061 深圳前海IXP的观察》
#技术杂谈
今日， #原唯云四杰 新换了 #深圳前海IXP 的BGP。从目前本频道掌握的信息来看，梳理如下几个常见疑问和可能的答案：
1️⃣ 深圳前海IXP是什么？
四大国家新型互联网交换中心（IXP）之一，属于2019年以来国家级战略“东数西算”配套设施，致力改善区内跨网及东/西部之间的网络性能。
新IXP分布：深圳前海、宁夏中卫、浙江杭州、上海临港。
✍️ 如前海已接入电、联、移、广四大运营商，华为、阿里、腾讯等大厂云，以及部分二级运营商和IaaS。
2️⃣ 新型IXP相对于旧的16个NAP有何优势？
❶ 提升跨运营商/IDC的网间互通性能。
✍️ 例如，杭州电信到杭州移动曾经跳数较多（杭电 -> 沪电 -> 上海NAP -> 沪移 -> 杭移），导致跨网时延居高不下。而IXP可实现在杭州本地互联，显著降低延迟。
❷ 改善远距离尤其东/西部间的网络性能。
✍️ 如宁夏-北京，从原本35ms（西安NAP）大幅降低至20ms（中卫IXP）。此外，中卫IXP周边大区也可从中获益。
3️⃣ 一个自然而然的问题，新型IXP入口的疗效究竟如何？
不看纸面，看疗效。本频道借助 #乌鲁木齐电信 后端对延迟进行测试。
该观测点的优势：
❶ 首先它是电信，契合AS135061的电/联双组网；
❷ 相对深圳，既符合远距离，也归属IXP重点优化的西部；
❸ 乌鲁木齐—宁夏IXP—深圳IXP，较之“乌市—西安NAP—广州NAP—深圳”的传统路由基本不新增绕路。
遗憾的是，我们 🚫
未找到🚫
前海IXP相对于深圳联通具有时延优势
的证据❗️
✍️ 如 #库洛米 (深IXP) 对比 #YTOO (深联) 的🇭🇰🇸🇬，延迟🈚显著优化；反倒略逊YTOO一筹，着实出乎意料！
4️⃣ 补充
10月1日
❌ 据成都电＋联、广州移动、湖北移动、广西电＋移的测试，丢包、掉速严重。
☢️ 晚高峰和闲时差异巨大：深圳/广州电信
✅ 带宽与延迟稳定：珠海/佛山联通，及走 #无锡Pub云 的上海、浙江。
有趣的是，以成都为例： ❶奶昔强改host到
入口后大幅改善。❷IMM的前海跨省性能，属四杰里唯一较安好的。
总之，IXP跨区跨网仍不完美，建议谨慎决定❗️
✍️ 其他区域体验，欢迎留言补充
#唯云四杰 #新疆电信 #深圳前海IXP
#技术杂谈
针对一些意见的回应：
1️⃣ 大、小包是指什么？
2️⃣ 数据请求多大算大，多小算小？
3️⃣ 有无可能所谓“阴阳分流”指的是传输段，而不是落地？
4️⃣ 再谈阴阳分流对用户和商家的影响。
针对一些意见的回应：
1️⃣ 大、小包是指什么？
大小包的称呼是取自TG圈一种通俗化的说法，而非我们原创。严格来说，小包 指小尺寸的数据请求，大包 指较大的数据请求。
2️⃣ 数据请求多大算大，多小算小？
首先，我们不是基于“先验”来定义，而是基于各机场的实际表现进行“后验”概括。从之前的图来看，部分机场香港节点在2MB和5MB之间存在跳跃，那么姑且概括2MB及以下为小包，5MB及以上为大包。这仅仅是便于描述的概括。
3️⃣ 有无可能所谓“阴阳分流”指的是传输段，而不是落地？
确有可能。事实上，有关阴阳分流，暂可从大家集思广益中梳理如下可能：
❶
Github CDN优化策略
。这点首先排除。从基于相同控制变量的实测来看，部分机场有延迟跳跃，而与此同时的另2个(对照组)机场却无延迟跳跃。假如Github CDN有优化策略，那么没理由针对不同机场呈
歧视性差异
。
📝注1：DNS均套香港IP的ECS，只会就近连🇸🇬CDN。
📝注2：Github在亚太仅有🇯🇵🇰🇷🇸🇬三处CDNs，但香港至日(韩) RTT约52ms(76ms)，都远大于阴阳25ms剪刀差。
❷
国内段路由在测试时存在变化
。该可能性也可以排除，因控制变量包括同一软路由和宽带、深联入口、测试在短时间内一次完成。测试的网络环境既非广电宽带，也非二级运营商，且维持相同控制变量。
❸ 落地存在分流。这是最具争议的一种可能性，起源于坊间关于Jinx的传言及讨论。今日，我们又利用同处新加坡的VPS自建网盘实测，
虽不能彻底排除这一可能性，但其发生的概率应当降低
。理由是：我们通过测试自建VPS网盘的延迟，不论数据包尺寸，#原唯云四杰 和 #TKV 延迟均在145ms左右且IP均为同一落地IP——该延迟接近阴阳线路的“小包”延迟155ms，但高于阴阳线路的“大包”（或白名单）延迟130ms。
❹ 跨境线路的分流，或许是最大的可能性！可能的解释是：小包被路由到一条成本占优的链路连通落地，可能经过更多中间节点，因此延迟更高；大包则被路由到一条延迟较低（但成本不占优）的链路。
4️⃣ 再谈阴阳分流对用户和商家的影响。
如果可能性❹是成立的，就有必要从三方面来谈：
👥 用户体验
。
由于小数据请求场景中，网络性能要求不高，如常规网页场景，通常50ms内的
延迟差
都不易察觉。而流媒体场景，传输性能的敏感度更高（如YouTube娱乐分就与RTT延迟
负相关
），则适合走“大包”链路确保低延迟。其他场景就看商家的
白名单
如何设置了。
💼 商家成本
。
据Akamai统计，Smaller Packet（小包）虽单个包小，但累积量大，占全球70%以上流量。将小包流量通过较为经济的高延迟链路传输，节省带宽成本；而将大包通过低延迟、高成本链路，确保传输质量。这在运营成本上，也合乎情理。
💰 产品售价
。
阴阳分流的短板似乎不多，但好处呢？有助于在成本、售价和用户体验三者之间找到 #
平衡点
。
如果商家在削减自身成本的基础上，
进一步让利给用户，将售价定在甜点区
（如专线 ≤0.2元/GB），那必定喜闻乐见。例如回应过此事的机场/频道，就不失为一家在三者之间取得较好平衡的例子，也是值得推荐的。
#原唯云四杰 #奶昔 #库洛米 #IMM #花云 #咸鱼加速器 #TKV #阴阳分流 #香港 #广港 #技术杂谈
1️⃣ 我们尝试厘清究竟是Jinx的阴阳分流策略，还是奶昔自己的策略。遗憾得知，不管是Jinx还是Eons落地节点，都存在阴阳分流。
2️⃣ 意外发现，TKV也*可能*存在大小包的阴阳分流。
控制变量：
❶ 同一个网络环境（含运营商＋Openwrt＋Openclash＋深联入口机场）排除软硬件和国内线路干扰。
❷ 相似的时间段：排除时段干扰。除此，每次对同一机场节点连续、每隔2秒一轮curl，且每轮都逐个curl不同大小包，以此循环100轮。
❸ Curl同一网站即Github的🇸🇬CDN：排除机场对流媒体（或其他正常分流需求）的识别干扰。
对照组：
❶ 符合常理的机场相应区域节点
FAQ：
❶ 这个图是什么？
❸ 只要用起来顺手，阴阳分流又能奈我何？
1️⃣ 我们尝试厘清究竟是Jinx的阴阳分流策略，还是奶昔自己的策略。遗憾得知，不管是Jinx还是Eons落地节点，都存在阴阳分流。
2️⃣ 意外发现，TKV也*可能*存在大小包的阴阳分流。
控制变量：
❶ 同一个网络环境（含运营商＋Openwrt＋Openclash＋深联入口机场）排除软硬件和国内线路干扰。
❷ 相似的时间段：排除时段干扰。除此，每次对同一机场节点连续、每隔2秒一轮curl，且每轮都逐个curl不同大小包，以此循环100轮。
❸ Curl同一网站即Github的🇸🇬CDN：排除机场对流媒体（或其他正常分流需求）的识别干扰。
对照组：
❶ 符合常理的机场相应区域节点
FAQ：
❶ 这个图是什么？
这是折线图。
横轴：包大小(Packet Size)，由小至大依次是：512KB、1M、2M、5M、10M、25M。
纵轴：利用节点访问Github的HTTP延迟
图中的每一条线，代表某个机场的某个节点
❷ 这个图怎么看？
理论上，如果没有阴阳分流策略，不论数据包文件有多大，从客户端发出请求到接收到第一个字节响应的时间（Start Transfer Time）都应当趋同。
#️⃣ 例如 #FlowerCloud 和 #NexusCloud (咸鱼加速器) 的延迟近乎一根水平线，这才是正常情况。
反之，如果数据包大小能够改变延迟表现，那就意味着存在“大小包分流”。
#️⃣ 例如，图中 #Nexitally 、#Kuromis 、#IMM 、#TKV 都在2MB与5MB之间存在“延迟跳跃”（约25ms断层），那么就有理由怀疑，2MB及以下、5MB及以上走的实际链路是不同的。否则，不会出现这种反常情况。
❸ 只要用起来顺手，阴阳分流又能奈我何？
首先，2MB的数据包在网页浏览中已经不算小了，哪怕图片素材很少的谷歌搜索页面都在2~10MB左右。
然后，可以想象一个场景：如果一个页面是2MB，下一个页面是5MB甚至更高，那么浏览时因自动触发的阴阳分流，*可能*导致访问网站的IP反复横跳——此时，轻则触发部分网站的验证码；重则导致账号被封❗️
#️⃣ 这在访问#OpenAI#ChatGPT#Claude等高风控网站时，*可能*非常危险☠️
#技术杂谈 #原唯云四杰 🇭🇰可能真实存在“大包、小包走阴阳线路”的分流策略
近日，TG圈逐渐有人怀疑并讨论 #原唯云四杰 的大/小包走不同分流策略。对此，我们利用Github的ping链接（无头文件，记为404B）以及从512KB到25MB不等的多种包大小进行了实测。
根据延迟（Latency）结果初步推测，imm、kuromis、nexitally三家机场在处理不同大小的数据包时，可能采用了不同的网络线路。具体来说，5MB及以上的大包延迟明显不同于404B、512KB、1MB和2MB的小包延迟，显示出大包和小包的延迟分布存在显著差异。这可能表明三家机场在处理大包时，采用了B线路，而小包则走A线路。
可以肯定的是，A线路在香港的延迟优化上表现的确出色，但在国际互联（peering）方面表现却较差，这导致A线路至Github🇸🇬CDN的小包延迟高（中位数155ms），与B线路相差约25ms。这可能就是为了顶级香港延迟而产生的代价吧！
那么问题来了：你更愿意选纸面延迟优秀（小胜2ms RTT）但国际互联实际较差的 #局域网香港 ，还是纸面延迟良好且国际互联优秀（领先25ms）的 #水桶香港 呢？❗️
此外，原唯云四杰或将陆续更换BGP。这带来一个新的思考：纵使国内段BGP进一步压低1.3ms的延迟（以唯云对深联的优势为例），这与国际互联损失的25ms相比，似乎杯水车薪？
若非此次入口更换风波，这一问题或许不会引发关注。正如那句话所言：“只有潮水退去，才能看出谁在裸泳。“
近日，TG圈逐渐有人怀疑并讨论 #原唯云四杰 的大/小包走不同分流策略。对此，我们利用Github的ping链接（无头文件，记为404B）以及从512KB到25MB不等的多种包大小进行了实测。
#复刻思路：
curl -o /dev/null -s -w $GITHUB不同大小的文件
#循环100次，记录 %{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。这可能就是为了顶级香港延迟而产生的代价吧！
乍一看反直觉，但实际原因可能是：Jinx本身规模小，没能力谈到对等互联，所以跨网都以流量计费，这样不得不换peering好但物美价廉的其他落地去分流大包。
或许又有人疑问：直接用物美价廉、peering好的落地做全局转发岂不更好？其动机包括：
❶ Peering不好，不代表它
🇭🇰大内网延迟
不好【类比 电信163家宽】；
❷ Ak的peering更好，但你又愿意
付多少溢价
买落地是它的机场呢【类比 移动家宽】
。
此外，原唯云四杰或将陆续更换BGP。这带来一个新的思考：纵使国内段BGP进一步压低1.3ms的延迟（以唯云对深联的优势为例），这与国际互联损失的25ms相比，似乎杯水车薪？
若非此次入口更换风波，这一问题或许不会引发关注。正如那句话所言：“只有潮水退去，才能看出谁在裸泳。“
#技术杂谈 #香港 #广港 #深港 #广港专线 #唯云 #唯一 #唯一入口 #唯云四杰 #深圳联通 #奶昔 #IMM #花云 #西数 #TKV #咸鱼加速器 #咸鱼 #西部数据
近日，随着 #原唯云四杰 入口更换为深圳联通，🇭🇰节点的延迟表现及稳定性备受质疑。
我们今日下午16:36~18:00之间测试了部分 #深联十三太保 ，将结论汇总如下：
1️⃣ 最受关注的问题：奶昔（乃至原唯云四杰）延迟及稳定性倒退多少？
2️⃣ 原唯云四杰的表现放在今天，究竟如何？
近日，随着 #原唯云四杰 入口更换为深圳联通，🇭🇰节点的延迟表现及稳定性备受质疑。
我们今日下午16:36~18:00之间测试了部分 #深联十三太保 ，将结论汇总如下：
1️⃣ 最受关注的问题：奶昔（乃至原唯云四杰）延迟及稳定性倒退多少？
对比奶昔的9月2日和8月10日结果可知，更换深圳联通后：
❶ RTT延迟＋1.3ms
❷ HTTP延迟＋6ms
❸ 期望SLA从99%降至98%，但依然是今日所测机场中的最高水准！
❹ 最后是一个坏消息：可惜 #普通节点 走大包的带宽有问题，例如在西南，油管娱乐跑分仅5W（本地理论上限为65W）‼️加钱上#Premium节点则不受影响#Premium节点 跨省也有影响，只是程度轻‼️
2️⃣ 原唯云四杰的表现放在今天，究竟如何？
这个问题很难回答。
❶ 按RTT延迟排序，由快至慢：imm、花云、咸鱼、西数、奶昔、TKV、YTOO
❷ 按HTTP延迟排序，由快至慢：imm、花云、奶昔、咸鱼、西数[估]、TKV、YTOO
❸ 按抖动排序，由优至劣：咸鱼、TKV、花云、西数、imm、奶昔、YTOO
❹ 按
期望SLA
排序：
98%：奶昔*、TKV**
97%：花云、咸鱼加速器
96%：Imm、西部数据
...
92%：YTOO***
* 奶昔的非Premium节点，如果走大包，带宽明显低于其他机场，可能是跨省策略有问题
** TKV根据我们半个月前测试，日间虽很猛，但晚高峰有明显倒退，约降3~5%
*** YTOO今日表现属实令人意外
