[Feature Request] 更详细的方案：非可信通路 与 可信通路（VMore and VLess），含 VLess 具体设计方案

[RPRX]

2020-07-17 更新：

[New Protocol] VLESS BETA：性能至上、可扩展性空前，目标是全场景终极协议。

2020-06-20 更新：

[New Protocol] VLESS ALPHA

---

经过在 v2ray/v2ray-core#2526 中的讨论，我告诉 @ActiveIce 应该重新开一个 issue，于是他在 v2ray/v2ray-core#2541 中描述了一个方案，但我觉得将 VMess 的实现解耦掉各种 HASH、加密部分并不容易，会增大难度、延长 VMess 2 的设计时间，尤其是可能会带来新的未知问题。所以，基于种种考虑，我更倾向于下一步分为专攻两个方向的两个协议。由于这和一个协议解决所有问题有根本区别，所以我开了这个 issue。

首先，我并不希望这是一轮大规模重构，那样太麻烦且设计周期很长。我倾向于这两个新协议就只是两个新协议而已，要能复用 v2ray 的现有架构、其它组件，也就是说基础架构无需做任何变动。

请允许我引入一些自己想出来的概念：

经过思考，我觉得我们对 v2ray 的使用可以分为两种情况，即 非可信通路 与 可信通路，而没有半可信通路。比如，一般来说内网可以算作可信通路，而公网则算作非可信通路，但这两种情况并不是绝对的，通路可以互相转化。我举个例子，公网虽然是非可信通路，但基于 TLS 后可以变为可信通路，而如果途经 CDN，则又变回非可信通路。内网若不受自己控制，则不应算作可信通路，而应算作非可信通路。

---

那么，非可信通路 与 可信通路，各对应一种协议：VMore and VLess（就这么命名吧）

具体而言，专用于非可信通路的 VMore 是含 AEAD 加密和其它改进的 强化版 VMess，注重安全。

而专用于可信通路的 VLess 是无需任何 HASH、加密等多余计算的 阉割版 VMess，注重性能。

同时，这两个协议都应该支持可无限扩展的混淆方案（改变流量时序特征），等下我会详细描述。

对于 VMore 的具体设计，我个人并没有太多想法，只是认为这应该是一个相对整体的安全方案，而且觉得这可能是一个长期工程。建议多参考一些其它地方已有的最佳实践（而不是闭门造车），以及参考 https://github.com/v2ray/discussion/issues/711

对于 VLess 的具体想法，其实我已经在 v2ray/v2ray-core#2526 中描述过了，只是现在不是非要基于 TLS，如内网用途，这也是我想出可信通路、通路转化那些概念的原因 —— 现在的定位更明确：专用于可信通路，性能 MAX。

由于去掉了各种 HASH、加密等多余计算部分、支持关闭混淆，VLess 的性能将会比现在的 VMess 更强（即使后者加密选 none）。但 VLess 并非完全不 Mess，相反地，它的混淆方案更强大：支持无限扩展、随机选择、每次请求随机选择。

---

下面我将详细说一下 VLess 的具体设计，我想我们现在就需要它（鉴于 VMore 一时半会儿出不来）。由于主要是阉割，实现起来不难，熟悉 VMess 代码的大佬应该很快就可以完成。

参考：https://www.v2fly.org/developer/protocols/vmess.html

但由于这个文档有些地方有歧义（如现混淆方案 Shake 的参数），我还看了 VMess 的部分代码。

因为是用于可信通路，所以是明文、去掉所有加密，也没有系统时间相差要求等。 保持无状态，保留鉴权、兼容现有的路由、统计、底层传输方式等，不另起炉灶。 为 TLS 穿墙准备了可无限扩展的混淆方案，但其它用途无需开启，也不占地方。

客户端：

1. 认证信息无需 HMAC，只留 UUID，不要 MD5、UTC 时间。

2. 指令部分去掉 AES-128-CFB 加密，只留响应认证、指令、端口、地址类型、地址，其它全部不要。

3. 配置文件中新增“混淆方案”选项（把现方案改成可扩展形式），默认 none 不开启，填 auto 是随机选择一种混淆方案，rand 是每次请求随机选择，shake 则是现方案（参数改为后面提到的随机值）。指令部分结尾添加一个1字节的“混淆方案名称长度”，如5，接着是混淆方案具体名称 shake。有混淆方案时，继续添加一个1字节的“附加数据长度”，如16，接着是一个16字节的随机值。

4. 数据部分为“标准格式”，且没有加密。是否混淆、混淆方案取决于配置文件。 不混淆时，数据部分不采用“标准格式”，即不分割为若干小块，同时也不需要小块校验。

服务端：

1. 配置文件中新增“是否必须混淆”选项，默认 false 不强制，填 true 则客户端必须选择一种混淆方案，否则断开连接。请求到达时，若服务端没有请求中的混淆方案或无法成功解除混淆，则断开连接。

2. 应答头部数据去掉 AES-128-CFB 加密，只留响应认证，不要选项、指令部分。

3. 应答头部数据结尾添加一个1字节的“混淆方案名称长度”...（结构与前文相同）

4. 实际应答数据同样为“标准格式”，且没有加密。是否混淆、混淆方案和客户端的请求一致。 不混淆时，数据部分不采用“标准格式”，即不分割为若干小块，同时也不需要小块校验。

可能：所有混淆相关结构均移至最前，当选择了混淆方案时，后面所有数据均参与混淆（包括头部）

---

这样一来和 trojan 相比有什么主要区别？

0. 理论上来说，不开混淆时，VLess + TLS 速度可以追平 trojan（那么 trojan 就很尴尬了） WS 的 Base64 编码会使数据量膨胀 33% 左右，所以要么压缩，要么推荐其它长连接方式
1. VLess 不强制 TLS，且可以复用 v2ray 已有的其它组件（路由、DNS、统计、API等），适用范围更广。
2. 有强大的可无限扩展的混淆方案，还支持随机选择、每次请求随机选择。
3. 可以插一层 WebSocket/H2/QUIC 等 v2ray 已有、将有的底层传输方式。
4. 服务端可以由 nginx 处理 tls 并路径分流。（trojan 只能由 nginx 的 stream 段预读取 sni 来转发）
5. 当 v2ray 出现了新的 TLS 指纹解决方案时，可以直接拿来用。https://github.com/v2ray/discussion/issues/706
6. 如果你觉得 CDN 是可信通路，那么可以套 CDN。
7. （并不是很重要）trojan 只支持 socks5，而 v2ray 支持多种入站方式。

欢迎提出改进意见，也希望项目组给予反馈。

[rayc345]

既然已经是在可信通道上了为什么还需要混淆等内容，直接SOCKS5性能不应该更好吗？没有加密和验证却又混淆功能之间也并没有匹配。 混淆是为了防止流量审查者识别协议后封禁服务器，加密与数据校验是为了数据机密性、阻止审查者篡改数据探测。 所以不存在需要混淆而不需要加密的情况。

