海南出入口局会成为中国流量出海的新宠儿吗？

好奇心作祟，收集沿海城市海缆登陆的名单及设定容量等数据，发现了一些非常有趣的小细节/鬼故事。

1️⃣ 待海南 2 条新光缆投用后，它将超越 #上海 并跃居国际海缆容量第二，仅次于 #香港。

2️⃣ 近 20 年登陆 “陆港澳” 的 #海缆，仅 3 条的前五大出资方不含「三大运营商及其子公司/孙公司」。

换言之，若把 #国资参投 的剔除，香港仅剩 72.4 Tb，占原总量的 6.7%❗️

严格来说，72.4 Tb 也含有 “水分”，例如由 🇮🇳Tata 独资 3.84 Tb 的 TGN-IA，允诺给 🇭🇰 PCCW (联通的关联公司) 享用部分容量。其他国际海缆类似，但因缺乏细化的各方容量分配信息，我们只能简单地对登陆海缆的设定容量作加总。

3️⃣ 把即将投用的 2 条新缆（SEA-H2X 和 ALC，合 498Tb）统计与否，陆港澳的国际海缆容量依次是

海缆总容量Tb， 去掉2条新缆Tb
香港， 1079 581
海南， 498 ❗️ 0
上海， 451 451
汕头， 214 214
青岛， 56 56

注：琼-珠-港 307.2Tb、福-台 8Tb 未纳入上表。陆缆又因缺乏公开数据，也未入表。

海南，此次不仅实现 0 突破，更是纵身一跃 No.2❗️
海量大货将至，“三网优化＋击穿地板价” 的 #两亚 🐔大有可为。

4️⃣ 再来看，海南会成为新宠儿吗

极有可能！
❶ 此次出入口局扩容，#海口 是唯一获批 3 网出入口局的存在，且带 “海南自贸港”＋“中国-东盟”＋“数字经济和数字时代互联互通” 三重政策红利！
❷ 拆墙试点 等等动向，都昭示着 #海南 的与众不同。
❸ 鉴往知来，🇭🇰国际海缆容量也是靠吃政策饭发家的，见2️⃣的数据。国家层面 “钞能力”，既可培育出 #香港网络枢纽，也就能再造第二个 #海南网络枢纽。
❹ 三大运营商在🇺🇸业务已遭驱逐，透过海南将国际业务的大本营转移🇸🇬也算顺势而为。恰巧，#昆明 #海口 的交点正汇聚🇸🇬

某种程度上，中美贸易战以来的🇸🇬也算是吃了国内政策饭

#漫谈 #海南国际局 #海口出入口局 #新加坡 #东南亚

海豚机场测评｜用户侧体验｜测速频道

对比ss-trojan刷网页的真实耗时.png

《SS / Trojan 刷网页的实际延迟对比：下篇》

可能有人想问 v2ex.com 不是有挂 Cloudflare CDN？难道CDN不能改善加载耗时吗？

3️⃣ 访问挂载 CDN 的网站，其 #动态文件 的加载延迟依然对「用户侧耗时」拖后腿，属于压死骆驼的最后一根稻草。

例如 v2ex，其静态文件（CSS、部分图片）可通过 CF 全球/就近分发，但动态内容（帖子、评论等）则必须从美国 #建站鸡 拉取。

➤#动态文件 链路：🇺🇸源服务器 ➜节点 ➜你家，越接近 “直线” 就越快。
➤#静态文件 链路：🌎临近CDN ➜节点 ➜你家，就近分发。

再回头看图，就不难理解为何从快到慢依次是 🇺🇸 ＜🇯🇵 ＜🇭🇰 ＜🇩🇪。 🇺🇸节点对 #美国鸡 有东道主优势。

4️⃣ 那么，所有的 CDN 都无法扭转东道主优势吗？

答案：未必，要看网站类型。例如 #油管 (某种程度上) 、#网飞 等以分发静态视频为主的网站，其体验又主要由 CDN 决定。

甚至，谷歌、微软 对高优先级的 #搜索 业务，会采用高成本的全球分布式前端技术＋全球私有骨干网，无论用哪里的节点都快！

不过，前面提到的视频站，也有反例。

例如 XVi*、xHam* 等虽然挂 CDN，但未对太多视频上云（成本考量），所以仍要从 🇪🇺源服务器 拉取；P*Hub 也要从 🇺🇸源服务器 拉取。此时，因地制宜地用当地节点观影，首帧延迟、起速都更有优势。

反例之外，还有反转。

