#原唯云四杰 #奶昔 #库洛米 #IMM #花云 #咸鱼加速器 #TKV #阴阳分流 #香港 #广港 #技术杂谈

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 #Twitter 等高风控网站时，*可能*非常危险☠️

1阴阳分流：原唯云四杰区分Jinx和Eons节点.png

273.4 KB

2阴阳分流：加入TKV.png

273 KB