[henrypijames]

If you're already naming one protocol VLess, then the other - VMess 2 - should naturally be renamed VMore. It's so obvious, how could you miss it?

[henrypijames]

既然已经是在可信通道上了为什么还需要混淆等内容

Trusted doesn't mean unrestrained. Obfuscation can be used against restraint - think NAT firewall.

所以不存在需要混淆而不需要加密的情况。

Again, a NAT firewall is just such a case: Most of them don't attack your traffic (trying to read or even manipulate the data flow), but they do filtering. Obfuscation can help with that.

[RPRX]

既然已经是在可信通道上了为什么还需要混淆等内容，直接SOCKS5性能不应该更好吗？没有加密和验证却又混淆功能之间也并没有匹配。 混淆是为了防止流量审查者识别协议后封禁服务器，加密与数据校验是为了数据机密性、阻止审查者篡改数据探测。 所以不存在需要混淆而不需要加密的情况。

1.Socks5 本身并没有融入 v2ray 的体系，如 UUID、邮箱（流量统计）等，最重要的是：没有混淆 2.我说的是“为 TLS 穿墙准备了可无限扩展的混淆方案”，为了“改变流量时序特征” 3.“但其它用途无需开启，也不占地方”，比如可信通路的内网

请注意 VLess 是“专用于可信通路”，也就是说要么安全（如自家内网），要么已有 TLS

[RPRX]

If you're already naming one protocol VLess, then the other - VMess 2 - should naturally be renamed VMore. It's so obvious, how could you miss it?

似乎的确是这样

不过，其实是先有 VMess 2 的命名，再有 VLess 的命名 但就两个协议来说，相对于 VMess 2，VMore 这个命名的确更好

[darhwa]

Too much cheap talk. Where is your code?

[xiaokangwang]

目前来看VMess的目标是首先开发一个没有已知重放+主动探测弱点的协议。我已经看到了你们的讨论，会在未来参考这里的讨论来进一步改进V2Ray。请大家继续讨论，我会在之后发布一些和你们的讨论有关的思考和构想。

[xiaokangwang]

Too much cheap talk. Where is your code?

我认为更多的讨论也是必要的，请大家继续讨论，我在下一步开发的时候可能会考虑大家的想法。

[RPRX]

@xiaokangwang

个人认为，无论哪种协议，可无限扩展的混淆方案都是有必要的，希望出现在新协议的设计中。

然后是性能，由于现在很多人结合 TLS 使用，那么协议自带的 HASH、加密等为密码学上的安全而设计的这些东西应该是可以关闭的（如果能完美解耦到这种程度当然更好，就不需要分成两个协议了），这样在性能上就不输 trojan 了，再加上可选可扩展的混淆、v2ray 原有的其它功能，综合下来将空前强大。

[Kylejustknows]

层主的想法，有一定的作用，但我感觉并不是必需。

他是想弄一个： 无加密但也无特征的数据流，主打速度快，用来服务器内部使用，或者外套其他加密TLS等使用（只要数据不直接经过防火墙，就优先使用这个不加密的数据流） 能够解决一个问题：现在Vmess+ws+tls之类的伪装，整个过程数据流经过了多次重复加密，浪费了CPU。

然后楼上的增加的想法是， 弄一个原始数据流，然后用户可以选择套上某混淆方案，然后用户还可以选择套上加密方案。

然后，总结到这，这听起来就挺像ShadowSock了。（SS的数据流，用户可以自行设置加密选项和添加混淆插件和算法）

我个人感觉，因为v2ray并不是免费冒出来的，志愿者们编程的时间和精力都是有限的资源。以上的方案实现起来都需要大面积重新开发，不太符合现在的情况 （当然如果有组织提供充足资金我们可以有v2ray全职程序员，可以往这条路上走）。我个人建议现在，集中有限的资源和知识，更新一个vmess2协议，原位替换现在的vmess部分最现实（当然vmess2代码如果隐秘的同时能优化得比vmess1更快那就更好了）

[RPRX]

然后楼上的增加的想法是， 弄一个原始数据流，然后用户可以选择套上某混淆方案，然后用户还可以选择套上加密方案。

可无限扩展的混淆方案并不是“楼上增加的想法”，是一开始就有的想法。

但至于“选择套上加密方案”，这些要完美设计在一个协议里，确实是没那么简单的，要考虑的情况太多了。但如果分成两个协议，却不会很难，比如我提出的 VLess，其实只需要对现有的 VMess 代码删删删，再把它的 Shake 混淆方案改成可无限扩展的形式，一天之内就可以完成。

他是想弄一个： 无加密但也无特征的数据流，主打速度快，用来服务器内部使用，或者外套其他加密TLS等使用（只要数据不直接经过防火墙，就优先使用这个不加密的数据流）

这句话应该把“无特征”去掉，如果是 VLess 的话，最多也只是拥有混淆方案，做不到无特征。 （而且服务器内部使用之类的也不需要无特征啊）

[Kylejustknows]

“选择套上加密方案”，这些要完美设计在一个协议里，确实是没那么简单的

