VLESS outbound: Add pre-connect (early test, for Vision Seed)

[RPRX]

先前预告：https://t.me/projectXtls/1034

关于 Vision Seed，其实我之前不确定要不要加个“预连接”功能，现在非常确定了，因为它可以把 TCP 握手延迟都给干掉，再结合 Vision 的自由 padding 可以先演一下，所以只有自带 padding 的协议适合这么干

这么多年了我发现推动人们换新技术的并不是加密多安全，而是“不被封”，就像如今直连机场大量上 REALITY，所以需要同时给用户一些“肉眼可见的好处”，不然很难推动

“预连接”不同于“maxConcurrency=1”的连接复用，它本质上还是多条 TCP 连接，同样是消灭了延迟，至少有助于防止运营商或 GFW 对持续时间长的 TCP 连接进行降级，至于流量总量还是很大，只能是加钱了

“预连接”像连接复用、Switch 一样可以把实际延迟降至 0-RTT，但是只适合 Vision 这类有自由 padding 的协议，否则会是强特征

具体而言，它可以消除 VLESS Encryption TCP 握手的 1-RTT 延迟，也可以消除 REALITY/TLS 握手共 2-RTT 的延迟（TCP+TLS）

当前的配置方式是在 VLESS outbound 简化配置的 settings 中加 "testpre": 5，即可预留五个握手完毕的空闲连接以供使用

下一版 Xray-core，即正式版本中需要在 Vision Seed 中配置，并且会加上一些无数据的 padding 往返以尽量消除“预连接”的特征

NFTs

本次放出了一些 0.01 ETH 的 REALITY NFT，以及 VLESS NFT & Project X NFT 仍在架，请支持一下，本质上是捐款的纪念品

REALITY NFT：https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

VLESS NFT：https://opensea.io/collection/vless

Project X NFT：https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

[HappyLeslieAlexander]

https://github.com/yosebyte/nodepass

[RPRX]

首先“预连接”这个技术早几年就讨论过了，懒得找链接，我还看过有个项目给 Trojan 搞“预连接”，不过没有 padding 就是强特征

[RPRX]

几年前 REALITY 仓库写下的“XTLS 的下一个主要目标是 0-RTT”对 Vision 而言就是“预连接”，这不更早，不然它又没有复用该咋实现

只是以前的 VLESS outbound 有 vnext 多目标、users 多用户，写起来有点麻烦，现在只有一个 end point，一个小时就糊完了

[RPRX]

再往前推一些就是我在“消失”前就预告的 REALITY，提到了吊打 XTLS、可以用别人的域名、不仅是真实的 TLS 还是 0-RTT（显然指的不是“多路复用”），我本来是想把这些东西全糊一起的，最后还是搞成了模块化设计、自由组合

说这些没有别的意思，只是防止有人找角度恶评说抄谁谁谁，并且说实话“预连接”这么简单的东西是个开发者都能自己想出来

至于为什么以前没普及，就是我说的原因，前提是你得有自由 padding 否则强特征，但是用得好的话它还能起到迷惑 GFW 的作用

[gfw-killer]

Is it possible to use this with xhttp? without xhttp padding and separated up-down streams my node get blocked after few days
And please have a look at #5195

[Smallthing]

试了一下就炸掉
panic: runtime error: index out of range [-1]

goroutine 30 [running]:
github.com/xtls/xray-core/app/proxyman/outbound.(*Handler).Dial(0x4000324750, {0x13c4c88, 0x1ed6d60}, {{0x13c52f8, 0x400032c050}, 0x1144, 0x2})
github.com/xtls/xray-core/app/proxyman/outbound/handler.go:320 +0x844
github.com/xtls/xray-core/proxy/vless/outbound.(*Handler).Process.func1()
github.com/xtls/xray-core/proxy/vless/outbound/outbound.go:151 +0x108
created by github.com/xtls/xray-core/proxy/vless/outbound.(*Handler).Process in goroutine 29
github.com/xtls/xray-core/proxy/vless/outbound/outbound.go:142 +0x308

[RPRX]

@Smallthing 上一次 force-push 前是不会炸的，但是第一个连接关闭后它的 ctx 被 cancel 会导致后面的 dial 不出去

所以换成了 background，我研究下需要 clone ctx 里的哪些值

[RPRX]

看起来似乎把这处 panic 改掉，然后 VLESS outbound 加行代码赋值一下 ob.Conn 就行了，只是底层传输日志中 ctx id 会不一样

[RPRX]