#YouTube 虽挂 CDN，且对视频资源上云，但每个 CDN 的视频缓存有着明显的「地域偏好」。或许有人已注意到，
➤ 用 🇭🇰🇸🇬 加载「简中＋部分繁中」视频很快，RTT < 25ms 也轻松跑 100w 娱乐分；但加载欧美视频，因要从🇺🇸🇪🇺服务器拉取，又变得很慢，娱乐分咔咔掉。毕竟 city-level CDN 体量小……
➤ 用 🇯🇵 加载「简繁中＋日文」视频很快，但其他的…也就比🇭🇰🇸🇬好一点，但不多……

总之，各家采购 CDN 策略复杂。

5️⃣ 我该用哪的节点？

很难一概而论，毕竟每个人的机场、节点状况、常逛网站等大相径庭。不如用 随附的 .js #油猴脚本 测试一下，并把你的结果＋机场分享到评论区。

对于本文环境，🇺🇸最佳、🇯🇵 其次、🇭🇰再次…

⚠️ 测试务必接网线，且最好💉打鸡血排除远距离掉速的干扰！

#漫谈 #技术杂谈 #rtt #延迟 #脚本

LoadingTime.js

7 KB

《SS / Trojan 刷网页的实际延迟对比：上篇》

不少一/二线同时提供 SS＋Trojan 协议。众所周知的是，这俩虽然 RTT 相同，但因 Trojan 多一次握手，所以其 HTTP(S) 延迟 > SS协议。那么，优先选 SS 吗？

此时，有必要引入一个相关的问题/争议。不少人认为，HTTP(S) 延迟才最反映刷网页的实际体验。沿着这一逻辑，继而认为，SS 协议的 HTTP(S) 延迟更低，那么在日常使用中就应优先用 SS 节点。

部分人的观念：RTT 延迟对于日常网页毫无参考价值，仅供意淫之用…🥲

👉 问题来了，节点『HTTP(S) 延迟』真的最能反映 “刷网页的实际耗时” 吗⁉️ 省流：不能，其参考价值还不如 RTT ！

—————
对此，本文专门进行检验，得到了一些有趣的发现：

1️⃣ 相同入口-相同专线-相同落地，同时搭 #SS 和 #Trojan 节点，两者 HTTP 延迟差异较大（≈1次 RTT），但开网页的实际耗时差异→0❗️

如4个子图的左/右箱体所示。仅有的差异来自网络自身的波动

2️⃣ 看到这里，似乎 RTT 才是决定「用户侧网页加载耗时」的关键？沿着这个逻辑，RTT 越低，访问网站就越快？

答案：对，但也不对。

➤『对』的理由：横向对比（同一地区内比较）RTT 相同的节点，网页加载耗时理应相同——图中 #SS 和 #Trojan 的「网页加载耗时」无差异，就提供了“逆否命题”的论据。

➤『不对』理由：纵向对比（跨地区比较），RTT 越低的节点，并不意味着更低的「网页加载耗时」，如图中的🇺🇸和🇭🇰。这是因为，还有一个巨大的干扰项 #动态文件 ——暂且搁置，到第3点再谈。

至此，不妨碍我们先提炼第二个有用的结论：

✍️ 严格意义上，节点的 RTT、HTTP(S) 两类延迟都有槽点，但 HTTP(S) 延迟的槽点更大、误导性更强❗️

原文有修改。因字数限制，展开一些论述后，必须剁成两篇

#漫谈 #技术杂谈 #rtt #http #https #延迟 #专线 #协议

对比ss-trojan刷网页的真实耗时.png

439.4 KB

海豚机场测评｜用户侧体验｜测速频道

《从 GFW 泄露文件审视网络代理的未来》 9 月 11 日，一份从 GFW 内部流出的文件（见 gfw.report 的报告, 或 TG 推文）颠覆了许多人对代理安全的既有认知：已快进到 通过植入证书来进行 MitM。 1️⃣ 当前主流的代理方式 或不再安全 泄露文件及其讨论 1、讨论 2 等指出：只要你设备的 “证书” 被污染，无论套多少层加密或隧道技术，对于 #GFW 都不过是衣不蔽体。 ⚠️25-09-20 注：积至 (Geedge) 和 GFW 的关联性 争议不休！ 2️⃣ 积至的新技术：以主动…

《积至 和 GFW 究竟有无关联？》

自 gfw.report 该报告 (简称《报告》) 和本频道上回推文发布以来，大量争议聚焦在 ”积至公司“ 是否为 GFW 的关联实体 (含技术共享、白手套)，以及墙是否迎来大幅升级。

争议相关的 三方论点 梳理如下

