2021-05-26 11:05:53 +00:00
|
|
|
|
# VLESS 协议
|
|
|
|
|
|
|
|
|
|
VLESS 是一个无状态的轻量传输协议,可以作为 Xray 客户端和服务器之间的桥梁。
|
|
|
|
|
|
2022-12-24 05:06:47 +00:00
|
|
|
|
## Request & Response
|
|
|
|
|
|
2022-12-26 17:15:46 +00:00
|
|
|
|
| 1 字节 | 16 字节 | 1 字节 | M 字节 | 1 字节 | 2 字节 | 1 字节 | S 字节 | X 字节 |
|
|
|
|
|
| -------- | --------- | -------------- | ----------------- | ------ | ------ | -------- | ------ | -------- |
|
|
|
|
|
| 协议版本 | 等价 UUID | 附加信息长度 M | 附加信息 ProtoBuf | 指令 | 端口 | 地址类型 | 地址 | 请求数据 |
|
2022-12-24 05:06:47 +00:00
|
|
|
|
|
2022-12-26 17:15:46 +00:00
|
|
|
|
| 1 字节 | 1 字节 | N 字节 | Y 字节 |
|
|
|
|
|
| ---------------------- | -------------- | ----------------- | -------- |
|
|
|
|
|
| 协议版本,与请求的一致 | 附加信息长度 N | 附加信息 ProtoBuf | 响应数据 |
|
2022-12-24 05:06:47 +00:00
|
|
|
|
|
|
|
|
|
VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了(BETA 是第五个测试版):
|
|
|
|
|
|
|
|
|
|
> “响应认证”被替换为“协议版本”并移至最前,使 VLESS 可以升级换代,同时消除了生成伪随机数的开销。混淆相关结构被替换为附加信息(ProtoBuf)并前移,赋予协议本身可扩展性,相关开销也极小([gogo/protobuf](https://github.com/gogo/protobuf)),若无附加信息则无相关开销。
|
|
|
|
|
|
|
|
|
|
我一直觉得“响应认证”不是必要的,ALPHA 时为了提升生成随机数的性能,还用 math/rand 替换 crypto/rand,而现在都不需要了。
|
|
|
|
|
|
|
|
|
|
“协议版本”不仅能起到“响应认证”的作用,还赋予了 VLESS 无痛升级协议结构的能力,带来无限的可能性。
|
|
|
|
|
“协议版本”在测试版本中均为 0,正式版本中为 1,以后若有不兼容的协议结构变更则应升级版本。
|
|
|
|
|
|
|
|
|
|
VLESS 服务端的设计是 switch version,即同时支持所有 VLESS 版本。若需要升级协议版本(可能到不了这一步),推荐的做法是服务端提前一个月支持,一个月后再改客户端。VMess 请求也有协议版本,但它的认证信息在外面,指令部分则高度耦合且有固定加密,导致里面的协议版本毫无意义,服务端也没有进行判断,响应则没有协议版本。Trojan 的协议结构中没有协议版本。
|
|
|
|
|
|
|
|
|
|
接下来是 UUID,我本来觉得 16 字节有点长,曾经考虑过缩短它,但后来看到 Trojan 用了 56 个可打印字符(56 字节),就彻底打消了这个念头。服务端每次都要验证 UUID,所以性能也很重要:VLESS 的 Validator 经历了多次重构/升级,相较于 VMess,它十分简洁且耗资源很少,可以同时支持非常多的用户,性能也十分强悍,验证速度极快(sync.Map)。API 动态增删用户则更高效顺滑。
|
|
|
|
|
https://github.com/XTLS/Xray-core/issues/158
|
|
|
|
|
|
|
|
|
|
引入 ProtoBuf 是一个创举,等下会详细讲解。“指令”到“地址”的结构目前与 VMess 完全相同,同样支持 Mux。
|
|
|
|
|
|
|
|
|
|
总体上,ALPHA 2 到 BETA 主要是:结构进化、清理整合、性能提升、更加完善。这些都是一点一滴的,详见 [VLESS Changes](https://github.com/rprx/v2ray-vless/releases)。
|
|
|
|
|
|
|
|
|
|
## ProtoBuf
|
|
|
|
|
|
|
|
|
|
似乎只有 VLESS 可选内嵌 ProtoBuf,它是一种数据交换格式,信息被紧密编码成二进制,TLV 结构(Tag Length Value)。
|
|
|
|
|
|
|
|
|
|
起因是我看到一篇文章称 SS 有一些缺点,如没有设计错误回报机制,客户端没办法根据不同的错误采取进一步的动作。
|
2022-12-26 17:15:46 +00:00
|
|
|
|
(但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。)
|
2022-12-24 05:06:47 +00:00
|
|
|
|
于是想到一个可扩展的结构是很重要的,未来它也可以承载如动态端口指令。不止响应,请求也需要类似的结构。
|
|
|
|
|
本来打算自己设计 TLV,接着发觉 ProtoBuf 就是此结构、现成的轮子,完全适合用来做这件事,各语言支持等也不错。
|
|
|
|
|
|
|
|
|
|
目前“附加信息”只有 Scheduler 和 SchedulerV,它们是 MessName 和 MessSeed 的替代者,**当你不需要它们时,“附加信息长度”为 0,也就不会有 ProtoBuf 序列化/反序列化的开销**。其实我更愿意称这个过程为“拼接”,因为 pb 实际原理上也只是这么做而已,相关开销极小。拼接后的 bytes 十分紧凑,和 ALPHA 的方案相差无几,有兴趣的可以分别输出并对比。
|
|
|
|
|
|
|
|
|
|
为了指示对附加信息(Addons,也可以理解成插件,以后可以有很多个插件)的不同支持程度,下个测试版会在“附加信息长度”前新增“附加信息版本”。256 - 1 = 255 字节是够用且合理的(65535 就太多了,还可能有人恶意填充),现有的只用了十分之一,以后也不会同时有那么多附加信息,且大多数情况下是完全没有附加信息的。真不够用的话,可以升级 VLESS 版本。
|
|
|
|
|
|
|
|
|
|
为了减少逻辑判断等开销,暂定 Addons 不使用多级结构。一个月前出现过“可变协议格式”的想法,pb 是可以做到打乱顺序,但没必要,因为现代加密的设计不会让旁观者看出两次传输的头部相同。
|
|
|
|
|
|
|
|
|
|
下面介绍 Schedulers 和 Encryption 的构想,**它们都是可选的**,一个应对流量时序特征问题,一个应对密码学上的问题。
|
|
|
|
|
|
|
|
|
|
## ~~Schedulers~~ Flow
|
|
|
|
|
|
|
|
|
|
~~中文名暂称:流量调度器~~(2020-09-03 更新:中文名确定为“流控”),指令由 ProtoBuf 承载,控制的是数据部分。
|
|
|
|
|
|
|
|
|
|
我之前发现,VMess 原有的 shake “元数据混淆”在 TLS 上完全不会带来有意义的改变,只会降低性能,所以 VLESS 弃用了它。并且,“混淆”这个表述容易被误解成伪装,也弃用了。顺便一提,我一直是不看好伪装的:做不到完全一样,那不就是强特征吗?做得到完全一样,那为什么不直接用伪装目标?我一开始用的是 SSR,后来发现它只是表面伪装骗运营商,就再也没用过了。
|
|
|
|
|
|
|
|
|
|
那么,“流量调度器”要解决什么问题?它影响的是宏观流量时序特征,而不是微观特征,后者是加密要解决的事情。流量时序特征可以是协议带来的,比如 Socks5 over TLS 时的 Socks5 握手 ,TLS 上不同的这种特征对于监测者来说就是不同的协议,此时无限 Schedulers 就相当于无限协议(重新分配每次发送的数据量大小等)。流量时序特征也可以是行为带来的,比如访问 Google 首页时加载了多少文件、顺序、每个文件的大小,多套一层加密并不能有效掩盖这些信息。
|
|
|
|
|
|
|
|
|
|
Schedulers 没必要像下面的 Encryption 一样整个套在外面,因为头部的一丁点数据相对于后面的数据量来说太微不足道了。
|
|
|
|
|
|
|
|
|
|
BETA 2 预计推出两个初级的 Scheduler:Zstd 压缩、数据量动态扩充。进阶操作才是从宏观层面来控制、分配,暂时咕咕。
|
|
|
|
|
|
|
|
|
|
## Encryption
|
|
|
|
|
|
|
|
|
|
与 VMess 的高度耦合不同,VLESS 的服务端、客户端不久后可以提前约定好加密方式,仅在外面套一层加密。这有点类似于使用 TLS,不影响承载的任何数据,也可以理解成底层就是从 TLS 换成预设约定加密。相对于高度耦合,这种方式更合理且灵活:一种加密方式出了安全性问题,直接扔掉并换用其它的就行了,十分方便。VLESS 服务端还会允许不同的加密方式共存。
|
|
|
|
|
|
|
|
|
|
对比 VMess,VLESS 相当于把 security 换成 encryption,把 disableInsecureEncryption 换成 decryption,就解决了所有问题。目前 encryption 和 decryption 只接受 \"none\" 且不能留空(即使以后有连接安全性检查),详见 [VLESS 配置文档](https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md)。encryption 并不需要往外移一级,一是因为无法复用很多代码,二是因为会影响控制粒度,看未来的应用就明白了。
|
|
|
|
|
|
|
|
|
|
加密支持两类形式,一类是加密完全独立,需要额外密码,适合私用,另一类是结合已有的 UUID 来加密,适合公用。
|
|
|
|
|
(若用第一类加密形式,且密码是以某种形式公开的,比如多人共用,那么中间人攻击就不远了)
|
|
|
|
|
重新设计的动态端口可能会随加密同时推出,指令由 ProtoBuf 承载,具体实现和 VMess 的动态端口也会有很多不同。
|
|
|
|
|
|
|
|
|
|
套现成加密是件很简单的事情,也就多一层 writer & reader。BETA 3 预计支持 SS 的 aes-128-gcm 和 chacha20-ietf-poly1305:
|
|
|
|
|
客户端的 encryption 可以填 “auto: ss_aes-128-gcm_0_123456, ss_chacha20-ietf-poly1305_0_987654”,auto 会选择最适合当前机器的,0 代表测试版,最后的是密码。服务端的 decryption 也是类似填法,收到请求时会逐一尝试解密。
|
|
|
|
|
|
|
|
|
|
并不是所有组合都需逐一尝试:VMess 的加密分为三段,第一段是认证信息,结合了 UUID、alterId、时间因素,第二段是指令部分,以固定算法加密,指令中含有数据部分使用的加密算法,第三段才是重要的数据部分。可以看出,VMess 的加解密方式实际上是多对一(服务端适配),而不仅是结合 UUID。但仅是结合 UUID 来加密也是件相对麻烦的事情,短时间内不会出,鉴于我们现在有 VMessAEAD 可用,也并不着急。若 VLESS 推出了结合 UUID 的加密方式,相当于重构了整个 VMess。
|
|
|
|
|
|
|
|
|
|
## UDP issues
|
|
|
|
|
|
|
|
|
|
https://github.com/XTLS/Xray-core/discussions/252
|
|
|
|
|
|
|
|
|
|
## 客户端开发指引
|
|
|
|
|
|
|
|
|
|
1. VLESS 协议本身还会有不兼容升级,但客户端配置文件参数基本上是只增不减的。iOS 客户端的协议实现则需紧跟升级。
|
|
|
|
|
2. **视觉标准:UI 标识请统一用 VLESS**,而不是 VLess / Vless / vless,配置文件不受影响,代码内则顺其自然。
|
|
|
|
|
3. `encryption` 应做成输入框而不是选择框,新配置的默认值应为 `none`,若用户置空则应代填 `none`。
|
|
|
|
|
|
|
|
|
|
## VLESS 分享链接标准
|
|
|
|
|
|
|
|
|
|
感谢 <img src="https://avatars2.githubusercontent.com/u/7822648?s=32" width="32px" height="32px" alt="a"/> [@DuckSoft](https://github.com/DuckSoft) 的提案!
|
|
|
|
|
|
|
|
|
|
详情请见 [VMessAEAD / VLESS 分享链接标准提案](https://github.com/XTLS/Xray-core/issues/91)
|