由TG散户群体自发形成的测速社区。专注*用户测*的体验：单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
➤专线入口天梯表: https://www.haitunt.org
欢迎所有 用户👨🏻💻 和 机场主🕋 投稿，共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项，仅受理*原投稿人*。
讨论群: @haitunspeed
频道: @haitun_channel
《SS / Trojan 刷网页的实际延迟对比：下篇》
可能有人想问 v2ex.com 不是有挂 Cloudflare CDN？难道CDN不能改善加载耗时吗？
3️⃣ 访问挂载 CDN 的网站，其 #动态文件 的加载延迟依然对「用户侧耗时」拖后腿，属于压死骆驼的最后一根稻草。
4️⃣ 那么，所有的 CDN 都无法扭转东道主优势吗？
5️⃣ 我该用哪的节点？
#漫谈 #技术杂谈 #rtt #延迟 #脚本
可能有人想问 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 #延迟 #脚本
《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 #延迟 #专线 #协议
《RTT和HTTPS，哪种延迟更有参考价值？》
#技术杂谈 #延迟 #RTT #HTTPS #时延 #mihomo
很多人在纠结 Mihomo核心 #统一延迟 是否☑️ 时，常面临两种观点：有人坚持 RTT 延迟测试"自欺欺人"，有人推崇 RTT 作为首选指标。
1️⃣ RTT vs HTTPS延迟的区别
2️⃣ 为什么说RTT在今天更有参考价值？
3️⃣ 实用结论
在2025年还在固守成见——认定RTT是”自欺欺人“。对此，你怎么看？
#技术杂谈 #延迟 #RTT #HTTPS #时延 #mihomo
很多人在纠结 Mihomo核心 #统一延迟 是否☑️ 时，常面临两种观点：有人坚持 RTT 延迟测试"自欺欺人"，有人推崇 RTT 作为首选指标。
✍️全文省流：
在2025年，选RTT/统一延迟未尝不可！
但若回到2019年之前，那就HTTP(S)延迟
1️⃣ RTT vs HTTPS延迟的区别
见 往期推文 👈
2️⃣ 为什么说RTT在今天更有参考价值？
❶ 连接复用技术普及
➤ HTTP Keep-Alive 已成为标准配置
➤ HTTP/2 和 HTTP/3 支持多路复用，标志着网络瓶颈从"建立连接的耗时"转移到了"往返延迟RTT"❗️
➤ TLS 1.3 优化（从2-RTT减至1-RTT，支持0-RTT恢复）
🔰根据 HTTP Archive 对近3000万个网站样本的统计，早在2023年支持HTTP/2的网站就已超过70%。
❷ 实测验证
➤ 在已建立连接后，无论是主文档(document)、图片，还是其他放置在CDN的素材，加载时间都更接近RTT值❗️
➤ 经测试ChatGPT、谷歌、v2ex等网站的素材加载均如此。
3️⃣ 实用结论
❶ 初次访问🟡：完整HTTPS延迟更有参考价值
🔰此类访问示例：
打开 aaa.com 后立即舍弃，然后访问 bbb.com 后立即舍弃，继续 ccc.com ……
（周而复始，永不重样！但脱离了正常场景❓）……
❷ 持续访问🟢：RTT最关键，特别对于：
➤ 重复访问的网站及子页面
➤ 使用HTTP/2或HTTP/3的现代网站 （今天的绝大多数❗️）
➤ 使用CDN的网站
➤ 交互式App（如社交媒体、音视频/会议、游戏等）
🔰此类访问示例：
¹ 利用 DoH、DoH3、DoQ 等协议查询 DNS。
² 打开 telegram.org 后，点击二级页面 FAQ，然后转去 Moderation 继续浏览。
³ 在 TG群、Reddit、V2ex等灌水，在 YouTube、TikTok、网飞等刷视频，在谷歌、必应、ChatGPT等获取资讯
在2025年还在固守成见——认定RTT是”自欺欺人“。对此，你怎么看？