🔻否定论点，如：
{⓵} 积至有关 FET 组件的部分代码抄袭自开源项目 apernet/ OpenGFW，意味着积至无法获取 GFW 源码，继而推定其不属于 GFW 的关联实体；
{⓶} 若积至与 GFW 无关联，那么基于《报告》所作的推定难免危言耸听；
{⓷} 如果风向走歪，仅凭积至的技术储备，足以让代理上网回归解放前，开发新协议也无解；
{⓸} 方某某 2016 年从北邮病退后，不再牵头 GFW 项目。人走茶凉，积至与 GFW 互不隶属，致使积至技术难以输往 GFW 迭代。
……

🔺肯定论点，如：
[⓵] GFW 为涉密 “9** 计划” 项目成果，自带 “密级”，其主持人 (方某某) 若非执意踩缝纫机，断不敢在他处复刻，故 否论{⓵} 的立论依据缺乏保密常识；
—注：涉密项目与商业项目的工作逻辑迥异。如某知名 985 保密规定覆盖全体 8**、9** 项目。
[⓶] 积至若非 GFW 的实体/白手套，其创立仅 1 年时就接到外国政府的建墙订单，实在不可思议；
[⓷] 积至公司即 GFW 的白手套，却被有意包装为与 GFW 无关，其原因包括：规避潜在的舆论风波、迎合 “密级” 需要，等；
[⓸] 尽管 GFW 和北邮深度绑定，但依惯例，高校总是授予 “领域大专家” 带话语权的终身席位，直至身故——意味着看似在野的积至，其技术库仍能反哺 GFW。
—注：方某某既是院士，又曾主持 9**，更曾任北邮校长，显然备受北邮尊重且话语权应不低。
……

🔷 共识论点，如：
(⓵) 积至虽为中小企业，但偏偏短小精悍，跨国承建了巴、哈、缅、埃塞等国 “GFW”，期间还调动高贵的 国资央企 联合作业；
—注：国资央企仅 98 家，国企 > 40万 家，民企 > 5000万 家
(⓶) 积至参与了新疆、江苏等省墙搭建，即《报告》的此点论述属实；
(⓷) 在特色制度背景下，省墙意味着某种政策的早期试点，但争执双方对试点扩张的概率预期不同。
—注：据哈佛对 1980~2020 年🇨🇳实施政策统计，约 58% 的试点夭折、不再推广全国。
……

✍️ 读者请自行判断更接受哪种论点？ 欢迎补充其他论点……

#漫谈 #技术杂谈 #GFW #积至公司 #积至 #geedge

《从 GFW 泄露文件审视网络代理的未来》

9 月 11 日，一份从 GFW 内部流出的文件（见 gfw.report 的报告, 或 TG 推文）颠覆了许多人对代理安全的既有认知：已快进到 通过植入证书来进行 MitM。

1️⃣ 当前主流的代理方式 或不再安全

泄露文件及其讨论 1、讨论 2 等指出：只要你设备的 “证书” 被污染，无论套多少层加密或隧道技术，对于 #GFW 都不过是衣不蔽体。

⚠️25-09-20 注：积至 (Geedge) 和 GFW 的关联性 争议不休！

2️⃣ 积至的新技术：以主动 MitM 来监管流量

据悉，积至公司的新技术，可通过 蜜汁证书➕MitM 随时监控、解密你的流量——只需通过各种手段，把它的《蜜汁证书》悄悄植入，成为潜伏在你设备里的内鬼，丝滑小连招即成。

该思路与 iOS 部分代理 #App 的 MitM 去广告等场景类似。只是在 #去广告 场景中，你是主动安装第三方证书。而在积至的新技术场景中，你是被动植入第三方 (投毒) 证书❗️

3️⃣ 今后的安全标准：或不能停留在 “传统加密”

RPRX (Xray-core 和 VLESS 开发者) 称其 Reality 协议和抗量子加密 (Post-Quantum Encryption, 简称 Encryption) 特性都独具优势。

开发者推介 ⓵ Reality 对 MitM 的抗性；⓶ 号召中转机场从 SS 切至 Encryption。

频道注：#Reality 至少在 GFW Pro Max 的新疆，表现独一档；但后者的整体表现如何，还有待观察。

━ #专线 机场中，S* 等个别引入 Encryption，又如 L*、Y* 等意外改用 Reality；
━ 现仅 ⓵ Xray >= v25.9.5 [9月5日更新]、⓶ Mihomo >= v1.19.13 [8月27日更新] 等极个别核心的新版本支持 Encryption 特性❗️
━ 基于上述核心的 App 名单，见海豚测速-代理工具篇。可利用版本号按图索骥，跟踪 协议 / 新特性 支持动向。

倘若情况变得更加严峻，#代理协议 开发者与 GFW 免不了新一轮的斗智斗勇。明天，你还会翻墙吗？

（⚠️ 25-09-21 全文内容有调整 ）

#漫谈 #技术杂谈 #vless #抗量子 #encryption #xray #mihomo