[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 的具体设计，我个人并没有太多想法，只是认为这应该是一个相对整体的安全方案，而且觉得这可能是一个长期工程。建议多参考一些其它地方已有的最佳实践（而不是闭门造车），以及参考 #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 指纹解决方案时，可以直接拿来用。v4.23.2 之后：尽量分散特征 #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 就会快很多 #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开了加密更快？

（已缓解的问题）v2ray/v2ray-core#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?

[RPRX]

@okudayukiko

虽然你说的是 VMess V2，不过我说一下 VLess 中的做法，可以了解一下 v2ray/v2ray-core#2583

1、UUID使用ECDH交换（如X25519）且经常Rekey，不使用系统时间，如果时间错了就很麻烦。另外基于时间和HMAC-MD5的模式计算量大。

VLess 直接只用 UUID，不进行多余计算。有 TLS 等现代加密的情况下其实不会看出重复特征的。

2、TLS可选ECDHCurve、PreferServerCipher（默认为False）、PreferChaCha20（PreferChaCha20=true则使用ChaCha20-Poly1305->AES-GCM->AES-CBC。PreferChaCha20=false则使用AES-GCM->ChaCha20-Poly1305->AES-CBC。默认为false）选项。

这个就属于 V2Ray TLS 的事情了，与协议是解耦的。

3、制定QR Code和Share link标准。

我也是这么想的，必须有官方分享标准，不能像 VMess 一样混乱。

4、V2Ray手机App仍然不规范，许多App不支持SOCKS5+WS+TLS。V2RayNG也不支持SOCKS5+WS+TLS。

Socks5 有两次握手，不如用 VLess，0-RTT。

5、由客户端选择是否混淆和加密（不使用VMess加密则由TLS处理加密）。这一段信号会被加密传输。

混淆可以由客户端选择、服务端适配，但是加密必须双方提前约定，不然无法完美解耦。
加密和 TLS 不应该是二选一的，还可以都不选（内网）

[okudayukiko]

@okudayukiko

虽然你说的是 VMess V2，不过我说一下 VLess 中的做法，可以了解一下 v2ray/v2ray-core#2583

1、UUID使用ECDH交换（如X25519）且经常Rekey，不使用系统时间，如果时间错了就很麻烦。另外基于时间和HMAC-MD5的模式计算量大。

VLess 直接只用 UUID，不进行多余计算。有 TLS 等现代加密的情况下其实不会看出重复特征的。

2、TLS可选ECDHCurve、PreferServerCipher（默认为False）、PreferChaCha20（PreferChaCha20=true则使用ChaCha20-Poly1305->AES-GCM->AES-CBC。PreferChaCha20=false则使用AES-GCM->ChaCha20-Poly1305->AES-CBC。默认为false）选项。

这个就属于 V2Ray TLS 的事情了，与协议是解耦的。

3、制定QR Code和Share link标准。

我也是这么想的，必须有官方分享标准，不能像 VMess 一样混乱。

4、V2Ray手机App仍然不规范，许多App不支持SOCKS5+WS+TLS。V2RayNG也不支持SOCKS5+WS+TLS。

Socks5 有两次握手，不如用 VLess，0-RTT。

5、由客户端选择是否混淆和加密（不使用VMess加密则由TLS处理加密）。这一段信号会被加密传输。

混淆可以由客户端选择、服务端适配，但是加密必须双方提前约定，不然无法完美解耦。
加密和 TLS 不应该是二选一的，还可以都不选（内网）

制定两套协议太麻烦了，VMess V2由客户端选择是否用VMess混淆比较好。另外调用System time的做法，时间一错就很麻烦。AES-GCM只提供加密不提供混淆，现在用SS秒封端口。我也认为加密必须双方提前约定比较好，如果用VMess V2则服务端要求必须开启VMess加密（由客户端选择AES-128-GCM/AES-256-GCM/ChaCha20-Poly1305），如果用VMess V2-TLS则服务端允许关闭VMess加密。VMess v2不兼容VMess v1，但V2Ray服务器默认开启这两种协议保持兼容性（Kitsunebi Android有半年没更新了）。
另外目前Ubuntu、Debian收录了SS，但没收录V2Ray、ACME.SH。目前FreeBSD收录了V2Ray、ACME.SH。

[RPRX]

@okudayukiko

现在的情况是，VMessAEAD 已经出了，比原来的 VMess 更重，而且同样无法解耦掉混淆和加密。
VLess 也出了，目前是由客户端选择是否混淆的，服务端会自动适配。不选择混淆则一干二净。

加密的提前约定指的是不能有协商过程（服务端自动适配也是协商），要提前约定哪种算法。
这种方式不影响内层协议，承载什么都可以，说白了就是另一个 TLS。

当 VLess 有约定加密后，其实就是对 VMess 做了一轮重构：核心、混淆、加密，三者高度解耦。
但是否加密不应该是强制的，不是说必须加密或 TLS，应该还可以都不选，这才是人性化的设计。

VMess v2不兼容VMess v1，但V2Ray服务器默认开启这两种协议保持兼容性

这是很难做到的，还会带来安全性问题。

[okudayukiko]

另外混淆用的SHAKE128，我用openssl speed -evp sha256、openssl speed -evp blake2s、openssl speed -evp shake256发现shake256最慢，blake2s最快。

[RPRX]

@okudayukiko

感谢，之前还真没留意这方面，我有空也测试下性能。

[RPRX]

@okudayukiko

SHAKE-128 和 SHA-256 速度相近，所以 SHAKE-256 确实应该比 SHA-256 慢。

https://blake2.net/

初步决定新增 BLAKE3：

https://github.com/BLAKE3-team/BLAKE3

[RPRX]

我突然发现 VMess 原有的混淆真的只是”元数据“混淆，十分鸡肋，不知道存在的意义是什么。

[RPRX]

准确地说，VMess 原有的“元数据混淆”在 TLS 上除了降低性能外完全没有任何意义，不应该被留着。

[okudayukiko]

TLS能指定ECDH Curve和Cipher suite也有必要。我認為，TLS應該增加幾個選項：ECDHCurve、EnableAEADCiphers。
EnableAEADCiphers預設為true。若EnableAEADCiphers=0，則使用ECDHE-ECDSA(RSA)-AES-256-CBC-SHA384->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA1->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA1->RSA-AES-256-CBC-SHA384->RSA-AES-128-CBC-SHA256->RSA-AES-256-CBC-SHA1->RSA-AES-128-CBC-SHA1。若EnableAEADCiphers=1，則使用ECDHE-ECDSA(RSA)-AES-256-GCM-SHA384->ECDHE-ECDSA(RSA)-CHACHA20-POLY1305-SHA256->ECDHE-ECDSA(RSA)-AES-128-GCM-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA384->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA1->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA1->RSA-AES-256-GCM-SHA384->RSA-CHACHA20-POLY1305-SHA256>RSA-AES-128-GCM-SHA256->RSA-AES-256-CBC-SHA384->RSA-AES-128-CBC->SHA256->RSA-AES-256-CBC-SHA1->RSA-AES-128-CBC-SHA1。OpenSSL預設握手是ECDHE-ECDSA->ECDHE-RSA，AES-256-GCM-SHA384->CHACHA20-POLY1305-SHA256->AES-128-GCM-SHA256。
我使用AnyConnect和Trojan發現，單核VPS使用AES-CBC-SHA2速度最快。在手機上使用TLS-AES-CBC-SHA2比TLS-AES-GCM-SHA2、TLS-CHACHA20-POLY1305-SHA256省電和快速。AEAD-SHA2要進行兩輪計算。單核VPS，Ubuntu 20.04，看YouTube 1080P時，VPS的CPU使用率就高達50%。
/etc/ocserv/ocserv.conf
#Ocserv不使用AES-GCM的設定
tls-priorities = "NONE:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-DTLS1.0:+VERS-DTLS1.2:+SIGN-ALL:+ECDHE-RSA:+ECDHE-ECDSA:+AES-128-CBC:+AES-256-CBC:+SHA1:+SHA256:+SHA384:+CURVE-SECP256R1"
在單核VPS和雙核VPS上，TLS-AEAD-SHA2性能都比TLS-AES-CBC-SHA2差，雖然表面上用openssl speed -evp aes-128-gcm和openssl speed -evp aes-128-cbc跑分，AES-GCM比AES-CBC快。

[okudayukiko]

@RPRX ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。
另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

[hyxxsfwy]

@RPRX ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。
另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks

据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。

所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

[okudayukiko]

@RPRX ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。
另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks

据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。

所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。
你多試試幾個能用支付寶支付的廠商。
我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

[hyxxsfwy]

@RPRX ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。
另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks
据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。
所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。
你多試試幾個能用支付寶支付的廠商。
我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

沒有謾罵，只是指出您的描述中存在謬誤的事實。我們知道，非常的觀點需要更強的事實證據作為支持。拿出令人信服的證據，否則只自話自説你個人的“觀察”與“認為”是沒有意義的。
TLS1.3 是經過工業界嚴格的審計、測試、優化的，Google、CloudFlare 等流量大戶早已大規模部署。V2ray 有必要使用 Golang 庫提供的 TLS1.3 標準加密套件，以消除特徵，抵禦攻擊，保障信道安全，這是這段時間眾多開發者們達成的共識。任何試圖改變這一條原則的設計建議，都要接受嚴格的審視、評議。

[hyxxsfwy]

@RPRX ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。
另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks
据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。
所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。
你多試試幾個能用支付寶支付的廠商。
我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

關於 TLS 在低性能行動轉裝置和 IoT 設備上電量消耗的問題，業界也有大量的研究。比如這篇文獻：

Analyzing power consumption of TLS ciphers on an ESP32 (March 2019)

Despite the fact that these values have been obtained on a single IoT platform using a dedicated TLS implementation we obtained viable tendencies:
• Using TLS on the ESP32 requires a significant amount of energy. Compared to an unencrypted transmission, approximately 14 times more energy is required to establish a full TLS session.
• TLS 1.2 session resumption significantly reduces the required energy for IoT devices. At the moment of writing, TLS 1.3 session resumption has not been implemented.
• Using ECDSA instead of RSA for TLS signatures is beneficial in terms of energy consumption.
• TLS 1.3 further reduces the energy consumption for a full session compared to TLS 1.2.

個人的使用體驗是，TLS1.3 + WS + VMESS，沒有在手機和平板上觀察到明顯的電量損耗。

[okudayukiko]

更新，只要是TLS，不管AnyConnect還是Trojan，手機耗電問題幾乎無解。TLS的話建議分server和client模式，server模式可以指定TLS Cipher suite、ECDH Curve、Rekey timeout、Prefer Server Cipher，這些參數對TLS性能影響較大。Trojan用CHACHA20-POLY1305也耗電問題無解。

[RPRX]

@okudayukiko

刚刚手滑。。。

服务端最好不要 Prefer Cipher，否则客户端无法自动选择最适合自己的加密套件。

[wenjinlibug]

不知各位大佬是否願意聽一下外行人的意見，我不懂什麽加密套件加密原理，也不懂怎麽混淆才能騙過墻，僅僅作爲一個使用者來説，多一個協議選擇就代表墻要多分一份資源來防堵，如果只需要投入極少的人力簡單的合并到v2ray裏何樂而不爲？誰規定VLess合并后就一定要分出大量人力來維護了？至於Vmess的混淆加密等確實不是性能瓶頸，畢竟手機、電腦、服務器、綫路帶寬都會更新換代硬件性能提升遲早會完全蓋過那點性能損失，可問題的根本不在那裏，真正的問題在於“最沒特徵的人是間諜”，沒特徵本身就是最大特徵，現在的Vmess看起來就像毫無意義的强調無特徵和強加密。

[Sanfrencon]

我觉得应该从普通使用者的角度来考虑这个问题，如果是用来爬墙的话加解密速率不是大问题，服务与线路的稳定才是核心。目前看评论，开发VLess在我看来很大程度上有与Trojan比较的想法。讨论的计算资源占用问题，个人认为新的加密算法或者协议集成下就可以。vmess协议或者ss协议或者其它，来个开关，想用就用，不用你就明文再套个其它加密也行。这样组合更多，有的选，大家选自己最喜欢的就好，不用吵架。

V2ray在我心中应该更像一把瑞士军刀，提供更多选择与组合的同时，不断添加新的工具可以用，而不是简单为了翻墙去设计。我也经常用v2ray做国内的代理和转发，感觉配置简单很好用。个人期望v2ray在网络可靠性上有更好的设计，无论是改良目前UDP缺点，还是提供一个较好的负载均衡功能。都可以用比较小的成本，换取更稳定的网络体验。

[RPRX]

感觉楼上几位朋友误解了。。。现在并没有什么冲突。。。

[okudayukiko]

或者支持VMess+SSH。SSH支持的算法（Host key、Keyex、Encrypt、MAC）更多，在客戶端紀錄Base64 Public key或Public key fingerprint防止攻擊。
OpenVPN（TLS tunnel mode除外）、Tinc可以調用OpenSSL Library支持的算法，不受TLS Ciphersuite限制。

[RPRX]

@okudayukiko

SSH 自带 Socks5 代理（几年前流行的翻墙方式）

[RPRX]

@okudayukiko

刚刚 GitHub 崩了很长时间，没仔细看，回复也是过了好久才终于发出去

SSH 的 Socks5 是否有明显区别于 SSH 的特征还有待研究（我还没研究过

[okudayukiko]

這幾天在VPS上添加了2GB的swap file，再把原來.XYZ的域名換為.COM，解決了用Trojan看視頻時VPS端CPU使用率高的問題。
Trojan伺服器端或用戶端只協商一個TLS Cipher，看視頻緩慢的問題解決。
{
"run_type": "server",（或"run_type": "client",）
"ssl": {
"cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256",
"cipher_tls13": "TLS_AES_128_GCM_SHA256"
}
}
SSH用戶端使用以下命令（手動指定一個Cipher）也可以用SSH SOCKS5代理：ssh -D 1080 -o Ciphers=aes128-gcm@openssh.com user@host、ssh -D 1080 -o Ciphers=chacha20-poly1305@openssh.com user@host、ssh -D 1080 -o Ciphers=aes128-ctr -o MACs=hmac-sha2-256-etm@openssh.com user@host。直接用ssh -D 1080 user@host會被中國防火牆阻斷（預設情況下SSH客戶端會協商多個Ciphers），應該是被降級攻擊（對umac-xxx-etm@openssh.com和umac-xxx@openssh.com進行阻斷）。
Ocserv則使用以下配置，只協商一個TLS Cipher。
/etc/ocserv/ocserv.conf
tls-priorities = "NONE:+VERS-ALL:+ECDHE-RSA:+ECDHE-ECDSA:+SIGN-ALL:+AES-128-GCM:+AEAD:+GROUP-SECP256R1:+CURVE-SECP256R1"

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days