简述 XTLS 相关协议

vless

请求格式为：

ProtoBuf 请求为：

message Addons {
  string Flow = 1;
  bytes Seed = 2;
}

分析该设计：

Xray 对 UUID 使用了 ReadFull，这意味着 VLESS 可能并没有与 Trojan 相同的探测保护，向其发送 1+15 字节后停止，服务器长时间等待将会成为特征。 编辑：由于代码紊乱，没有发现外部再次处理了。

对于其想新增的字符串参数，开创性地使用了被 V2Ray 滥用的应用层协议 ProtoBuf 格式 ，这样独特的行为可能会让其他开发者误会，对他的专业性产生怀疑。

编辑：本来以为如此胡乱设计肯定难以启齿，但经他提醒，他甚至为此夸赞了一番

他称使用 ProtoBuf 是 “创举”，然而所谓的 “Tag Length Value” 只不过是在数据前增加一个长度， 他称 “本来打算自己设计，接着发觉 ProtoBuf 就是此结构、现成的轮子，完全适合用来做这件事，各语言支持等也不错。”，可以证明他缺乏二进制数据结构相关经验，作为协议一部分的 flow 常量字段不使用 uint8 而使用字符串，不使用 byte + string，而

对于地址格式，直接使用了 VMess 的意义不明格式（该格式修改了表示 address type 的字节，并且将端口移动到地址之前），而不是 Trojan 使用的标准 socksaddr。

至于什么兼容性，能做到在 patch release 中 break 协议的项目应该也不在乎这些。

UDP FullCone

由于 V2Ray 项目原作者对 TCP/IP 的理解水平不足，V2Ray 中将 UDP 与 TCP 连接混为一谈，导致其在 UDP 传输上的设计存在严重缺陷，而其他项目根本不存在这个问题。

而 VLESS 的设计直接沿用了 VMess 的 UDP 包不带地址的设计，这意味着他可以设计一个新的 “协议” 来修复这点。

修改 v2ray 的 mux.cool 私有多路服用协议并取了一个易于宣传的名字作为私有协议，也是出于类商业运营考虑，因为这样可以即不打破与原始 VMess 协议的兼容性又可以从上游而吸引更多用户。

回落

即使目前没有证据证明 GFW 会主动发起 HTTP 访问请求并根据回应来执行封锁，自欺欺人伪装界面仍然能吸引到许多缺乏相关知识的用户。

原始 XTLS

现在我们知道该协议一开始就有可以被识别的问题。

但在最初 naiveproxy 作者指出这点时，他的回复是 “不可能，你看代码了吗？“，直到两年后，klzgrad 指出的两个设计问题都被证明，他也没有正面回应，而是直接废弃了该协议。

XTLS vision

这协议实现复杂，实际作用除了延续其广受好评的为了 “高性能“ 创造特征外，还为连接头部的数据添加了填充。

该作者也找了许多其他开发者询问意见，然而：

根据这项尚未发表的研究，连接头填充在它们自制的 TLS in crypto 识别模型不能起到有效的作用，而多路复用的协议能起到一定混淆流量特征的作用。 换句话说，该协议不仅复杂且未定义，而且对于反审查目的也毫无意义。

我要指出的是，这项研究没有涉及现实世界的 GFW 行为，且没有证据证明 GFW 应用了此类机器学习识别。 考虑此类模型在误报率与性能，要想大规模部署都还需要很长时间。

对于 TLS 代理，naiveproxy 在 2018 年就实现了多路复用、连接头部填充、使用 chromium 作为 TLS 实现。而此后再也没有真正意义上设计优于它的 TLS proxy 项目。

Go 程序语言编写的 TLS 代理即使使用了 uTLS 这样伪装 TLS 指纹的库，也有报告其仍然被伊朗防火墙识别并封锁了。

reality

跟随与发布于二月 19 日的 shadow-tls v3，Xray 与三月 9 日发布了 Xray 1.8.0 (pre-release)。

该协议与 shadow-tls 都有报告已被伊朗防火墙识别并封锁了。

即使作者自称在两年前就发明了这个协议，但也无法解释为什么在 shadow-tls 发布后的六个月才发布第一个版本，有趣的是，其自称文档和定义已经写好了 明天就发。