|
|
发表于 2023-12-24 14:01:43
|
显示全部楼层
作者貌似修改文章承认自己不足了：
由于我的 Blog 原始文件托管在 GitHub pages 上，推送到个人仓库后上一篇文章立即被相关人士扩散并引发争议，并被指出内容存在错误。
事后，我与该作者进行了交流，也重新分析了相关协议，所以我在这里分享我的改正的对 VLESS 协议的新的理解。
由于有好事者盯着我的个人仓库看，我已经将其转为 private，且也不会删除上一篇文章，留作参考。
我上一篇文章写：
Xray 对 UUID 使用了 ReadFull，这意味着 VLESS 可能并没有与 Trojan 相同的探测保护，向其发送 1+15
字节后停止，服务器长时间等待将会成为特征。
但这是错误的，由于我简易检查时忽略了 Xray 代码的复杂度，没有发现外部再次嵌套了缓冲区再次进行了处理，这也是他在频道中唯一反驳我的。
关于 VLESS 的设计，我曾以为如此设计必然不会主动宣传，然而我确实在文档中发现了作者对此的解释。
version
“协议版本”不仅能起到“响应认证”的作用，还赋予了 VLESS 无痛升级协议结构的能力，带来无限的可能性。 “协议版本”在测试版本中均为 0，正式版本中为 1，以后若有不兼容的协议结构变更则应升级版本。
VLESS 服务端的设计是 switch version，即同时支持所有 VLESS 版本。若需要升级协议版本（可能到不了这一步），推荐的做法是服务端提前一个月支持，一个月后再改客户端。VMess 请求也有协议版本，但它的认证信息在外面，指令部分则高度耦合且有固定加密，导致里面的协议版本毫无意义，服务端也没有进行判断，响应则没有协议版本。Trojan 的协议结构中没有协议版本。
总结：VLESS 具有无痛升级协议结构的能力、无限的可能性、同时支持所有版本；VMess 请求也有协议版本，但毫无意义；Trojan 的协议结构中没有协议版本。 |
|
[复制链接]
楼主
