Forwarded from 薄荷
Project X Channel
太好了又是我最喜欢的翻墙协议大作战而且还发生在跨年夜
这就是我要的氛围！没有男/女朋友的打扰一个人躲在卧室被窝里和网友狠狠讨论翻墙协议
😁44⚡2👍1
Forwarded from GitHub
💬 New comment on Xray-core#4226 Reality的设计思路似乎有漏洞
by @RPRX
~~群友想啥呢，谁跟你们一样宅，跨年我肯定出去玩的，跑了，明天再更新 XHTTP 的文章和 v24.12.31 的 release notes~~
Reply to this message to post a comment on GitHub.
by @RPRX
~~群友想啥呢，谁跟你们一样宅，跨年我肯定出去玩的，跑了，明天再更新 XHTTP 的文章和 v24.12.31 的 release notes~~
Reply to this message to post a comment on GitHub.
❤14😁6👍2👀2⚡1
Telegram
Nikita Korotaev in Project X
@RPRX 你打算完成XUDP UoT迁移的文章吗？
## UoT Migration
要解决上文提到的问题，其实很简单：客户端重新连上时，服务端把原来的 UDP 端口还给它就行了。
类似 QUIC 的 Connection Migration，我提出了 UoT Migration 的概念，其最严格的定义为：
被代理的 UDP 来源二元组不变时，若客户端发了起新的 UoT 连接，服务端会将旧连接的下游资源转移给新连接，并关闭旧连接。
1. “下游资源”指的是服务端使用的 UDP 二元组或中转连接。若 UoT 连接断了，服务端需要等一段时间再释放下游资源。
2. 经测试，服务端不一定能及时获知“连接断开了”，所以必须允许新连接直接“抢走”下游资源，这也给了客户端更多的玩法。
可以看出，实现了 UoT Migration，才能真正实现稳定 FullCone。
甚至从某种程度上来说，这才是真正意义上的 FullCone，因为常规的 UDP NAT 并不会让映射关系依附于某条 TCP 的命运。
以上是去年写的其中一小段，我看了下去年还有 10% 就写完了，不过最近太忙了（忙着玩），明年一定
要解决上文提到的问题，其实很简单：客户端重新连上时，服务端把原来的 UDP 端口还给它就行了。
类似 QUIC 的 Connection Migration，我提出了 UoT Migration 的概念，其最严格的定义为：
被代理的 UDP 来源二元组不变时，若客户端发了起新的 UoT 连接，服务端会将旧连接的下游资源转移给新连接，并关闭旧连接。
1. “下游资源”指的是服务端使用的 UDP 二元组或中转连接。若 UoT 连接断了，服务端需要等一段时间再释放下游资源。
2. 经测试，服务端不一定能及时获知“连接断开了”，所以必须允许新连接直接“抢走”下游资源，这也给了客户端更多的玩法。
可以看出，实现了 UoT Migration，才能真正实现稳定 FullCone。
甚至从某种程度上来说，这才是真正意义上的 FullCone，因为常规的 UDP NAT 并不会让映射关系依附于某条 TCP 的命运。
👍27👀3❤2
Telegram
Project X Channel
Boost this channel to help it unlock additional features.
新的一年，v25.1.1 已 release，预计于明天设为 latest（现在的是 v24.12.31）。请 Telegram Premium 用户点一下 boost，以便本频道关闭强制性的 Telegram 广告，都是些野鸡 VPN 广告。
❤71
opensea.io
OpenSea, the largest NFT marketplace
OpenSea is the leading NFT marketplace, and now supports token trading. Welcome to the best place to discover, trade, and create onchain.
本来今天想小改 XHTTP 然后发个新版，结果改得走火入魔了，所以有人买 NFT 吗：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
❤18👀4😁3🔥2⚡1
Telegram
尚能饭 in Project X
xhttp又要改了？这下游支持又遥遥无期了
没改协议，但如果你指的是其它 core 的支持，我压根就没指望他们支持，今年的计划是先加 TUN 再放出新客户端
👍36🔥7👀6⚡3❤2😁1
Telegram
armin in Project X
够了，我们厌倦了所有这些更新，你改变了所有条目，你在寻找什么 rprx
示例：tcNoDelay 当你把它改为穿透时，遇到了什么问题？
示例：tcNoDelay 当你把它改为穿透时，遇到了什么问题？
Removed from channel.
tcpNoDelay 那个选项就没用，看不懂就多学，少来教开发者怎么做事，自从上次我说总有英语 end user 会这样，人家现在翻译成中文了
tcpNoDelay 那个选项就没用，看不懂就多学，少来教开发者怎么做事，自从上次我说总有英语 end user 会这样，
😁41👍7❤1👀1
刚刚看了下 TUN，突然悲从中来，十几年前我还是刚上初中的小屁孩时就用易语言网截写封包挂玩，十几年后又开始研究劫持进程流量，一点进步都没有，我草，之前搞 UDP 时同感，十几年前我就在搞 UDP 打洞和内网穿透，十几年后给你们写 UDP FullCone
👀45❤24😁23👍9⚡3
Telegram
James Anderson in Project X
十几年前我就写增删改查，十几年后我还在写。
那你这太惨了，我小学刚接触电脑就开始写挂，什么挂都写过，懂事了些就开始 C++ PHP JS 增查改删，之后 Go 开始流行我不小心入坑了 v2，现在正值青年天天去夜店玩，我说我是程序员人家都说我反差
😁59🔥11👍1
Forwarded from GitHub
💬 New comment on Xray-core#3272 License issue
by @RPRX
~~经典 License issue~~
我的看法是：
1. SS2022 由于刚出生就赶上了 GFW 对全随机数流量的全面封锁，未能普及，连中转机场都是老 SS AEAD，~~毕竟在某些人眼中自建主流、直连机场主流、国外主流都不算主流协议，就国内中转机场万年 SS AEAD 算主流，至于中转成了什么，也不算主流~~
2. 本能由 Xray 内建实现的 SS2022 却依附于外部依赖，在可维护性上并不妥，并且一直有一些 bug，~~现在更是不给用了~~
3. 所以有人 PR 换成 v2fly 的内建实现会合并，即使只有出站，~~毕竟说白了这协议动不动都没人用~~，这整件事就很无聊、浪费时间
4. 当初有人想更多 sing 的依赖进入 Xray，三个 mux、TUN 什么的，~~这情况就问你爽不爽~~，然而现在有 XMUX，TUN 也快了
Reply to this message to post a comment on GitHub.
by @RPRX
~~经典 License issue~~
我的看法是：
1. SS2022 由于刚出生就赶上了 GFW 对全随机数流量的全面封锁，未能普及，连中转机场都是老 SS AEAD，~~毕竟在某些人眼中自建主流、直连机场主流、国外主流都不算主流协议，就国内中转机场万年 SS AEAD 算主流，至于中转成了什么，也不算主流~~
2. 本能由 Xray 内建实现的 SS2022 却依附于外部依赖，在可维护性上并不妥，并且一直有一些 bug，~~现在更是不给用了~~
3. 所以有人 PR 换成 v2fly 的内建实现会合并，即使只有出站，~~毕竟说白了这协议动不动都没人用~~，这整件事就很无聊、浪费时间
4. 当初有人想更多 sing 的依赖进入 Xray，三个 mux、TUN 什么的，~~这情况就问你爽不爽~~，然而现在有 XMUX，TUN 也快了
Reply to this message to post a comment on GitHub.
👍34❤1⚡1😁1
Forwarded from GitHub
💬 New comment on Xray-core#3272 License issue
by @RPRX
确实挺浅显的：
1. 全随机数就算换成了 v6 也是全随机数，一时取巧而已，即使 IP 封不完也能实时阻断
2. Xray 又不是 Meta，我本来就不喜欢非必要地引入外部库去实现协议，更不会要求人家 GPL 改成 MPL，这也不可能实现
3. **并且我对推动 VLESS 以外的协议的支持没有什么兴趣**，有人 PR 才可能会收
4. 所以入口用 SS2022 的问题，可以等 VLESS encryption 与 Xray 新客户端普及后用 VLESS，**至于非 Xray 客户端，我不关心**
Reply to this message to post a comment on GitHub.
by @RPRX
确实挺浅显的：
1. 全随机数就算换成了 v6 也是全随机数，一时取巧而已，即使 IP 封不完也能实时阻断
2. Xray 又不是 Meta，我本来就不喜欢非必要地引入外部库去实现协议，更不会要求人家 GPL 改成 MPL，这也不可能实现
3. **并且我对推动 VLESS 以外的协议的支持没有什么兴趣**，有人 PR 才可能会收
4. 所以入口用 SS2022 的问题，可以等 VLESS encryption 与 Xray 新客户端普及后用 VLESS，**至于非 Xray 客户端，我不关心**
Reply to this message to post a comment on GitHub.
❤33👍9👀2🔥1
Telegram
ʌɾɪʌ in Project X
You really want my honest opinion?
Please stop releasing updates. Every time you do, I get stressed out, worrying that an important feature might stop working.
(Like the warning message for WebSocket, for example).🫠
Please stop releasing updates. Every time you do, I get stressed out, worrying that an important feature might stop working.
(Like the warning message for WebSocket, for example).🫠
明明能 XHTTP H2/H3 通过 CDN，你自己喜欢守着 ALPN http/1.1 那是你的问题，甚至 stream-one 都有 worker 版本了，全面取代 WS
👍27😁11❤1
Telegram
ʌɾɪʌ in Project X
The main problem is that users don’t update their clients. For example, some are still using v2rayNG 1.6, which is 3 years old, and I can’t force them to update.
Or take someone using Windows 7—they can’t use XHTTP because the newer versions don’t support…
Or take someone using Windows 7—they can’t use XHTTP because the newer versions don’t support…
至少在 XHTTP 全面普及前不会移除 WS，可能永远也不会移除
Xray 做了那么多工作以继续支持 Win7，你给我说不支持？
stream-up 上行由于无下行数据，cf 会掐断，这恰恰是下个版本解决的
你的言论让我想起以前改 FullCone 时短期内有些新问题，就有人喷是 FullCone 专版，都这样鼠目寸光那就真别搞了呗，什么新功能都不会有，守着 ALPN http/1.1 等死
又他妈浪费我时间跟你废话，下次这种傻逼能不能直接给 ban 了
Xray 做了那么多工作以继续支持 Win7，你给我说不支持？
stream-up 上行由于无下行数据，cf 会掐断，这恰恰是下个版本解决的
你的言论让我想起以前改 FullCone 时短期内有些新问题，就有人喷是 FullCone 专版，都这样鼠目寸光那就真别搞了呗，什么新功能都不会有，守着 ALPN http/1.1 等死
⚡24😁6🔥3🎉2❤1
Telegram
W Fang in Project X
一边控制不住自己喷人的欲望，一边愤怒于浪费时间喷人😏👍
确实是这样，主要是因为我没有群的权限不能 ban 人，然后这种消息在那里混淆视听又不能不喷，但是喷完了又发现是浪费时间，发个频道消息给我气得
❤19😁9👍3
Telegram
ʌɾɪʌ in Project X
Alright, fine. I just asked about something simple because I was worried about the future of the project, but now I feel better.
No need to get upset.
No need to get upset.
新东西刚出现会有些问题很正常、会修，且时间长了也会普及，Please stop releasing updates 这种言论哪个开发者看了都想骂你
👍37🎉3❤2