由TG散户群体自发形成的测速社区。专注*用户测*的体验:单线程表现、三网/国际区域表现、实际延迟&稳定性等综合评定。
➤专线入口天梯表: https://www.haitunt.org

欢迎所有 用户👨🏻‍💻 和 机场主🕋 投稿,共建透明、客观、更反映用户实际体验的评测生态。
➤投稿: @HaitunSubmit_bot
➤(若有)可能的撤稿事项,仅受理*原投稿人*。

讨论群: @haitunspeed
频道: @haitun_channel
📢 Sharon CDN HK & JP Photon 系列正式上线!

🚀 香港、日本同步首发,主打大陆优化!

极致低延迟:三网直连 (163pp/4837/58453),为大陆访问优化。
100Gbps 大带宽:独享高速带宽,轻松应对大流量。
企业级安全防护:高标准安全策略,业务无忧。
EPYC 高性能硬件:保证业务高负载持续稳定运行。

💰 价格低至 $10/月
👉 CDN官网: https://cdn.sharon.io
💬 官方群组: https://t.me/SharonNetwork
📢 官方频道: https://t.me/SharonNotice
适合富哥、富婆的《梦中情“由”》终于问世了!

华硕 ROG 今天在国内市场推出八爪鱼 7 AI 电竞路由器,主打未来机甲风外观和旗舰级配置,售价 ¥6999 。

10 月 24 日,开启新品预约

11 月 14 日,正式发售


搭载博通四核 2.6GHz CPU,配合 4GB DDR4 内存和 32GB eMMC 闪存,内置 NPU 神经网络引擎,算力可达 7.9 TOPS,为 AI 功能和高速网络传输提供强劲算力支持。

网络方面,双万兆网口,有线传输高达 31Gbps,无线传输高达 13 Gbps。

支持 Docker 容器,支持微服务、数据分析、自动化等特性,为开发者提供更大的开发灵活性,还适配 HomeAssistant 开源智能家居自动化平台,整合各种平台的智能家居,轻松管理 IoT 设备。
海豚机场测评|用户侧体验|测速频道
对比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
Back to Top