其实，现在用的vmess就是客户端和服务器握手后沟通一个加密方式。( 可选AES-128-CFB，AES-128-GCM，ChaCha20-Poly1305 或者 不加密） 其中的“不加密” 选项，就几乎是你说的VLess（有混淆和身份验证，但没有加密过程）

但多数情况，加密并不是拖慢V2Ray网络速度的瓶颈（2020年的主机，很少V2Ray的CPU跑满）。。。具体原因一句话两句话说不完。

还是先专心攻克vmess2（或者你说的VMore）吧，如果能集思广益，绕过所有的坑，抵挡住所有的嗅探做出一个极其robust的协议，然后再在vmess2使用的新技术允许的情况下，加入握手时双方沟通“不加密”，“不混淆”，甚至“不验证”的高速选项，似乎可以在不改动现有框架的情况下完成。（我自己并没有读过V2ray的代码，以上是我的个人拙见）

[RPRX]

凌晨好，其实我是看完了协议文档和部分 VMess 代码才写出了 VLess 具体可行的设计方案。

其实，现在用的vmess就是客户端和服务器握手后沟通一个加密方式。

错误。VMess 是无状态协议，没有握手。数据段的加密方式是直接写在请求头里的。 无需看代码，文档就交代得很清楚：https://www.v2fly.org/developer/protocols/vmess.html

其中的“不加密” 选项，就几乎是你说的VLess（有混淆和身份验证，但没有加密过程）

半对。即使选了“不加密”，也只是数据段。请求和响应的头部仍然会使用 AES-128-CFB 加密。 其中请求头部的认证信息，是 HMAC(MD5, 用户 ID, UTC 时间某值)，这也是没有必要的。 更具体的你可以看一下文档，请求和响应头部有很多不必要的字段、HASH、加密、验证等。

以及，VMess 不仅不能手动关闭混淆（至少现在没有这个配置项），还没有预留可无限扩展的混淆方案空间。另外它的“响应认证”只有1字节，也就是说8位、2的8次方256，大并发下可能会产生冲突，所以 VLess 改成了2字节65536。我的意思是，VLess 不止是阉割 VMess。

但多数情况，加密并不是拖慢V2Ray网络速度的瓶颈（2020年的主机，很少V2Ray的CPU跑满）。。。具体原因一句话两句话说不完。

这要看对比，有人仅因为速度快一些就选择 trojan。

加入握手时双方沟通“不加密”，“不混淆”，甚至“不验证”的高速选项

还是：没有握手。其次，要在一个协议中做到这样，会引入很多新问题，如主动探测漏洞的卷土重来。 所以我更倾向于分为专攻两个方向的两个协议。其中 VMore 比较复杂，交给项目组大佬们。

而 VLess 真的很简单，如果确定需要的话，我一个人就可以很快完成。

[Kylejustknows]

而 VLess 真的很简单，如果确定需要的话，我一个人就可以很快完成。

你说的简单，是指这个协议的简单；我说的简单，是指无缝融入现有框架的简单；加一个新协议，支持双协议，需要改动的地方太多了；我上文说的握手，其实想说的是v2的authentication过程，您包含一下 👍

我个人觉得，Vless没有必要，因为 1，只要有混淆，双方就要有解开+去掉混淆的算法，而这个算法往往是没有硬件加速的（而加密协议往往有硬件加速），相对等等等等过程来说, 加密占用的系统资源其实很小。 2，V2ray的“慢”，真心不是加密这个步骤引发的（加密步骤，没有在各个层面上拖慢v2ray的速度）。哪怕把vmess协议去掉加密和混淆，v2ray+caddy+ws+tls还是要比trojan慢。怎么说呢，一台100000元顶配的家用电脑，通用性很强，但挖比特币比不过1000元的专用挖矿机。

---

我更希望的是，Vmess做好Vmess，做接口，然后把websocket, h2 等“壳”的任务，分拆出去，让其他开发者在不用读懂核心代码的情况下，很容易做出“壳”的插件出来。（而不是把这些伪装任务都加给v2ray的开发者）

将来我们可以有，翻墙模拟成ftp同时上传下载大的zip文件，翻墙模拟成用utorrent上传下载某个电影，翻墙看起来像是在用微软RDP远程桌面，等等等等这样的百花齐放的插件，才是墙最头疼的。

[RPRX]

@Kylejustknows

其实我觉得你在发言前似乎总是没有先仔细看完我发的 issue，以及，的确应该先看下代码（无恶意）

你说的简单，是指这个协议的简单；我说的简单，是指无缝融入现有框架的简单；加一个新协议，支持双协议，需要改动的地方太多了；

这个协议本身简单，融入框架则更简单。请你看一下 v2ray-core/proxy 文件夹，十分清晰有序。 反过来说，如果加两个新协议就要大改框架，那 v2ray-core 的代码可以被称之为____。

只要有混淆，双方就要有解开+去掉混淆的算法，而这个算法往往是没有硬件加速的（而加密协议往往有硬件加速），相对等等等等过程来说, 加密占用的系统资源其实很小。

混淆只是添加随机数据，绝对不会比加密慢（即使 AES 有硬件加速），复杂度根本不是一个量级的。

V2ray的“慢”，真心不是加密这个步骤引发的（加密步骤，没有在各个层面上拖慢v2ray的速度）。哪怕把vmess协议去掉加密和混淆，v2ray+caddy+ws+tls还是要比trojan慢。怎么说呢，一台100000元顶配的家用电脑，通用性很强，但挖比特币比不过1000元的专用挖矿机。

我不知道你是怎样得出这个结论的，VMess + WSS 只是加密选 none 就会快很多 https://github.com/v2ray/discussion/issues/686 至于为什么加密选 none 后还比 trojan 慢，如我所说：关不了混淆、请求和响应头有太多不必要的东西

trojan 只是没有做多余的工作而已，并不是神仙，而 VLess 正是要实现这一目标，所以有必要。 而且你这样对比对 v2ray 不公平，至少也得去掉 caddy。另外，caddy 性能不如 nginx。

我更希望的是，Vmess做好Vmess，做接口，然后把websocket, h2 等“壳”的任务，分拆出去，让其他开发者在不用读懂核心代码的情况下，很容易做出“壳”的插件出来。（而不是把这些伪装任务都加给v2ray的开发者）

现在的结构就是这样，还是先看一下代码吧。“壳”的插件指的是什么？伪装还是？

将来我们可以有，翻墙模拟成ftp同时上传下载大的zip文件，翻墙模拟成用utorrent上传下载某个电影，翻墙看起来像是在用微软RDP远程桌面，等等等等这样的百花齐放的插件，才是墙最头疼的。

想法不错，但如果不能完美伪装，就成了强特征。

[Kylejustknows]

VMess + WSS 只是加密选 none 就会快很多

你给的讨论里也说了，开不开TLS，CPU并没有明显变化， 所以那里头说的使用TLS的慢，其实不是慢在加密上！！！而是慢在tls握手上。。。

同时，这也印证了我说的Vmess协议内部的加密，开不开它对速度几乎没有影响（因为加密现在根本不是CPU的负担）

比trojan慢，是因为v2ray+ws所有数据需要经过网页服务器reverseproxy，所有数据都增加了网页服务器的地址验证和tls加解密，网页服务器还要应用一次代理规则过滤，然后数据再传送v2ray内部端口的过程。 而trojan在握手后，就是客户端-服务器直连。 所以Vless哪怕再精简，传输上还是要比trojan慢一截子，而且不会和现在的情况有太多区别。

“壳”的插件指的是什么？伪装还是？

是，指的是伪装 （不是混淆）。 我的想法是，v2ray做好vmess2协议的加解密、低特征，以及freedom之前的路由规则等。 然后把传输协议，比如websocket等从v2ray核心里分离出来。

用户需要用websocket，就下载一个websocket插件。用户需要用QUIC，就下载一个QUIC插件。同时把接口做得易用，支持和鼓励第三方制作更多传输插件。

原因是： 1，很多网络开发者，对自己专业的网络协议很懂行，但对v2ray不懂。如果能提供一个方法，让他们轻松地能把vmess数据，融入到他们熟悉的网络协议的数据段中，会有更多更专业、更难以识别的伪装传输冒出来。（比如，v2ray客户端模拟网页浏览器来链接v2ray+ws+tls的服务器，产生的特征，肯定要比“专业做网页浏览器”的开发者做出来的要粗糙；这也是naiveproxy的作者坚持网络部分使用chromium network stack的原因，他发现“真正的浏览器”握手tls+proxy，就是和第三方软件握手tls产生的统计特征不一样）

2，减轻V2ray的代码工作量，V2ray的核心开发者自己不需要学习和精通各种现在的、未来的传输协议，只要专心把一个强壮的vmess2协议和路由功能做好。

3，一个插件被嗅探被攻破了，作者被喝茶了，不影响其他插件和v2ray核心的正常运行。

[RPRX]

@Kylejustknows

如果我发了别的链接，也请先仔细看完。

你给的讨论里也说了，开不开TLS，CPU并没有明显变化，

请问你是在哪里看到这句话的？我为什么没有看到

所以那里头说的使用TLS的慢，其实不是慢在加密上！！！而是慢在tls握手上。。。

这都什么跟什么。用 WebSocket 的情况下，TLS 握手几分钟一次。且 1.3 已经优化，还可以 0RTT。

同时，这也印证了我说的Vmess协议内部的加密，开不开它对速度几乎没有影响（因为加密现在根本不是CPU的负担）

由于你说的第一句话是错的，所以这个推论也是错的。就算加密不是负担，也要时间。 而且我发的链接已经明确列出了 aes-128-gcm 和 none 的速度区别，为什么你还能说出这句话？

比trojan慢，是因为v2ray+ws所有数据需要经过网页服务器reverseproxy，所有数据都增加了网页服务器的地址验证和tls加解密，网页服务器还要应用一次代理规则过滤，然后数据再传送v2ray内部端口的过程。 而trojan在握手后，就是客户端-服务器直连。 所以Vless哪怕再精简，传输上还是要比trojan慢一截子，而且不会和现在的情况有太多区别。

我说了：“你这样对比对 v2ray 不公平，至少也得去掉 caddy。” 而且没有规定 v2ray 非要由 nginx/caddy 反代吧？只是它可以这样做。

然后把传输协议，比如websocket等从v2ray核心里分离出来。

传输协议都在 v2ray-core/transport/internet，也很整齐、可扩展

---

一般来说和我对话多轮的，要么是没有看清我说的话或理解错误，要么是专业知识的广度和深度积累不够，导致基本认知存在错误，请自查问题。

[Kylejustknows]

请问你是在哪里看到这句话的？我为什么没有看到

这是你发的链接中，统计结果里记录vmess开不开加密的对比部分。 其中，有不加密比较快的：605比831，564比745，199比212 也有加密以后比较快的：318比308， 550比507，215比195

要问为什么（为什么有时反而vmess开了加密更快？） 我只能说，误差比较大、没有统计意义、工作环境对它们的影响远远大于加密的影响。

文内也说了，CPU占用率几乎没变化，这说明加密的工作负担，并不是现在速度的瓶颈。

传输协议都在 v2ray-core/transport/internet，也很整齐、可扩展

1，有很多开发者，不愿意把自己的劳动成果，贡献到v2ray项目里。允许他人创作署名自己的插件，有激励作用。 2，没有提供易用的接口，在core/transport/里接手开发，需要先花费很多时间研究v2ray的其他部分代码。而如果提供了易用的接口和使用文档，第三方开发会容易很多。 当然，这些都是talkie talkie 。几年后，墙存不存在还不一定呢。

一般来说和我对话多轮的，要么是没有看清我说的话或理解错误，要么是专业知识的广度和深度积累不够，导致基本认知存在错误，请自查问题。

是的！我跟你说框架思路也很累，因为咱俩真的不是一个级别的。让在v2ray上一行一行贡献代码的开发者们来决定未来的路线吧，咱俩扯扯想法就行了。

[RPRX]

@Kylejustknows

你还是没有回答哪里有“开不开TLS，CPU并没有明显变化”

为什么有时反而vmess开了加密更快？

（已缓解的问题）https://github.com/v2ray/v2ray-core/issues/1257 https://www.v2fly.org/developer/protocols/vmess.html#标准格式

根源是 VMess 为了加密和混淆，将实际请求数据分割为若干个小块。即使加密选 none，还是要用这种结构（混淆），服务器需要校验完所有的小块（而这个校验算法之前甚至比硬件加密还慢），这是现在选 none 也不立竿见影的原因。而如果再不要混淆，完全可以不用分成小块、小块校验，速度会更快。

以及我说过：即使选 none，还是有很多不必要的字段、HASH、加密、验证等，都是可以被优化掉的。

误差比较大、没有统计意义、工作环境对它们的影响远远大于加密的影响。

有时候瓶颈的确不在加密，但不妨碍在设计时追求性能极限。

是的！我跟你说框架思路也很累，因为咱俩真的不是一个级别的。让在v2ray上一行一行贡献代码的开发者们来决定未来的路线吧，咱俩扯扯想法就行了。

我并没有对你的框架思路表达质疑，只是防止你认为 v2ray-core 没有可扩展性。 （因为你之前说“加一个新协议，支持双协议，需要改动的地方太多了；”）

[henrypijames]

@rprx @Kylejustknows As a neutral observer of your argument back and forth, I want to say:

"Encryption is not the (main) bottleneck" and "encryption is not maxing out the CPU" are absurd arguments for mandatory encryption, especially when it often lead to double and triple encryption in practice. Any waste is waste. I don't want V2 to occupy 1% CPU if it can do with 0.5%. This is not just theoretical or esthetic, either: I have more than one older computer on which V2 is one of the programs jamming up the systems at peak load.

That said, I have not seen a convincing argument (or even anything close to it) for why we need to split the protocol up into two versions. He who makes that suggestion must carry the burden of proof. V2 is already modular (though there's always room for improvement in this regard, of course), and we all want it to stay modular. Giving that, why is VLess simply achieved by using VMore and setting all parameters to their null-values?

[RPRX]

That said, I have not seen a convincing argument (or even anything close to it) for why we need to split the protocol up into two versions. He who makes that suggestion must carry the burden of proof. V2 is already modular (though there's always room for improvement in this regard, of course), and we all want it to stay modular. Giving that, why is VLess simply achieved by using VMore and setting all parameters to their null-values?

我来解释一下：因为强行融合会导致未知问题、很棘手的问题（其实在 issue 开头我就写了）。

比如，假设 VLess 没有一点多余（性能极限），而 VMore 全副武装没有漏洞（安全极限） 那么，如果要一个协议同时实现两者，有两个思路： 1.头部加一个不加密的字段来区分。但这会导致强特征，所以不可行。 2.由服务端来自动区分，这样看起来可行，但是会额外消耗 CPU 资源。

但额外消耗 CPU 不是最大的问题，最大的问题是 VLess 的不安全性传染给 VMore 了。 比如，VLess 没有任何防主动探测的机制，这个融合后的协议也有这个漏洞（因为含 VLess）。

而如果用其它策略融合，需进行未知的多余设计，但可以肯定的是 VLess 必然会失去它的性能极限。

[bhoppi]

这样如何：把VMess协议的加密去掉，并为streamSettings里的security项添加更多的加密方式，比如PSK加密，比如#2541 里提到的Noise Protocol，等等。这样，高性能的无加密VMess有了，TLS加密的VMess有了，需要其他简单的或相对可靠加密的VMess都可以有。而且这些加密方式也可以作用于SOCKS5/HTTP/SS等代理协议，用户根据需要自由选择，这也符合V2Ray的设计思路。

[RPRX]

这样如何：把VMess协议的加密去掉，并为streamSettings里的security项添加更多的加密方式，比如PSK加密，比如#2541 里提到的Noise Protocol，等等。这样，高性能的无加密VMess有了，TLS加密的VMess有了，需要其他简单的或相对可靠加密的VMess都可以有。而且这些加密方式也可以作用于SOCKS5/HTTP/SS等代理协议，用户根据需要自由选择，这也符合V2Ray的设计思路。

先把 VMess 变成 VLess，再通过协议以外的途径加密，这是一个值得探讨的思路。

只是存在以下问题： 1.正如前面我提到的，服务端区分加不加密要用未知的多余设计，VLess 必然会失去它的性能极限。 2.如何保证带了加密的 VLess 仍是“无状态”？也就是说可选的加密方式不能有握手这个流程。

两个协议同样符合 V2Ray 的设计思路。事实上，现在的 V2Ray 就已经有九种协议了，其中一种是 VMess，而 VMore 和 VLess 只是一个原位替换、一个新增而已，没有打算另起炉灶。 （在本 issue 的正文中，与 V2Ray 现有设计兼容的理念是贯穿始终的）

[bhoppi]

只是存在以下问题： 1.正如前面我提到的，服务端区分加不加密要用未知的多余设计，VLess 必然会失去它的性能极限。

服务端和客户端保持相同的配置即可，不需要作区分。

2.如何保证带了加密的 VLess 仍是“无状态”？也就是说可选的加密方式不能有握手这个流程。

自由组合么，一定会有符合要求的和不符合要求的，我们根据需求来选择即可。比如，如果需要高性能和便捷性，使用无握手的加密方式和VLess组合就是无状态的；如果更需要隐蔽性，使用TLS+WebSocket+VLess，TLS和WebSocket其实都会破坏VLess的无状态（都有握手），但这无可厚非，大家也都在用。

两个协议同样符合 V2Ray 的设计思路。事实上，现在的 V2Ray 就已经有九种协议了，其中一种是 VMess，而 VMore 和 VLess 只是一个原位替换、一个新增而已，没有打算另起炉灶。

我并不反对你对协议的改进思路，我只是觉得这个方案并不能覆盖所有的情形，所以提出一点对加密这块的更通用的想法。

[Kylejustknows]

Any waste is waste. I don't want V2 to occupy 1% CPU if it can do with 0.5%

There is an important fact in the play: we have very limited developer human resources, and we don't have major contributors. Currently, we tolerant the double or triple layers of encryption simply because it can be easily implemented.....

I would like our coders and mathematicians to spend their precious time and effort in making the "vmess2" stronger, instead of trying to save users maybe $0.05 monthly electricity bill.

[RPRX]

服务端和客户端保持相同的配置即可，不需要作区分。

区分加不加密只是往外转移了一层，仍要区分，这部分性能还是要损失的。

自由组合么，一定会有符合要求的和不符合要求的，我们根据需求来选择即可。比如，如果需要高性能和便捷性，使用无握手的加密方式和VLess组合就是无状态的；如果更需要隐蔽性，使用TLS+WebSocket+VLess，TLS和WebSocket其实都会破坏VLess的无状态（都有握手），但这无可厚非，大家也都在用。

你误解了，我指的是有些人想用比较纯粹的完全安全且无状态的 VMess，要确保能组合出来。

我并不反对你对协议的改进思路，我只是觉得这个方案并不能覆盖所有的情形，所以提出一点对加密这块的更通用的想法。

其实你的想法挺好的，但我觉得开发组现在一心只想先原地替换现在的 VMess，不会解耦到那种程度。这也是我想新增一个 VLess 作为补充的原因。

[henrypijames]

比如，假设 VLess 没有一点多余（性能极限），而 VMore 全副武装没有漏洞（安全极限）

Let's stop right there. Why does VLess need extreme performance? Who needs that?

I would never consider a "performance maximization" approach for something like V2. There is always a performance trade-off - I only oppose excess encryption because there is no trade-off (it brings additional cost with no additional benefit).

You're the one talking about user cases all the time. I don't think you have a user case for VLess (beyond maybe yourself, that is).

[henrypijames]

I would like our coders and mathematicians to spend their precious time and effort in making the "vmess2" stronger, instead of trying to save users maybe $0.05 monthly electricity bill.

And I'm telling you that I've had to kill V2 (along with other processes) on my computer to unfreeze the system - every now and then. So, no, it's not just about a bit higher power consumption - it's about being usable or not.

Currently, we tolerant the double or triple layers of encryption simply because it can be easily implemented.....

I understand that, and I accept it as fact-of-life. But now we're trying to design a new protocol. The entire purpose of this exercise is to come up with something that we previously haven't thought of yet. To start, we must throw away old baggage and begin with a clean slate. If, after looking for solutions and coming up short, we conclude that redundant encryption cannot be avoided with acceptable development cost, then I would accept that result, too. But to start by saying redundant encryption doesn't matter, without even looking at ways to reduce it is wrong - how do you even know it must cost more development hours before having tried it?

[henrypijames]

我指的是有些人想用比较纯粹的完全安全且无状态的 VMess，要确保能组合出来。

At this point, I've come to doubt that this is even possible. Being stateless means authenticating all the time, and that repeated authentication is extremely fruitful grounds for protocol profiling. Does anyone know any stateless protocol that does a decent job at obfuscation?

[RPRX]

比如，假设 VLess 没有一点多余（性能极限），而 VMore 全副武装没有漏洞（安全极限）

Let's stop right there. Why does VLess need extreme performance? Who needs that?

I would never consider a "performance maximization" approach for something like V2. There is always a performance trade-off - I only oppose excess encryption because there is no trade-off (it brings additional cost with no additional benefit).

You're the one talking about user cases all the time. I don't think you have a user case for VLess (beyond maybe yourself, that is).

的确有人仅因为追求性能就选择 trojan，我也喜欢高性能，但我不用 trojan，因为我不喜欢它的那些特性，比如不能套 CDN、不能由 Nginx 处理 TLS，更没有 v2ray 的其它工具。我想，当 v2ray 性能接近甚至追上 trojan 后，或者说推出一个主打性能的协议时，将会是更多人的首选（而不会选择其它工具），用的人多对 v2ray 的长期开发是有利的。况且，推出一个这样的协议其实并不难。

2020-06-07 追加：事实上，前段时间 v2ray 被爆出多项漏洞后，一些机场下架了全部的 v2ray 而只留 trojan，这是我不愿意看到的，我一点也不希望 v2ray 因此逐渐失去活力，我希望更多的人用它。

如果不追求性能极限，setting all parameters to their null-values，那么根据现在的 VMess，最多只能优化掉数据部分的额外计算，而请求头仍有多余的字段、HASH、加密、验证等，并不优雅。

---

作为一个有很多协议的网络工具，v2ray 如果缺少一个这样的协议是比较令人遗憾的（有 UUID、流量统计、可选混淆，Socks5 则没有这些）。这个协议推出后，相信大多数结合 TLS 使用 v2ray 的人都会切换到新协议上，并渐渐喜欢上这份纯粹。

鉴于这个新协议并不难实现，我现在甚至有点想先把它写出来，而不是讨论“我们是否需要它”。

[henrypijames]

There is a distinct difference between performance optimization and performance maximization. I'm all for optimization, but maximization is ridiculous. So far, I don't see the need for VLess unless you're going for performance maximization, because the overhead could be well within acceptable range and not in conflict with optimization at all.

那么根据现在的 VMess，最多只能优化掉数据部分的额外计算，而请求头仍有多余的字段、HASH、加密、验证等，并不优雅

First of all, elegance should only be a goal if it's realistic to aim for it - I'm not sure of that. Second, it's most definitely not elegant when you split one protocol into two - in fact, that's much, much more inelegant than some limited overhead. Third, there is no reason to assume how the new Vmess protocol would look like based on how the current one looks like - if the new one is just like the old one, then what's the point? Fourth, why does the header have to fixed (and I don't mean length - I mean the constituent parts)? Why can't we have a flexible header? With a flexible header, you wouldn't even have unused bytes in it (not to mention that a flexible header might be harder to profile).

鉴于这个新协议并不难实现，我现在甚至有点想先把它写出来，而不是讨论“我们是否需要它”。

Truly nobody is arguing you shouldn't (in fact some are challenging you to provide code). You can certainly put it out there and see how well it's received. I think you're way too optimistic about how many users would agree and appreciate your approach. I also believe you're massively underestimating the difficulty of creating a plugable obfuscation layer. (And without a plugable obfs layer, your VLess wouldn't exist at all, am I right?)

I think what's likely to happen is: You write a minimalist data transfer protocol, that's near trivial. Then you put TLS around it and ask people to come up with an obfs layer for you, but nobody would heed your call. So you try to do it yourself and realize, no, plugable obfs is like Bigfoot - it's rumored to exist but nobody has definitely proof. You give up the "plugable" criteria and just write an obfs layer, and now VLess can only be used in conjunction with TLS and that specific obfs, and your originally minimalist VLess has basically become VMore.

[bhoppi]

区分加不加密只是往外转移了一层，仍要区分，这部分性能还是要损失的。

加不加密是双方事先约定好的，保持配置文件一致即可，既不增加字段，亦不需要协商，怎么会有性能损失？

你误解了，我指的是有些人想用比较纯粹的完全安全且无状态的 VMess，要确保能组合出来。

我并没有误解。我本人就有这样的需求，我现在在某些场景下的关键信道，用的是SOCKS5+WireGuard的组合，比现有V2Ray的任何带加密的模式速度都快。

其实你的想法挺好的，但我觉得开发组现在一心只想先原地替换现在的 VMess，不会解耦到那种程度。这也是我想新增一个 VLess 作为补充的原因。

同上。如果VLess设计合理，做到性能比肩SOCKS5，我肯定会用。如果V2Ray能再加入像我所说的一个轻量的PSK加密层，WireGuard也可以扔了。

[RPRX]

So far, I don't see the need for VLess unless you're going for performance maximization, because the overhead could be well within acceptable range and not in conflict with optimization at all.

在能够轻松做到的基础上，我的确更喜欢纯粹而极致的性能。

Second, it's most definitely not elegant when you split one protocol into two - in fact, that's much, much more inelegant than some limited overhead.

其实我并不想参与 VMore 的设计，这也是我一开始称它为 VMess 2 的原因。从另一个角度想，我只是创造了一个追求性能、可扩展混淆的新协议 VLess 而已，而不是将 VMess 一分为二。

Third, there is no reason to assume how the new Vmess protocol would look like based on how the current one looks like - if the new one is just like the old one, then what's the point?

是这样没错，但目前我们只有 VMess，所以我只能拿它来举例，我也很无奈。

I think you're way too optimistic about how many users would agree and appreciate your approach. I also believe you're massively underestimating the difficulty of creating a plugable obfuscation layer. (And without a plugable obfs layer, your VLess wouldn't exist at all, am I right?)

事实上，我已经在 v2ray/v2ray-core#2526 中描述了“简单协议”，即 VLess 的设计理念，只是现在不强制 TLS 了。 支持可无限扩展的混淆方案并不难，我已经在本 issue 正文中详细描述了如何实现它。

配置文件中新增“混淆方案”选项（把现方案改成可扩展形式），默认 none 不开启，填 rand 是每次请求随机选择一种混淆方案，填 shake 则是现方案（参数改为后面提到的随机值）。指令部分结尾添加一个1字节的“混淆方案长度”，如16+5=21。当选择了混淆方案时，继续添加一个16字节的随机值，接着是混淆方案的具体名称，如 shake，或以后推出的其它混淆方案。

[RPRX]

加不加密是双方事先约定好的，保持配置文件一致即可，既不增加字段，亦不需要协商，怎么会有性能损失？

好像的确是这样。

同上。如果VLess设计合理，做到性能比肩SOCKS5，我肯定会用。如果V2Ray能再加入像我所说的一个轻量的PSK加密层，WireGuard也可以扔了。

那么问题来了，到底是要设计 VLess，还是把认证改成 UUID、加上流量统计和可选混淆的 Socks5+？

---

我看到 Socks5 需要一次握手来协商认证方法，现在我认为 VLess 至少第一次请求会比 Socks5 快。 话说，加上数据压缩等级会不会更好？毕竟 TLSv1.3 不自带压缩了。（Socks5 则本来就没有这项）

---

仔细想了想，就穿墙来说，数据本来就是访问的网站自己 Brotli / Gzip 过的，所以没必要加可选压缩。

[henrypijames]

在能够轻松做到的基础上，我的确更喜欢纯粹而极致的性能。

It's not easily achievable - nothing is. The fact you think something is easily achievable after countless people before you have failed makes me question your basic judgement.

支持可无限扩展的混淆方案并不难，我已经在本 issue 正文中详细描述了如何实现它。

And I think that's a fantasy: It is as secure and unrecognizable as all the other self-made, proprietary obfuscation methods out there (that you so despise) - in other words, totally worthless. In fact, this seems worse than SS version 1.

[RPRX]

@henrypijames

Countless people have failed??? Just for achieving that??? Ridiculous. What's your problem with your basic judgement? I'm not old in age, but I've written code for nearly ten years, since primary school. And I've used so many programing languages. I wonder that don't you even code? Perhaps you should read the documentation carefully first.

https://www.v2fly.org/developer/protocols/vmess.html

[RPRX]

@henrypijames

我想表达的意思是，少特性比多特性还难实现？任何写过代码的人都不会说出这样的话。至于混淆方案，这是一个口子，设计时不能 hard code，因为这是用 TLS 后少有的有意义的变量了（有些人或许不希望完全随机而是希望像网页流量，并不是只有一个方向）

[hyxxsfwy]

既然已经是在可信通道上了为什么还需要混淆等内容，直接SOCKS5性能不应该更好吗？没有加密和验证却又混淆功能之间也并没有匹配。 混淆是为了防止流量审查者识别协议后封禁服务器，加密与数据校验是为了数据机密性、阻止审查者篡改数据探测。 所以不存在需要混淆而不需要加密的情况。

对 TLS 内包裹的流量进行混淆，是对抗用机器学习提取“恶意 TLS 流量特征“的必要手段。参考：

• 初探加密流量识别
• 基于机器学习的TLS恶意加密流量检测方案

[henrypijames]

I'm not old in age, but I've written code for nearly ten years, since primary school. And I've used so many programing languages. I wonder that don't you even code?

You have a propensity to ad hominem attacks - I've noticed that since I'm not the first one you've attacked. Every time you and someone else is talking in circles, it's the other person's fault: He is either too stupid to understand the issue, or too lazy to pay attention to what you've written, or both. There's never anything wrong with your argument, not even a little.

Whether I code or not shouldn't matter - in the history of computer science, there has been great personalities (mostly mathematicians) who made significant contributions without writing lines of code themselves, specially in the area of protocol design. But to answer your question: I've been writing computer programs since primary school as well, starting with Basic on Sinclair ZX (I still have that machine at home, and the programming cassettes) - and that was in the 1980s. I've been contributing to Open Source projects since the mid 1990s (the term Open Source didn't exist yet, and I didn't have access to the Internet, so it was on FidoNet). It seems you were born after that.

[RPRX]

@henrypijames

You have a propensity to ad hominem attacks - I've noticed that since I'm not the first one you've attacked. Every time you and someone else is talking in circles, it's the other person's fault: He is either too stupid to understand the issue, or too lazy to pay attention to what you've written, or both. There's never anything wrong with your argument, not even a little.

事实上，是你先开始不就事论事的，“question your basic judgement”，这是你说的。 不太理解，一些习惯用英语交流的人为什么不能好好说话呢？就像 v2ray/v2ray-core#2526 中那位一样。 然后你甚至反过来说“You have a propensity to ad hominem attacks - I've noticed that since I'm not the first one you've attacked.”，真是神奇。 我并没有一直坚持我的所有观点，但当我是正确的时候，和我辩论那位的确会很尴尬。 为了避免对方过度尴尬，我会在适当（胶着）的时候进行提醒，让对方仔细想一下。

Whether I code or not shouldn't matter - in the history of computer science, there has been great personalities (mostly mathematicians) who made significant contributions without writing lines of code themselves, specially in the area of protocol design. But to answer your question: I've been writing computer programs since primary school as well, starting with Basic on Sinclair ZX (I still have that machine at home, and the programming cassettes) - and that was in the 1980s. I've been contributing to Open Source projects since the mid 1990s (the term Open Source didn't exist yet, and I didn't have access to the Internet, so it was on FidoNet). It seems you were born after that.

让我们回到正题，既然从你第一次写代码开始已经过了近四十年，正如我所补充的（其实那才是重点），为什么你会觉得少特性比多特性还难实现（尤其是在包含少特性的多特性已经实现了的情况下），这不违反常理吗？你甚至还说前人在这件事上失败了，可以解释一下吗？

[henrypijames]

事实上，是你先开始不就事论事的，“question your basic judgement”，这是你说的。

Obviously, I wasn't question your basic judgement in life generally - we don't know each other AFK. I was questioning your judgement in regards to the task at hand, which is well within the realms of our discussion. You, on the other hand, made a feeble attempt at ad verecundiam argument.

为什么你会觉得少特性比多特性还难实现

That's not my position, it's your misinterpretation of my position - or a mischaracterization of the facts, really. Your design goal for VLess is not less features, since it has two features that the current Vmess doesn't have: "maximal performance" and "limitless extensibility" (particularly in obfuscation). I think neither one is realistic on its own, and I've laid out the argument why. To return your favorite phrase to yourself: read what I've written.

尤其是在包含少特性的多特性已经实现了的情况下

That's even more absurd. If we've already got what we want, what are doing here? Isn't any design of a new protocol based on the judgement that the old one hasn't realized (and can't realize) what we want?

[RPRX]

@henrypijames

既然你不怕尴尬，那么我们继续。希望你不要删除回复，因为有人这样做过。

Obviously, I wasn't question your basic judgement in life generally - we don't know each other AFK. I was questioning your judgement in regards to the task at hand, which is well within the realms of our discussion. You, on the other hand, made a feeble attempt at ad verecundiam argument.

你质疑的是什么，你当然可以随意解释 —— 反正你在当时也没明说。你没有意识到，重要的是听的人的感受，而不是你的事后解释。面对攻击，正当防卫已经没有防卫过当的说法了。

That's not my position, it's your misinterpretation of my position - or a mischaracterization of the facts, really. Your design goal for VLess is not less features, since it has two features that the current Vmess doesn't have: "maximal performance" and "limitless extensibility" (particularly in obfuscation). I think neither one is realistic on its own, and I've laid out the argument why. To return your favorite phrase to yourself: read what I've written.

你对 VLess 的理解倒是没错：1.性能 2.可扩展的混淆方案

那么“性能”要怎样做到呢？删代码。没错，主要不是写代码，是删代码，别告诉我这是做不到的。

至于可扩展的混淆方案，我已经把实现方法写得很详细了，具体到了协议结构和判断逻辑，实现起来不现实吗？如果你仍然这么认为，那我无话可说。

That's even more absurd. If we've already got what we want, what are doing here? Isn't any design of a new protocol based on the judgement that the old one hasn't realized (and can't realize) what we want?

就像我说的，是删代码、删特性。没必要的字段、HASH、加密、验证等，都需要删掉。

---

以及，我不喜欢在我们的讨论中掺杂我和别人的讨论，当你开始这样做时，就已经显示出你慌乱了。 还有你能不能别总是改来改去，一气呵成不好吗？这显得你有点混乱，我还要等你改完。

[henrypijames]

没错，主要不是写代码，是删代码，别告诉我这是做不到的。

You can remove code, but removing code doesn't necessarily improve it. You're not solving the fundamental problem that has led to the need for a new protocol in the first place.

I'm not questioning your design on entirely technical grounds, my argument is more abstract (philosophical if you will). You can disprove it by delivering an implementation that turns out to be working and widely accepted. But I'm not challenging you to do that - because I believe it won't work (at least your current design), and I'm not a sadist eager to watch you fail.

当你开始这样做时，就已经显示出你慌乱了。

Stop describing my state of mind to me. Either you're wrong, or you're right - in which case I don't need you to tell me. In any case, my emotions are irrelevant to the argument I make. Unless you're just trying to embarrass me in front of others - and now we're back to ad hominem attacks ...

还有你能不能别总是改来改去，一气呵成不好吗？这显得你有点混乱，我还要等你改完。

It's revealing how strongly you feel against one revising himself. I mention this because it mirrors your lack of reflection on your own protocol design as well (though not a total lack, I give you credit for that - you have at least climbed down from your initial fundamental opposition against anything that isn't based on TLS).

[RPRX]

@henrypijames

补充一点，我看了看我对您的质疑，也是纯粹技术相关的啊，有越界吗？

You can remove code, but removing code doesn't necessarily improve it. You're not solving the fundamental problem that has led to the need for a new protocol in the first place.

事实上，删掉那些不必要的特性还真的就能提高性能，你可以参考一下 trojan。就算从需求的角度出发，谁不喜欢更高性能的呢？trojan 相比 v2ray 几乎只有速度高出 25% 左右这个优势，而人们为了这个优势就可以转而使用它。

I'm not questioning your design on entirely technical grounds, my argument is more abstract (philosophical if you will). You can disprove it by delivering an implementation that turns out to be working and widely accepted. But I'm not challenging you to do that - because I believe it won't work (at least your current design), and I'm not a sadist eager to watch you fail.

那么我明白了，我在说技术，你在说哲学。。。算了这个无关紧要。 如我所说，我当前的设计（或者说简化）对提高性能是有帮助的。当然，你可以持保留意见。

Stop describing my state of mind to me. Either you're wrong, or you're right - in which case I don't need you to tell me. In any case, my emotions are irrelevant to the argument I make. Unless you're just trying to embarrass me in front of others - and now we're back to ad hominem attacks ...

因为我不喜欢你那样做，两个人就事论事，不必掺杂其它的东西。

It's revealing how strongly you feel against one revising himself. I mention this because it mirrors your lack of reflection on your own protocol design as well (though not a total lack, I give you credit for that - you have at least climbed down from your initial fundamental opposition against anything that isn't based on TLS).

如果我发现有更好的理念，那么我会把它拿来。非 TLS 协议的确是很好的烟雾弹，我也不想被集火。

[henrypijames]

I just saw that @xiaokangwang has started a project called VLite two months ago. You may want to take a look.

[RPRX]

I just saw that @xiaokangwang has started a project called VLite two months ago. You may want to take a look.

简单看了下，第一眼感受：根目录结构比 v2ray 好。 毕竟 v2ray 是在 GO111MODULE 出现之前的项目，将一些代码文件直接放在根目录下。 然后是 LICENSE：All rights reserved. 或许会修改？ 没有看到加密什么的，除了 dtls 部分有个 TLS_PSK_WITH_AES_128_CCM_8

[hanxiao1982]

诸位不要歪楼了，还是回到协议设计的讨论吧。 我个人认为还是尽量模块化保证协议搭配灵活性为好，毕竟这是V2Ray最大的特点，至于兼顾性能也并不一定非要拿掉所有特性只保留TLS。 例如可以将协议做成中间件一个模块一个模块搭起来，什么都不搭就是VLess，搭上加密，搭上混淆就慢慢VMore了。当然这样做开发复杂性会增加，同时估计保证不了与现有的VMess兼容性。

[Kylejustknows]

诸位不要歪楼了，还是回到协议设计的讨论吧。 我个人认为还是尽量模块化保证协议搭配灵活性为好，毕竟这是V2Ray最大的特点，至于兼顾性能也并不一定非要拿掉所有特性只保留TLS。 例如可以将协议做成中间件一个模块一个模块搭起来，什么都不搭就是VLess，搭上加密，搭上混淆就慢慢VMore了。当然这样做开发复杂性会增加，同时估计保证不了与现有的VMess兼容性。

你说的想法，很上面的帖子就被讨论了。 你可能认为，vmess = socks5 + 混淆 + 加密； 然而为了防探测，设计得完全不是这样。 vmess本身可以用参数关闭加密，但是完全关闭数据运算就不很好办，因为和其他协议那样握手认证后传输数据不同，vmess每个数据包里都带有用户验证（来克服一些网络问题）数据和鉴权加密混合融在一起的，这个数据处理运算是免不掉的。

所以才有上面的一些建议：

• 本机、局域网内通信的：直接Socks5
• 跨网络、但用其他方法套了一层TLS的：关闭加密的Vmess （保留了鉴权和混淆）
• 跨网络、直连V2Ray: 正常的带加密的Vmess。

我觉得这三种配置的性能都已经是理论上最佳了。

白话文指南里，最近冒出来几种分流器的配置方法，https://guide.v2fly.org/advanced/tcp_tls_web.html， 包括caddy最近也在更新待条件判定的tcp proxy的代码，可能不久之后，类似于trojan这种tls鉴权后数据直连的模式，会慢慢代替掉websocket. (但，tls握手后的直连数据，都用的不是合法http协议，CDN无法识别，所以想用CDN加速的，还是得websocket。 如果哪天，某个混淆插件能把数据流完全模拟成真实的http的POST GET PUT，能合法穿越各种http代理和分发网络，那就神了）

[henrypijames]

I also don't believe you can have a simple core protocol that is extensible and safe and resistant to attacks and probes, because people have tried that, many many times. Integrity is difficult when you're modular in the first place, but much more so when you build from bottom-up with a core agnostic to what's around it. The same is true - and much profound so, for unrecognizability. I don't think it has ever been done, ever (and not for lack of trying) - an modular and agnostic yet unrecognizable protocol.

This is what I've been trying to say to the original poster this entire time: I don't think his seemly simple and humble goals are simple or humble - I think it's downright impossible. So no, it's not off-topic at all.

[okudayukiko]

请问V2开发者还收love@v2ray.com和v2ray@protonmail.com的邮件吗？我认为VMess 2更好。我设想的方案已经发往V2开发者邮箱。