Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rprx opened this issue Jul 16, 2020 · 200 comments

Comments

@rprx
Copy link
Contributor

@rprx rprx commented Jul 16, 2020

官网文档:https://www.v2fly.org/config/protocols/vless.html

终极配置:VLESS over TCP with XTLS + 回落 & 分流 to WHATEVER


2020-07-31 更新:VLESS PREVIEW 1.1 已于两天前合并进 v2ray-core 公测,将出现在 v4.27.0 版本中。

2020-07-23 更新:加入了判断首包长度(原创)的协议回落模式,PREVIEW 版本将很快发布(在此之后,BETA 系列仍会继续)。


这份说明本来应该于一周前 VLESS BETA 发布时就写好的,但因为实在是很麻烦(每次写说明比写代码麻烦多了),所以就鸽到了今天。。。不过上次也差不多。与上一份说明 #2583 不同,这次更加注重 VLESS 本身的设计。

代码在 rprx/v2ray-vless,它是 v2fly/v2ray-core 的超集,只是多了 VLESS 协议,其它的完全一样。releases 已补充历版 VLESS Changes,有已编译好的 Windows & Linux x64 版本,交叉编译可参考 v2ray/discussion#756

若你正在使用 TLS,简单地将 VMess 改为 VLESS 就可以获得性能提升:

  1. 替换服务端和客户端的可执行文件。
  2. 将两边的协议都改为 "vless",具体参考 VLESS 配置文档,相较于 VMess 的只有少许改动。

这只是 VLESS 的短期意义,它的长期意义是:可扩展性空前,适合随意组合、全场景广泛使用,符合很多人的设想、几乎所有人的需求,足以成为 v2ray 的下一代主要协议,乃至整个 XX 界的终极协议。

那么,是时候更新一下对 VLESS 的认知了。

Request & Response

1 字节 16 字节 1 字节 M 字节 1 字节 2 字节 1 字节 S 字节 X 字节
协议版本 等价 UUID 附加信息长度 M 附加信息 ProtoBuf 指令 端口 地址类型 地址 请求数据
1 字节 1 字节 N 字节 Y 字节
协议版本,与请求的一致 附加信息长度 N 附加信息 ProtoBuf 响应数据

VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了(BETA 是第五个测试版):

