https://t.me/projectXray/3788824
首先 UDP 大规模被封的是直连而套 cdn 是条新路，其次 opengfw 最初都在 readme 中写了基于 trojan-killer 你是眼瞎吗？最后你现在能给我用浏览器转发 trojan 连上 trojan-gfw？人家本来就没有设计这些。
由于他修改了评论我也补充两句：被检测的是 quic-go，然而人们早就知道它和浏览器特征不同，所以在 Xray 你可以选 Browser Dialer 或 uQuic。trojan-killer 检测的是时序特征，他没看代码硬说只是首包长度。
Telegram
世界 in Project X
首先 udp 大规模被封是事实，你赢了好几天的协议能被检测了也是事实，其次你写的就是个长度检测别碰瓷别人 opengfw 了，最后 trojan 和 vless 一样都是二进制协议，能用浏览器转发的是传输层协议，还在装傻
https://t.me/projectXray/3788944
https://t.me/projectXray/3788951
套 cdn 不就是仗着 gfw 不轻易封 cdn 吗？你该不会以为 ws 还能苟活是 gfw 不能识别、直连也不封吧？Browser Dialer 就是设计出来结合我的协议用的不然你以为呢？浏览器转发速度是会有折扣但不会连不上，建议你自己用过再说，还有下个版本 uQuic 就来了你急什么啊？
https://t.me/projectXray/3788951
Telegram
世界 in Project X
同样的协议原来墙还会不封 CDN IP 原来还能这么编，自己眼瞎还说别人事实性错误，改别人 v2ray 协议的时候怎么不说别人没有设计
甚至人家写的是 hy2 检测器，经风扇研究对 splithttp 无效，世界不去锐评自己加了的 hy2 反而拿来冲 Xray，反正对世界来说重点从来都只是攻击 Xray 发泄情绪，什么借口并不重要，这也就是他总是能说错一个事实就当无事发生、换个借口继续攻击的原因。
真的别说什么相爱相杀，我只感到恶心，从来都只有世界冲 Xray，甚至还连续写了两篇小作文，我可没主动对他干过啥。怪不得去年他说 TiT 是炒作，还在 GitHub 和频道闹出了一堆暴露水平的笑话，今天才知道他连 trojan-killer 的代码都没看过，就这还“技术细节”？去年和世界“私聊”时他甚至把我的所有动作都批判了一遍，加上今天的事情，我只觉得这个人的心理已经极度扭曲。
https://t.me/projectXtls/200
https://t.me/projectXtls/200
Telegram
Project X Channel
To 6：对啊，我也是这么想的，各玩各的、互不干涉不好吗？但他非要当什么审判法庭，天天盯着我找茬，把我从 2020 年开始的每个动作都批判一遍，我有什么办法😅
Forwarded from GitHub
💬 New comment on Xray-core#3560 SplitHTTP h3 closes connections abruptly when dialerProxy is used
by @RPRX
> * 多路复用模式，三选一：
> * 复用多少次开新连接
> * 同时最多多少子连接
> * 同时总共多少条连接
想了一下，如下设计 SplitHTTP H2 H3 的多路复用控制更合适
首先基础模式二选一：
- 同时最多多少子连接（concurrency），先把现有连接复用满再开新的
- 同时最多多少条 TCP/UDP “连接”，先开新连接直至占满总数再复用
其次两个限制维度，可以同时生效：
- 一个连接最多被累计复用多少次，默认 0 为不限制
- 一个连接最大存活时间，默认 0 为不限制
最后，以上选项均填范围，Xray 每次随机选择一个确定值，以淡化潜在特征
这样的话原版的第一个“复用多少次开新连接”也能组合出实现，并且提供了更多可能，欢迎大家提出建议，~~不然就这么实现了~~
目前还想到可以在开新流时选择哪条连接的“算法”上做文章，~~不过还没想好，可以以后再 patch~~
Reply to this message to post a comment on GitHub.
by @RPRX
> * 多路复用模式，三选一：
> * 复用多少次开新连接
> * 同时最多多少子连接
> * 同时总共多少条连接
想了一下，如下设计 SplitHTTP H2 H3 的多路复用控制更合适
首先基础模式二选一：
- 同时最多多少子连接（concurrency），先把现有连接复用满再开新的
- 同时最多多少条 TCP/UDP “连接”，先开新连接直至占满总数再复用
其次两个限制维度，可以同时生效：
- 一个连接最多被累计复用多少次，默认 0 为不限制
- 一个连接最大存活时间，默认 0 为不限制
最后，以上选项均填范围，Xray 每次随机选择一个确定值，以淡化潜在特征
这样的话原版的第一个“复用多少次开新连接”也能组合出实现，并且提供了更多可能，欢迎大家提出建议，~~不然就这么实现了~~
目前还想到可以在开新流时选择哪条连接的“算法”上做文章，~~不过还没想好，可以以后再 patch~~
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3560 SplitHTTP h3 h2 multiplex control
by @RPRX
话说去年我升级 XUDP UoT Migration 时不是预告过一个 PLUX 嘛，好像以前只公开过一点，干脆不留悬念了。PLUX 在 2021 年时是一个游戏加速器，UDP 上多倍发包是老生常谈，重点是它能在 TCP 类的流（QUIC 也算）上用：同时开多个连接发相同（但当然有 padding）的包，这样一条 TCP 不小心延迟或丢包甚至断开时其它的还 work，可以极大程度提升在 TCP 代理上打游戏的体验。~~游戏 UDP 包的数据量很小，多倍发也没啥，不是抢占带宽。去年我给还它扩展了些东西但忘了，回头翻翻去年的笔记。~~
~~当然可以说大饼或 ppt 加一，然而 XUDP 是 VLESS 刚出时就画的饼到 Xray 才发布，REALITY 是 2021 初的饼到 2023 初才发布。~~
Reply to this message to post a comment on GitHub.
by @RPRX
话说去年我升级 XUDP UoT Migration 时不是预告过一个 PLUX 嘛，好像以前只公开过一点，干脆不留悬念了。PLUX 在 2021 年时是一个游戏加速器，UDP 上多倍发包是老生常谈，重点是它能在 TCP 类的流（QUIC 也算）上用：同时开多个连接发相同（但当然有 padding）的包，这样一条 TCP 不小心延迟或丢包甚至断开时其它的还 work，可以极大程度提升在 TCP 代理上打游戏的体验。~~游戏 UDP 包的数据量很小，多倍发也没啥，不是抢占带宽。去年我给还它扩展了些东西但忘了，回头翻翻去年的笔记。~~
~~当然可以说大饼或 ppt 加一，然而 XUDP 是 VLESS 刚出时就画的饼到 Xray 才发布，REALITY 是 2021 初的饼到 2023 初才发布。~~
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3560 SplitHTTP h3 h2 multiplex control
by @RPRX
其实就算我经常戏称它们为大饼，隔壁戏称为 ppt，还是与传统意义不同，因为我说的这些设计都是能实现的，而不是虚无缥缈。
不过就像我说过，“Xray-core 一直在按顺序做认为该做的事情”，对于填这些饼我从来没急过，~~该轮到时自然会轮到。~~
最后，祝福。
Reply to this message to post a comment on GitHub.
by @RPRX
其实就算我经常戏称它们为大饼，隔壁戏称为 ppt，还是与传统意义不同，因为我说的这些设计都是能实现的，而不是虚无缥缈。
不过就像我说过，“Xray-core 一直在按顺序做认为该做的事情”，对于填这些饼我从来没急过，~~该轮到时自然会轮到。~~
最后，祝福。
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3560 SplitHTTP h3 h2 multiplex control
by @RPRX
注：PLUX 就是以前提过的 Accelerator 加上 TCP 版后的名字，因为后者名字不显著，前者取名 PLUX 是因为它至少 double 了连接
Reply to this message to post a comment on GitHub.
by @RPRX
注：PLUX 就是以前提过的 Accelerator 加上 TCP 版后的名字，因为后者名字不显著，前者取名 PLUX 是因为它至少 double 了连接
Reply to this message to post a comment on GitHub.
Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.23
优化了 SplitHTTP 上行的稳定性，服务端必须升级到该版本以支持新版客户端。
恭喜 mmmray 贡献了 Xray-core 的第 1000 个 commit！
优化了 SplitHTTP 上行的稳定性，服务端必须升级到该版本以支持新版客户端。
恭喜 mmmray 贡献了 Xray-core 的第 1000 个 commit！
GitHub
Release Xray-core v1.8.23 · XTLS/Xray-core
SplitHTTP Upload Optimization
正如 v1.8.21 所预告的，SplitHTTP 现已引入 scMinPostsIntervalMs 选项，优化了上行的稳定性。
scMinPostsIntervalMs 为客户端独有参数，默认值为 30，即单个子连接内每 30 毫秒 POST 一次，你可以将它设为 10 以降低游戏延迟，或者设为 10-50 以减少特征。注意：服...
正如 v1.8.21 所预告的，SplitHTTP 现已引入 scMinPostsIntervalMs 选项，优化了上行的稳定性。
scMinPostsIntervalMs 为客户端独有参数，默认值为 30，即单个子连接内每 30 毫秒 POST 一次，你可以将它设为 10 以降低游戏延迟，或者设为 10-50 以减少特征。注意：服...
Project X Channel pinned «Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.23 优化了 SplitHTTP 上行的稳定性，服务端必须升级到该版本以支持新版客户端。 恭喜 mmmray 贡献了 Xray-core 的第 1000 个 commit！»
Project X Channel pinned «Announcement of NFTs by Project X https://github.com/XTLS/Xray-core/discussions/3633»
更新了该 NFT（Project X）的第一批赠予名单与数目，剩下的会继续赠送给 Project X 以前、以后的核心贡献者们。
我对该 NFT 的未来充满信心，因为无论如何它都是这些代理软件所发行的第一个 NFT，我已经觉得 75 个放多了，希望不要卖完。
虽然但是，今天 ETH 眼见触底了，现在你可以以八折入手该 NFT，这何尝不是一种首发优惠。
https://github.com/XTLS/Xray-core/discussions/3633
我对该 NFT 的未来充满信心，因为无论如何它都是这些代理软件所发行的第一个 NFT，
虽然但是，今天 ETH 眼见触底了，现在你可以以八折入手该 NFT，
https://github.com/XTLS/Xray-core/discussions/3633
GitHub
Announcement of NFTs by Project X · XTLS/Xray-core · Discussion #3633
Background 自初始创立的近四年来，Project X 几乎是这里仅有的不收任何赞助、不收任何广告，也没有任何“产业”的项目组。 因为我们创立 Project X 的初衷是捍卫人们自由获取与表达信息的基本人权，anti-censorship，do something good，而不是为了任何经济利益，即使我们已经投入了大量的时间精力、所创造的价值更是难以估量，我们也没有从中拿过一分钱...
顺便更新下该 NFT 的销售情况：平均每 100views 会产生一个交易，已售七个，直到加密货币开始大跳水。在我们尚未全力宣传这件事、大多数人还不知道、现在 views 也才近千的情况下，这已经算得上是一个很好的开端，毕竟购买 NFT 相对麻烦，且七百块也不算便宜。总之非常感谢各位的支持！