由TG散户群体自发形成的测速社区。专注*用户测*的体验：单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
📝 摘要：用户发现GPT-5.2在基准测试中疑似通过海量Token策略刷高分击败Gemini 3.0 Pro，引发争议。
有网友质疑其性能被夸大，OpenAI被指可能存在虚假营销。
来源：IT之家
🔗 阅读原文
#AI模型 #基准测试 #技术争议
─────────────────
🐬 海豚测速频道 | @haitun_channel
📢 精选资讯分享，欢迎投稿
《SS / Trojan 刷网页的实际延迟对比：上篇》
不少一/二线同时提供 SS＋Trojan 协议。众所周知的是，这俩虽然 RTT 相同，但因 Trojan 多一次握手，所以其 HTTP(S) 延迟 > SS协议。那么，优先选 SS 吗？
此时，有必要引入一个相关的问题/争议。不少人认为，HTTP(S) 延迟才最反映刷网页的实际体验。沿着这一逻辑，继而认为，SS 协议的 HTTP(S) 延迟更低，那么在日常使用中就应优先用 SS 节点。
👉 问题来了，节点『HTTP(S) 延迟』真的最能反映 “刷网页的实际耗时” 吗⁉️ 省流：不能，其参考价值还不如 RTT ！
—————
对此，本文专门进行检验，得到了一些有趣的发现：
1️⃣ 相同入口-相同专线-相同落地，同时搭 #SS 和 #Trojan 节点，两者 HTTP 延迟差异较大（≈1次 RTT），但开网页的实际耗时差异→0❗️
2️⃣ 看到这里，似乎 RTT 才是决定「用户侧网页加载耗时」的关键？沿着这个逻辑，RTT 越低，访问网站就越快？
原文有修改。因字数限制，展开一些论述后，必须剁成两篇
#漫谈 #技术杂谈 #rtt #http #https #延迟 #专线 #协议
不少一/二线同时提供 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 #延迟 #专线 #协议
《积至 和 GFW 究竟有无关联？》
自 gfw.report 该报告 (简称《报告》) 和本频道上回推文发布以来，大量争议聚焦在 ”积至公司“ 是否为 GFW 的关联实体 (含技术共享、白手套)，以及墙是否迎来大幅升级。
争议相关的 三方论点 梳理如下
✍️ 读者请自行判断更接受哪种论点？ 欢迎补充其他论点……
#漫谈 #技术杂谈 #GFW #积至公司 #积至 #geedge
自 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
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
#技术杂谈
针对一些意见的回应：
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），那必定喜闻乐见。例如回应过此事的机场/频道，就不失为一家在三者之间取得较好平衡的例子，也是值得推荐的。