“响应认证”被替换为“协议版本”并移至最前,使 VLESS 可以升级换代,同时消除了生成伪随机数的开销。混淆相关结构被替换为附加信息(ProtoBuf)并前移,赋予协议本身可扩展性,相关开销也极小(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 动态增删用户则更高效顺滑。

引入 ProtoBuf 是一个创举,等下会详细讲解。“指令”到“地址”的结构目前与 VMess 完全相同,同样支持 Mux。

总体上,ALPHA 2 到 BETA 主要是:结构进化、清理整合、性能提升、更加完善。这些都是一点一滴的,详见 VLESS Changes

ProtoBuf

似乎只有 VLESS 可选内嵌 ProtoBuf,它是一种数据交换格式,信息被紧密编码成二进制,TLV 结构(Tag Length Value)。

起因是我看到一篇文章称 SS 有一些缺点,如没有设计错误回报机制,客户端没办法根据不同的错误采取进一步的动作。
(但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。)
于是想到一个可扩展的结构是很重要的,未来它也可以承载如动态端口指令。不止响应,请求也需要类似的结构。
本来打算自己设计 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 配置文档。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

由于 VLESS 是对 VMess 的精简且同样存在于 v2ray 中,目前 VLESS 的 UDP 能力与 VMess 完全相同,也就是:

  1. 整个 v2ray 对 UDP 的处理广泛存在问题,这是影响 FullCone 实现的障碍之一,参考 #1429 (comment)
  2. VMess 没有为 UDP 建立持久的隧道,这是影响 FullCone 实现的障碍之二,参考 https://trojan-gfw.github.io/trojan/protocol
  3. VMess 只支持 UDP over TCP,不支持直接 UDP(至于 mKCP、QUIC,它们不属于 VMess,且 UDP 实际上经历了两次转换)

对于第一个问题,要改 v2ray 很多地方的代码,希望 @xiaokangwang 大佬可以解决。

对于第二个问题,我先几句话讲清突破本地的层层 NAT 限制实现 FullCone 的原理:

简单来说就是把远端 VPS 的一些 UDP 端口“映射”到本机,使其效果完全等同于本机的端口(但本机的端口并不一定被实际占用)。因为 VPS 一般都是有公网 IP 的,NAT 环境最佳,核心原理就是利用 VPS 的公网 IP 来提升本机的 NAT 等级,或者某个游戏/应用的实际 NAT 等级。此时它们使用的实际上是远端 VPS 的端口,就绕过了本地的层层 NAT 限制。而要做到保持映射,至少连接要保持住。

VLESS BETA 系列后期,预计客户端可选:

"udp": {
    "nat": "origin" / "tunnel" / "tunnels",
    "tcp": true / false
}

Sharing link

为了避免 VMess 分享链接生态混乱的情况,VLESS 要求图形客户端等仅支持官方分享链接标准,即将出炉。

一开始,我只是简化了 VMess,并推出 VLESS 协议,追求性能极限,不断进行优化,同时注重可扩展性,为下一步铺路。

而现在,不同于前几个版本主要做减法,BETA 系列的目标是好好利用可扩展性,做可选的加法,成为终极协议。

我一直在强调,这些加法都是可选的,如果你不需要那就不用开启,并不影响性能极限,这也是最重要的、贯穿始终的。

到处可扩展、可组合、层层完美解耦不失性能,并不只是我一个人的设想,很多人都是这么想的,这个解决方案可以使所有人满意。

而 VLESS 将会成为有史以来可解耦性(性能)、可扩展性(功能)、安全性等都最强大、完美的终极协议,一个协议解决所有问题。

当然,这也离不开 v2ray 已有的模块,感谢大家的贡献。我相信对于 v2ray 来说,这也会是一个全新的开始。

若还有什么没考虑到的情况,欢迎提出改进建议,这个 issue 还会持续跟进 VLESS 的更新。

LESS IS MORE.

@wenjinlibug
Copy link

@wenjinlibug wenjinlibug commented Jul 18, 2020

@rprx 希望releases能增加“linux arm64”、“linux arm”。因为VLESS受益最大的应该是手机端(我绝不承认自己编译不出执行文件)。

@rprx
Copy link
Contributor Author

@rprx rprx commented Jul 18, 2020

@wenjinlibug

VLESS 即将发布一个 PREVIEW 版本,先合并进 v2ray-core 公测。以及,v2ray-vless 新版本会编译 linux-arm64-v8a 和 macos-64。

@lxhao61
Copy link

@lxhao61 lxhao61 commented Jul 18, 2020

尽快合并到主项吧,这样才有支持VLESS的OpenWrt路由器端、手机端、图形界面客户端应用。因为基本无人用v2ray原版的无图形界面的客户端。

@rprx
Copy link
Contributor Author

@rprx rprx commented Jul 18, 2020

@lxhao61

更新:VLESS 服务端已确定要加一个协议回落模式,将出现在 PREVIEW 版本中,所以还需要些时间才能发布。

@lxhao61
Copy link

@lxhao61 lxhao61 commented Jul 18, 2020

@lxhao61

更新:VLESS 服务端已确定要加一个协议回落模式,将出现在 PREVIEW 版本中,所以还需要些时间才能发布。

哦,这样呀。感谢!

@guodie418
Copy link

@guodie418 guodie418 commented Jul 19, 2020

好着急啊,不知道大佬们什么时候能融入正式版,这样我的垃圾软路由就能减轻负担了

@xhqpp
Copy link

@xhqpp xhqpp commented Jul 20, 2020

希望能解决UDP的痛点,那就真的是完美了

@rprx
Copy link
Contributor Author

@rprx rprx commented Jul 21, 2020

@xhqpp

解决 UDP 问题不仅需要改协议,还需要 v2ray 各个出入站及中间传输环节的支持,所以要等到 VLess BETA 系列后期,但会解决。

@lxhao61
Copy link

@lxhao61 lxhao61 commented Jul 21, 2020

@rprx
v2ray下的socks+websocket+tls、shadowsocks+v2ray-plugin及shadowsocks+websocket+tls配置应用有UDP问题不?非Vmess协议。

@rprx
Copy link
Contributor Author

@rprx rprx commented Jul 21, 2020

@lxhao61

应该有问题,且若不开 Mux,还会 UdpBlocked。

@lxhao61
Copy link

@lxhao61 lxhao61 commented Jul 21, 2020

@rprx
哦,还以为非Vmess协议无UDP问题。明白了,谢谢!

@ghost
Copy link

@ghost ghost commented Jul 28, 2020

I think one may enable FullCone NAT with v2ray's bridge and portals over VLESS, where mux will be automatically enabled, and the heart beat will be sent to keep the connection.

@rprx
Also the Port and Address in VLESS can be omitted when Mux.Cool is enabled. Maybe they can go into the ProtoBuf extesion?

@ghost
Copy link

@ghost ghost commented Jul 28, 2020

I like the Mux.Cool because of its flexibility and the potential to allow multiplexing an customizable dummy UDP into TCP connections to modulate the traffic pattern, for future obfuscation needs.

@rprx
Copy link
Contributor Author

@rprx rprx commented Jul 29, 2020

@pram991

v2ray 的 Mux 是在 VLESS 之前就接管了请求,把 VLESS 当成了它的底层传输方式,提供身份认证功能。

所以开启 Mux 后,Port 和 Address 已经不是 VLESS 的事情了,无需放入 ProtoBuf。

目前 Mux 是可以在一定程度上保持连接,但 v2ray 的一些组件有问题,仍然无法实现 FullCone。

Mux.Cool 本身也可能有一些坑,VLESS 协议以后可以单独选择第三方成熟的 Mux 方案。

@fbion

This comment has been minimized.

@zhaoyadong00

This comment has been minimized.

@rprx
Copy link
Contributor Author

@rprx rprx commented Aug 1, 2020

@okudayukiko

我觉得可行。

@okudayukiko
Copy link

@okudayukiko okudayukiko commented Aug 1, 2020

VMess/VLess可考慮擴展加入ICMP通道,這是為手機/電腦的V2Ray VPN模式而設計(目前PC的V2Ray Core只提供SOCKS/HTTP代理)。而VPN方案有TAP-Windows,用routenetsh設定路由表。

@1265578519
Copy link

@1265578519 1265578519 commented Aug 1, 2020

如果解决不了NAT的问题的话,,,感觉新协议没什么意义啊,看起来对比现有的貌似也没什么区别。
除了性能提升外?还有什么亮点吗,没看出来

@rprx
Copy link
Contributor Author

@rprx rprx commented Aug 2, 2020

@1265578519

现在这个时间点,大概还有很方便的协议回落?以及可扩展极强的框架。

不要太早下结论,让子弹飞一会儿~

@1265578519
Copy link

@1265578519 1265578519 commented Aug 2, 2020

@rprx 嗯,要正式的时候,一定要同时把NAT搞出来呀,这才是能突显出新协议的优势

@rprx
Copy link
Contributor Author

@rprx rprx commented Aug 2, 2020

@1265578519

v2ray-core 的第一个 VLESS 预览版,我觉得亮点是简洁而强大、安全的协议回落,接下来就是解决 UDP 问题和继续提升性能了。

有了这样的协议回落后,可以使 TCP + TLS 成为常态,比 WSS 更好。协议回落今天也刚刚升级,预计很快发布,主要是:

允许根据 TLS ALPN 的协商结果来单独转发 h2;支持 PROXY protocol 1 & 2,这样后端就能拿到请求的真实来源 IP 和端口了。

@okudayukiko
Copy link

@okudayukiko okudayukiko commented Aug 2, 2020

我覺得transport security的TLS可以分為server mode和client mode,server mode可以指定Cipher suite、ECDH Curve、Rekey timeout、Prefer server cipher,client/server可指定TLS Engine(Go/OpenSSL,也可考慮LibreSSL,Windows 10內建OpenSSH用的是LibreSSL)。未來可將DTLS和SSH(預設偽裝無Shell的SSH,畢竟Psiphon用的就是改版SSH)加入到transport security裡面。雖然目前TLS足夠穩定而且速度快。另外OpenSSL TLS 1.0-1.2使用OpenSSL風格的Cipher suite name,如ECDHE-ECDSA-AES128-GCM-SHA256(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)、ECDHE-ECDSA-AES128-SHA256(TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256),程式在指定Cipher suite時要自動轉換。
還要考慮一些電腦遊戲、程式是不支援代理的,必須VPN模式。我們遇到一個現象是繁體中文/日文Windows在中國下載更新(Windows Update/Windows Store)很慢,簡體中文Windows下載更新很快。
請支援NAT設定。
另外WS+TLS是用TLS包裝WS,H2+TLS是用TLS包裝H2;不清楚KCP+TLS是用TLS包裝KCP,還是用KCP包裝被TLS加密的數據。

@lxhao61
Copy link

@lxhao61 lxhao61 commented Aug 4, 2020

@rprx
大神出一个VLESS支持 PROXY protocol 1 & 2回落的具体配置模板(VLESS与Nginx配合),特别是Nginx安装与配置。否则大部分不知道怎么具体配置,当然包括我。

@okudayukiko
Copy link

@okudayukiko okudayukiko commented Aug 4, 2020

@rprx
大神出一个VLESS支持 PROXY protocol 1 & 2回落的具体配置模板(VLESS与Nginx配合),特别是Nginx配置模板。否则大部分不知道怎么具体配置,当然包括我。

VLess是底層協定(SOCKS也可作為V2Ray底層協定),TLS、TLS+WS、TLS+HTTP2是進一步Transport層包裝。Nginx可以偽裝成wss://localhost:443,瀏覽器或curl打開https://localhost:443 後是一個網頁。Trojan-GFW支援plain_http_response選項,就是直接以HTTPS協定訪問端口時會返回的網頁。

@rprx
Copy link
Contributor Author

@rprx rprx commented Aug 4, 2020

@okudayukiko

VLESS 有基于首包长度分流(VLESS 原创)的新型协议回落模式,相对于其它协议回落方案,更简洁、高效、安全,功能也更强大。
https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md

@lxhao61

设置 proxy_protocol 和 set_real_ip_from 即可(当然,之后也会出例子
https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/

@twzchi
Copy link

@twzchi twzchi commented Aug 4, 2020

v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vless/outbound: failed to find an available destination > v2ray.com/core/common/retry: [dial tcp xx.xx.xx.xx:443: operation was canceled dial tcp: operation was canceled] > v2ray.com/core/common/retry: all retry attempts failed
这个警告是因为服务器太渣,产生丢包,然后Warming吗?

@rprx
Copy link
Contributor Author

@rprx rprx commented Aug 4, 2020

@twzchi

网络问题,换成 VMess 试试,也一样的。

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

现在就是原封不动地传递。VLESS 的事情取决于需求,回落也只是一次性判断,后面就不会管了,纯搬运。

XTLS 必须最前置,不支持 CDN。

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

可能对现在的模式存在些误解。。。建议研究下文档

@mclovin-2k
Copy link

@mclovin-2k mclovin-2k commented Sep 27, 2020

XTLS已经有了,就等XUDP了。

@rhjdvsgsgks
Copy link

@rhjdvsgsgks rhjdvsgsgks commented Sep 27, 2020

XTLS已经有了,就等XUDP了。

估计难,udp本来就不是加密的

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

XUDP 也是 over TCP 的,特点是聚合隧道和实现对 UDP 的精细控制,包括 FullCone。

@ruisiji

This comment has been hidden.

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

(已在另一个 issue 中回复)

@ruisiji

This comment has been hidden.

@imess
Copy link

@imess imess commented Sep 27, 2020

Sorry, 我修改了一下问题,能否再查看一下?

TLS是端对端加密,直接对话的双方是终结点,nginx前置,xtls在后不就失去意义了,虽然不清楚nginx的4层转发是否可行

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

可以 Google 一下 Nginx SNI 分流的用法。

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

TLS是端对端加密,直接对话的双方是终结点,nginx前置,xtls在后不就失去意义了,虽然不清楚nginx的4层转发是否可行

Nginx 的 SNI 分流不会影响

@zhaoyadong00
Copy link

@zhaoyadong00 zhaoyadong00 commented Sep 27, 2020

XUDP 也是 over TCP 的,特点是聚合隧道和实现对 UDP 的精细控制,包括 FullCone。

不能理解实现思路 或者 细节,可以详细讲解一下吗。

@ruisiji

This comment has been hidden.

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

XUDP 也是 over TCP 的,特点是聚合隧道和实现对 UDP 的精细控制,包括 FullCone。

不能理解实现思路 或者 细节,可以详细讲解一下吗。

v2fly/v2ray-core#112 (comment)

@rhjdvsgsgks
Copy link

@rhjdvsgsgks rhjdvsgsgks commented Sep 27, 2020

同不理解,希望能说下具体是什么原理
依我看来如果不把 udp 直接嵌到某些流中的话就不算 x 了,但直接嵌进去的话不就是直接暴露明文了吗

看起来好像就是个 udp over tcp ,并没有像 xtls 一样把原始数据嵌入到新的流中?🤔

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

就是个加强版 UDP over TCP

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

补充:对回落功能和 XTLS 的理解是错误的,文档里有正确答案。

@kirin10000
Copy link

@kirin10000 kirin10000 commented Sep 27, 2020

也许是我被自己的 use case 给束缚住了,始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。

你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢?

你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢?

@ruisiji
你可以翻一下我的脚本里的V2Ray-XTLS+TCP+Web配置文件部分,可能对你有帮助

@ruisiji
Copy link

@ruisiji ruisiji commented Sep 27, 2020

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 27, 2020

@ruisiji

即使是 VLESS 前置,对 Web 而言也是多一次本地流量转发。

@ruisiji
Copy link

@ruisiji ruisiji commented Sep 28, 2020

@rprx 希望大拿能够攻克一下难关,允许将 VLESS + XTLS 放在 CDN 后面,这样使用场景就能大大的扩展了。

另外就是关于 UDP 的支持了,这个呼声非常高,不知道用 CDN 的话,还能不能很好的支持了。

看样子将 VLESS 当成 VMESS 用的话是可以放 CDN 后面的,但 XTLS 和 UDP 貌似就没实现了。

@kirin10000
Copy link

@kirin10000 kirin10000 commented Sep 28, 2020

@rprx 希望大拿能够攻克一下难关,允许将 VLESS + XTLS 放在 CDN 后面,这样使用场景就能大大的扩展了。

另外就是关于 UDP 的支持了,这个呼声非常高,不知道用 CDN 的话,还能不能很好的支持了。

看样子将 VLESS 当成 VMESS 用的话是可以放 CDN 后面的,但 XTLS 和 UDP 貌似就没实现了。

XTLS不可能放CDN后面的,CDN是同服务器建立TLS连接,同时和客户端建立另外一个TLS连接,在CDN中与服务器的建立的TLS连接会解密,并重新进行TLS加密与客户端连接

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 28, 2020

@ruisiji

XTLS 原理上无法支持 CDN(除非 TCP 转发)和 WS,且 CDN 与 XTLS 的需求场景也不相符,套 CDN 本身对性能就不会很敏感。

VLESS 的 UDP 是 over TCP 的,一开始就支持、有实现,包括 CDN。建议避免出现这样的认知偏差。

@kirin10000
Copy link

@kirin10000 kirin10000 commented Sep 29, 2020

想了解一下XTLS和TLS在对UDP的处理上有区别吗?使用XTLS会不会增加UDP包传输延迟?

@rprx
Copy link
Contributor Author

@rprx rprx commented Sep 29, 2020

想了解一下XTLS和TLS在对UDP的处理上有区别吗?使用XTLS会不会增加UDP包传输延迟?

1.有区别 2.应该不会

目前在灰度测试一个新的带长度的 UDP 格式(启用 XTLS 时),如果没什么问题,下个版本会变成 UDP 的默认传输格式

@759071793
Copy link

@759071793 759071793 commented Oct 8, 2020

也许是我被自己的 use case 给束缚住了,始终无法理解 VLESS + XTLS + HTTPS Web Server 怎样组合使用。
你能否提供 VLESS + XTLS + HTTPS Server1 + HTTPS Server2 这样的示例呢?
你能否提供 VLESS + XTLS + Nginx(HTTPS Server1 + HTTPS Server2) 这样的示例呢?

@ruisiji
你可以翻一下我的脚本里的V2Ray-XTLS+TCP+Web配置文件部分,可能对你有帮助

大佬请问如何配合宝塔面板呢。

@xiaopanggege
Copy link

@xiaopanggege xiaopanggege commented Oct 26, 2020

@rprx 针对被qian方面的考虑,vmess是不是会更安全一些?

@rprx
Copy link
Contributor Author

@rprx rprx commented Oct 26, 2020

@rprx 针对被qian方面的考虑,vmess是不是会更安全一些?

不会。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.