[Features Request] Request QUIC with XTLS support

[nJhEqnvK]

TL;DR 因为 mkcp 已经有xtls支持，不知道后续是否会有对QUIC的xtls支持？

QUIC在一定程度上能够抵抗丢包（软件控制重发包），并且随着未来HTTP3的普及被混淆于海量流量中，可能会比mkcp更安全/特征更小（之前被秒封有心理阴影了）。同时鉴于mkcp与QUIC都是基于UDP的协议，之前在VLESS发布时说暂时无法支持，但现在mkcp已经在 v2fly/v2ray-core#266 中讨论过并且已经实现，就不知同样的对QUIC添加支持是否有技术可行性？

辛苦大佬啦！

[nJhEqnvK]

附上一个晚高峰的堵车现场

此时TCP基本上处于瘫痪状态。。。

[RPRX]

技术上可以加，但 QUIC 已经自带了 TLS 的功能，从这个角度来说没有必要（给 mKCP 加是增强安全性）

[bhoppi]

我猜楼主的意思是把QUIC里的TLS替换成XTLS吧，用以提高性能。我个人觉得还是很有技术难度的，牵涉到第三方库的修改。 @RPRX

另外回复楼主，QUIC的抗丢包策略只在略有丢包的环境下有效，否则性能并不比TCP好。像你这个丢包率，只有KCP效果比较好了，QUIC根本不行。

[nJhEqnvK]

技术上可以加，但 QUIC 已经自带了 TLS 的功能，从这个角度来说没有必要（给 mKCP 加是增强安全性）

感谢 @RPRX 大佬回复， 正如 @bhoppi 所说，把QUIC原生TLS替换为XTLS可以提升性能，日后也有可能配合mKCP做fallback

我猜楼主的意思是把QUIC里的TLS替换成XTLS吧，用以提高性能。我个人觉得还是很有技术难度的，牵涉到第三方库的修改。 @RPRX

另外回复楼主，QUIC的抗丢包策略只在略有丢包的环境下有效，否则性能并不比TCP好。像你这个丢包率，只有KCP效果比较好了，QUIC根本不行。

mKCP之前因为被秒封过所以一直心有余悸，同时在v2ray那个repo下有过许多关于其性能、安全性的讨论，如v2ray/v2ray-core#1659 目前除了添加xtls外没看到后续跟进，不知Xray这边后面是否会针对这个问题进行讨论？

如果理解有误还请各位大佬拨冗指教，再次感谢各位的付出 😃

[Fhokud]

QUIC仍然处于草案状态，等QUIC确定最终版本后再改也不迟？

[RPRX]

TLS over QUIC 时避免二次加密有点难，因为 QUIC 耦合了太多东西，两者的 packet 应该也不是 1:1 的关系。

QUIC over QUIC 的优化倒是值得研究，相信 HTTP/3 定稿时，我是不会放过它的。

[reformc]

quic自带ssl加密了，再加密一次的确有点浪费性能。不过我觉得quic用处还是很大的，特别是手机使用，因为手机处于移动中，不管是wifi还是4G，信号不好或者网络不好的情况经常发生，而且手机也经常切换基站或者切换wifi，频繁的切换网络和丢包的话，显然quic更好用。

[reformc]

刚测了下，如果节点网速不稳定的话，用quic延时和带宽都比用xtls好很多。用xtls延时有1.6S到2S之间，用quic在1-1.4s之间。有时候因为IP限制，我必须选用美国机房或者欧洲机房的节点的话，网络就会很不稳定。但是ios的小火箭貌似不支持quic