《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 #延迟 #专线 #协议
