4.0 KiB
vless v1 标准
本v1标准参考v0标准，并着重针对addon和udp部分进行了一些改动。原v0标准请参考
https://github.com/v2ray/v2ray-core/issues/2636
v1的讨论 可以参考 vless_v1_discussion
本文为实际确定的具体标准，与讨论是有所不同的，讨论是非正式的。大家以本文为标准依据。
响应包包头的修改
v1部分不再具有 v0中所定义的响应包头部分。tcp响应 直接就为承载数据，udp的话还是有特殊的定义，请看下文。
因为响应包没有包头，所以也不支持addon协商。如果服务端不支持某一addon 或者不支持v0/v1的话，应该无声地关闭底层连接，而不返回任何响应。
addon 含义修改
对比：v0的 addon第一字节为addon长度， 剩余为 addon内容
v1发生变化， addon 第一字节 为addon类型指示, 剩余内容为响应类型的具体数据.
0 为无addon 1 为 udp_multi 标志. 开启此标志后, udp使用分离信道方式传输. 2 为 【多addon】标志, 此时第二字节为 addon的数量, 然后 第三字节 为 第一个addon的类型指示, 之后是第一个addon的数据块（视addon类型而定, 比如 udp_multi标志就没有任何数据块），然后是第二个addon的类型指示，以此类推。
v1不再采用protobuf，因为我们不应受制于任何复杂外部实现. 我们应该自有结构。
vless v0的addon主要被xray用来自定义xtls流控，而因为本作作者已经发现xtls的漏洞并摒弃xtls，开发了lazy技术，所以也不会去继承xray的现有addon。
udp的 多路复用 与 分离信道
vless v1准备同时支持两种模式，【经典的 类socks5/trojan 的多路复用】的方式，以及【分离信道】的方式。
究竟使用哪一种由 客户端决定，服务端将同时支持二者。
客户端使用 addon 部分来标识。
具体请看下文
udp包头确定
vless 的v0 始终处于beta中，而且 【udp长度】的包头仅仅在 commit中所提及，根本没写在该beta 文档里
本作定义的 v1 对vless 的udp包头进行完整定义。
在经典传输时，每一个udp数据报 都采用如下格式 第 1、2字节 为 port。第3字节为 atype，然后是变长的addr内容，定义与tcp的握手的包头一致。接着是udp数据包长度的2字节，然后是承载数据。
在 分离信道传输时，
一，客户端发送的格式: 首个客户端握手包的握手部分采用与tcp相同的格式
接着是udp数据包，前两字节为数据长度的2字节，然后是承载数据。
二，服务端发送的格式：
因为我们服务端发往 客户端的方向 有时需要传输 UMFURS 信息，所以我们需要一字节来指示本次数据包的意义。
第一字节为数据包意义指示，
0标识 普通 来自原始raddr的数据包，此时 第二字节和第三字节为数据长度，然后跟着数据；
1标识 UMFURS 数据, 此时，第 2、3字节 为 port。第4字节为 atype，然后是变长的addr内容，定义与tcp的握手的包头一致。接着是udp数据包长度的2字节，然后是承载数据。
其他情况
传输在websocket之上的情况
之前还讨论过 在使用ws时免除udp长度信息的计划 而且同样作为高级层，grpc和quic因为传输的是流, 不满足包的特征，是无法免去长度信息的。
仔细思考, 免除udp长度信息主要是为了避免读取端 进行额外缓存, 减少读取端的拷贝
但是, 一旦实施的话，实际上会增加 发送端的 buf, 发送端需要一次额外拷贝到buf中, 再整体一起写入 websocket, 所以实际上 如果 把 【发送端和接收端】 作为一个 整体 来考虑的话, 该计划并没有减少任何 内存拷贝, 而且还增加了代码复杂度。
因此，讨论中的 免除udp长度信息的计划 不切实际，不予支持。
而且, v1的分离信道方式还是要先读取一字节, 所以还是要缓存, 所以完全没必要。