Telegram
世界 in Project X
这下又批评起 hy 了？刚才还扯虎皮说人家时序检测是跟你一起写的呢
https://t.me/projectXray/3787906
我对 Brutal 的看法从来没变过，如果你觉得有批判，我觉得重点并不是 hy 而是满嘴说别人滥用 cdn 但自己连 Brutal 的都加的某人吧。opengfw 最初对 trojan 的检测是基于 trojan-killer 也是独立的客观事实，且我不觉得和 hy 作者有什么过节，而不像某人从来没有学会过就事论事。
https://t.me/projectXray/3787939
事实就是 Brutal 并没有开启新的 anti-censorship 路径，而是在已有路径上抢占带宽、弱化其他人的体验，与 SplitHTTP H3 完全不同，某人又在装傻弄混。
https://t.me/projectXray/3787939
👍19❤1👀1
Telegram
世界 in Project X
确实完全不同了，你能被检测 brutal 不能
https://t.me/projectXray/3788116
我真的不知道他是怎么打出这句话的。世界的逻辑：quic-go 可被检测，可用 Browser Dialer 和在准备 uQuic 的 splithttp 完了，只用 quic-go 的 hysteria 赢！更别说那个文章标题就是 hy 且 hy 最近大规模被封，睁眼说瞎话的能力始终一流，我实在是觉得和他讨论任何事情都是浪费时间，真的没有必要，他还很自豪让我在频道发了这么多言，没看到平时我在 GitHub 的活跃。对了防止你狡辩，Brutal 本身也是一种特征。
https://t.me/projectXray/3788108
QUIC 过 cdn 是一种新的 anti-censorship 路径，就像当年的 ws，下行发包取决于 cdn 且我相信人家没开 Brutal，你明确写了“我就是要占多少带宽”这才叫“抢占带宽”，不然什么都别用了。
https://t.me/projectXray/3788108
👍8
Telegram
⚡ in Project X
sb内核作者和xr内核作者在吵架？
https://t.me/projectXray/3788382
千万别，说吵架是抬举他，你看记录他完全就是在发泼，不讲道理的，也就仗着大多数人不懂不好评价，他每次都是这样。
https://t.me/projectXray/3788456
所以我就说是浪费时间嘛，揪着大家本就知道与浏览器特征不同的 quic-go 不放而故意不看 splithttp 能用浏览器转发，已经说了很多遍了不想再说了。他没有什么能挑刺的就又开始攻击又是 ppt 又是 pr 了，其实我说过 22 年就设计了类似的东西，当时对这里绝望了所以没有露面，不然你觉得我是怎么在 pr 中狠狠建议修改的？而且我始终是在一边画饼一边填坑并且我自己写的代码也不少，我觉得你从这个角度攻击属实是没活了。
https://t.me/projectXray/3788456
👍14❤1
Telegram
世界 in Project X
田忌赛马专家，trojan 被你虚空检测的时候怎么不提可以用浏览器转发，不会是因为速度又慢又不稳根本没人用吧
https://t.me/projectXray/3788726
首先 trojan 大规模被封是事实，其次我写的检测是针对时序特征而不是 client hello 指纹你换指纹没用，最后 trojan 不基于 http 用不了浏览器转发。如果你再发泼发表这种错误百出的言论我会视你为傻子并且不再回复。
👍12
Telegram
世界 in Project X
首先 udp 大规模被封是事实，你赢了好几天的协议能被检测了也是事实，其次你写的就是个长度检测别碰瓷别人 opengfw 了，最后 trojan 和 vless 一样都是二进制协议，能用浏览器转发的是传输层协议，还在装傻
https://t.me/projectXray/3788824
首先 UDP 大规模被封的是直连而套 cdn 是条新路，其次 opengfw 最初都在 readme 中写了基于 trojan-killer 你是眼瞎吗？最后你现在能给我用浏览器转发 trojan 连上 trojan-gfw？人家本来就没有设计这些。
由于他修改了评论我也补充两句：被检测的是 quic-go，然而人们早就知道它和浏览器特征不同，所以在 Xray 你可以选 Browser Dialer 或 uQuic。trojan-killer 检测的是时序特征，他没看代码硬说只是首包长度。
👍13
Telegram
世界 in Project X
同样的协议原来墙还会不封 CDN IP 原来还能这么编，自己眼瞎还说别人事实性错误，改别人 v2ray 协议的时候怎么不说别人没有设计
https://t.me/projectXray/3788944
https://t.me/projectXray/3788951
套 cdn 不就是仗着 gfw 不轻易封 cdn 吗？你该不会以为 ws 还能苟活是 gfw 不能识别、直连也不封吧？Browser Dialer 就是设计出来结合我的协议用的不然你以为呢？浏览器转发速度是会有折扣但不会连不上，建议你自己用过再说，还有下个版本 uQuic 就来了你急什么啊？
https://t.me/projectXray/3788951
🔥19😁5❤4
Project X Channel pinned «Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.21 SplitHTTP for HTTP/3, the last hope of *ray's QUIC 总之，SplitHTTP H3 是第一个完全基于标准 H3、支持套 CDN 的 QUIC 类代理，亦可用反代、Browser Dialer 来隐蔽自身。 毫无疑问，SplitHTTP H3 已经开启了一个崭新的时代。»
甚至人家写的是 hy2 检测器，经风扇研究对 splithttp 无效，世界不去锐评自己加了的 hy2 反而拿来冲 Xray，反正对世界来说重点从来都只是攻击 Xray 发泄情绪，什么借口并不重要，这也就是他总是能说错一个事实就当无事发生、换个借口继续攻击的原因。
😁45👍8
真的别说什么相爱相杀，我只感到恶心，从来都只有世界冲 Xray，甚至还连续写了两篇小作文，我可没主动对他干过啥。怪不得去年他说 TiT 是炒作，还在 GitHub 和频道闹出了一堆暴露水平的笑话，今天才知道他连 trojan-killer 的代码都没看过，就这还“技术细节”？去年和世界“私聊”时他甚至把我的所有动作都批判了一遍，加上今天的事情，我只觉得这个人的心理已经极度扭曲。
https://t.me/projectXtls/200
https://t.me/projectXtls/200
Telegram
Project X Channel
To 6：对啊，我也是这么想的，各玩各的、互不干涉不好吗？但他非要当什么审判法庭，天天盯着我找茬，把我从 2020 年开始的每个动作都批判一遍，我有什么办法😅
😁63👍11👀4❤2🔥2🎉2
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.
👍26🔥7⚡1👀1
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.
⚡21👍5❤4🔥1👀1
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.
❤27👍4
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.
👍14⚡2❤1
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 以减少特征。注意：服...
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！
🎉112👍16⚡3❤2👀2
Project X Channel pinned «Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.23 优化了 SplitHTTP 上行的稳定性，服务端必须升级到该版本以支持新版客户端。 恭喜 mmmray 贡献了 Xray-core 的第 1000 个 commit！»
👀51😁10❤4👍4🔥4