XTLS Vision: Add testpre (outbound pre-connect) and testseed (outbound & inbound)

[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 往返以尽量消除“预连接”的特征

---

934beb2 给 VLESS 出入站加了 testseed，用户可以自行修改 XTLS Vision 的 900 500 900 256 这几个最关键的 padding 相关参数

testpre 和 testseed 都是暂时的配置项，还不完善，功能也有限，这个月内会出正式版的 Seed 并加到分享链接中

Donation & NFTs

Collect a Project X NFT to support the development of Project X!

• TRX(Tron)/USDT/USDC: TNrDh5VSfwd4RPrwsohr6poyNTfFefNYan
• TON: UQApeV-u2gm43aC1uP76xAC1m6vCylstaN1gpfBmre_5IyTH
• BTC: 1JpqcziZZuqv3QQJhZGNGBVdCBrGgkL6cT
• XMR: 4ABHQZ3yJZkBnLoqiKvb3f8eqUnX4iMPb6wdant5ZLGQELctcerceSGEfJnoCk6nnyRZm73wrwSgvZ2WmjYLng6R7sR67nq
• SOL/USDT/USDC: 3x5NuXHzB5APG6vRinPZcsUv5ukWUY1tBGRSJiEJWtZa
• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1
• VLESS NFT: https://opensea.io/collection/vless
• REALITY NFT: https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• Related links: VLESS Post-Quantum Encryption, XHTTP: Beyond REALITY, Announcement of NFTs by Project X

[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]

打住，Close() 的问题已经解决了就别吵了，这 Close() 有没有人调用都不知道

[sqkam]

一个会发送东西的channel只能是唯一的那个发送者关闭 这里通知发送者不再发送不代表发送者立刻就停了 如果发送者迟了一会再被pick会从所有满足条件的select里随机选一个然后往关闭的channel里发送数据最后导致panic 这些破事以前都是遇到过的

那别人是怎么写的呢 别人怎么就能解决 开口你就是骂

[sqkam]

打住，Close() 的问题已经解决了就别吵了，这 Close() 有没有人调用都不知道
好的

[sqkam]

@Fangliding 不过我承认一点， 后面你改的那一版 拿走一个conn 就通知新建一个conn 是好的，这一点我没想到

[RPRX]

哪里需要额外通知，channel 没压进去不就是阻塞了吗，压进去了不就可以继续新建 conn 了吗，你们越搞越复杂

[sqkam]

哪里需要额外通知，channel 没压进去不就是阻塞了吗，压进去了不就可以继续新建 conn 了吗，你们越搞越复杂

他那个写法给了我一个启发，不是像现在这样 就等预连接，开始的时候也不用预热，而是用select 看能不能拿到预连接。没拿到预连接就用正常的连接，同时通知建立一条新的预连接，这个建立的预连接里面也不是for {} ,而是for range n{}, 这样可以避免连接失败还一直dial，同时也能根据网络流量动态开建立预连接的func

[sqkam]

我提个pr 看看

[sqkam]

#5361

[yuhan6665]

Looks good to me！（作为最简实现）
长远来讲 这样的功能应该是广泛有用的 应该考虑如何加给其他协议或者 transport
虽然处理不当可能会增加一点特征 但是作为可选项 而且相比于之前爱好者群友们喜欢折腾的比如 tcp fast open 不管是可维护性 还是安全性都要更优

[RPRX]

其实我给 yuhan 发消息让他看一下 PR 的意思是看一下 #5270 (comment) ，但他似乎没看到

934beb2 给 VLESS 出入站加了 testseed，用户可以自行修改 XTLS Vision 的 900 500 900 256 这几个最关键的 padding 相关参数

testpre 和 testseed 都是暂时的配置项，还不完善，功能也有限，这个月内会出正式版的 Seed 并加到分享链接中

[RPRX]

cadcb47 小细节，ctx = 改为了 ctx :=

[Fangliding]

我捏的时候还专门写了个别的名 生怕不小心给外头盖了

[RPRX]

话说测试下现在的代码能不能用，我懒得测试了，先去发版了

[sqkam]

能用

[sqkam]

vision 和xhttp试过

[chika0801]

vless自己加密+xhttp("maxConcurrency": "16-32")+reality
我看了下说明是写的 但是只适合 Vision 这类有自由 padding 的协议 这套组合用不了vision，我就不测试加了。

vless自己加密+vision+reality

服务端入站也在settings-clients 里面加了"Testseed": [123,421,512,66]，与客户端出站的 "Testseed": [] 不同的值。

都是正常的。

[RPRX]

c123f16 取出来发现是两分钟之前的就直接扔；顺便把等待 200 毫秒改到了 for 的最后，因为我想了一下同时 dial 几个也很正常

Golang channel 应该是先准备好数据再伺机压进去吧，那这个写法就没问题；半小时一次的连接观测不会失败了但吃不到减延迟

[tianlichunhong]

vision 和xhttp试过

大侠，预链接的配置是怎么样的？给个样例学习学习。谢谢！找了好几个链接，没有看到详细该如何配置。