确实可行，e8aecbc 已修，经测试可以正常使用，你们再测测吧

@gfw-killer 这个 pre-connect 是给 RAW REALITY/Encryption 用的，XHTTP 自带复用，体感延迟本身就是 0-RTT，但可以用 Seed

[RPRX]

@Fangliding 在群里提到了 senderSettings

简单看了下貌似它用到了 ctx 中的东西，所以这个 pre-connect 目前只适用于非 dialerProxy 的情况

[RPRX]

翻出来些先前讨论

预连接：https://t.me/projectXtls/143 、#3560 (comment)

Seed：#1295 (comment) 、https://t.me/projectXtls/145

至于 Switch，明年上吧，还有 Mux/Reverse 增强、PLUX 等，说实话 pre-connect 出了后再加个游戏佬喜欢的 PLUX 就差不多了

现在感觉 pre-connect 潜力很大、会成为标配，如果想要原生 UDP 打游戏，那用 PLUX #3560 (comment) 可以替代，齐活了

[Smallthing]

这东西的预连接的超时怎么设置，大规模使用cdn图片后有时候会卡好一会，服务端看经常能产生60多个预连接，感觉复用逻辑是不是有点粗暴了

[RPRX]

@Smallthing 超时是 TODO，还有你 testpre 设的 5 就最多有五个预连接，不会有六十多个

[RPRX]

@Smallthing 连接数不等于预连接数啊，你应用层的连接没断开，代理层是 1:1 的，几十个不是很正常吗

其中有十个是预连接，你填的 5 就表明随时有 5 个预连接备用，如果被使用了就会自动开新的预连接，自动补至 5 个

[Fangliding]

我稍微重写了一下这个池逻辑 1e50e6e

[RPRX]

@Fangliding 直接用 channel 的确更方便，不过得补上 sleep，不然可能会疯狂循环，还有直接 go func 就行

[Fangliding]

我把close的逻辑一起做了所以那里会略长 才提前拉出来的

[RPRX]

@Fangliding 改成 channel 倒是方便了多次 go，要不改成 make channel 1 然后起多个 go 吧（实现了 concurrency 的 TODO），不然哪次阻塞了就全堵了，还有 timeout 的 TODO 你也加一下（它可能也需要 customize & randomize？）

然后 TODO 就只剩下了 sleep 的 customize & randomize，还有 vision paddings，至于 ctx mitm 我想了下似乎不需要

[RPRX]

大概以下四个 customize & randomize：

• testpre
• sleep
• timeout
• vision paddings

先 sleep 再 dial，不然一下子 dial 出去 n 个，容易失败

Close 可以实现，inactive 我想了下不用管，没人用这个出站的话那些 conn 会自动断开，只是不太利于半小时一次的连接观测

[Fangliding]

err我想过了 遇到就让worker死掉 用用户的下一次请求来唤醒 熵更高 还不会出现断网静置反复尝试的问题 就是逻辑会比较复杂
起几个goroutine我想过 但是怕笨比填太好让它炸了
timeout不需要 dialer自带

[RPRX]

自定义 timeout 什么的主要是减少特征吧，不然现在这功能直接就能 release 了

for testpre 里面 go 就行了

[Fangliding]

为啥要自定义timeout 这和普通的连接是一个超时机制啊 下面的transport基本都设置为 Chrome行为了

[RPRX]

忘了下面的 transport 还有超时，那没事了

改成 for testpre，加一下 sleep 吧

[RPRX]

err我想过了 遇到就让worker死掉 用用户的下一次请求来唤醒 熵更高 还不会出现断网静置反复尝试的问题

我也是这么想的 https://t.me/projectXray/4492708 不过 #5270 (comment)

遇到半小时一次的连接观测的话会直接失败，这块还得想想

[RPRX]

@Fangliding 帮忙 rebase 一下

[majorcheng]

xhttp是不是可以配合downloadSetting中设置"maxConcurrency": 1

[RPRX]

xhttp是不是可以配合downloadSetting中设置"maxConcurrency": 1

https://github.com/XTLS/Xray-core/releases/tag/v25.10.15 已经默认了

[majorcheng]

xhttp是不是可以配合downloadSetting中设置"maxConcurrency": 1

https://github.com/XTLS/Xray-core/releases/tag/v25.10.15 已经默认了

那pre-connect的testpre和"maxConcurrency": 1放一起的话，效果会是？

[RPRX]

那pre-connect的testpre和"maxConcurrency": 1放一起的话，效果会是？

没必要啊，XHTTP 复用后本身就是实际上 0-RTT