Forwarded from GitHub
💬 New comment on Xray-core#3547 建议 Xray 支持 Hysteria 协议
by @RPRX
之前有人建议加 Hysteria 时我说得很清楚是 [还需观望](https://github.com/XTLS/Xray-core/issues/2635#issuecomment-1761217856)，并且给出了两点理由：
一是作为主流代理软件的 Xray 一加，大家一用 Brutal，公网会炸，而且大家都用了就是无意义内卷体验比现在还差并没有利好谁，仅此而言就不应当加 Brutal。我觉得责任感还是比市占率更重要，Xray 不会为了市占率而抛弃作为主流代理软件的责任感去加这样的东西，后来好像是 TCP 作者之一也在推上表达了类似的观点。本质上是这么多年了绝大多数人对协议还是只能看到一时爽而不会去思考大规模铺开的后果，~~我一直有这样的思考是经常当预言家的原因之一~~，就像我经常给伊朗人说不要看到个能用的协议就奔走相告恨不得人人都用上，会凉得很快，~~反正他们也没听过劝就成现在这样了~~。
~~以防有人说：什么责任感？ray 系没用 CDN 吗？我想说这是为了 anti-censorship，这本来就是这些代理软件存在的根本原因。~~
二是当时并不清楚 GFW 会如何对 QUIC 动手，不妨等 GFW 开始封锁、协议迭代后再加一个真正能 anti-censorship 的协议，不然我们刚加一个协议就被 GFW 封了也是挺浪费时间精力的。昨天 GFW 开始大规模封锁 UDP 类代理，看了一些讨论是 UDP 流量一大就会被封且不仅限于 Hy，~~这下和第一条对上了又预言上了，所以在这个时间点又建议加 Hy 是怎么想的，really？~~
我看到你的理由包括“让我很烂的 VPS 也可以在晚上发挥作用”，但你大概没有想过这样的代价其实是其它协议、其它流量在晚高峰的体验更差，并且最后一个坚守的软件 Xray 加了 Brutal 后晚高峰就等着一起爆炸，你的这个理由就不复存在。
最后你附上了 Hy 作者的 回应 说法存在些问题，只是当时出于正好没空、~~社区和谐~~等原因没有再回复，现在评价一下：
首先是 Hy 文档 QA 中也存在的偷换概念问题，“运营商承诺的带宽”并不等于“从你家到境外 VPS 的带宽”，我说这个应该秒懂，**本地运营商最多给你签本运营商的带宽，到境外 VPS 那么复杂的线路可不全是他家的，你一用 Brutal 就是针对整条链路这合适吗？** 即使是本地带宽，要求运营商按签给你们的带宽乘以人头去实际扩容放那里也不现实，因为除了晚高峰它们就是闲置，这是对资源的严重浪费，**何况运营商签给你的普通家宽本就不是长时间拉满独占，所以并不是没有破解限速就是合理的行为，这就是滥用。**
其次就算 BBR 也是在"弱化 Cubic 的体验"，它也懂得退让，所以大家能一起换到 BBR、一起提升体验，而大家一起 Brutal 就会炸。Brutal 并不是传统的拥塞控制，本质上是抢占带宽，至于“联机游戏” UDP 没有拥塞控制，人家又不是为了抢占带宽，流量也不大。
最后就是，我之前提到的“和普通 QUIC 的不同”，就比如 Brutal，GFW 完全可以发现这样的东西就无脑封，~~虽然现在更暴力，UDP 流量一大就封~~。总之以上只是技术性讨论，我认为 QUIC 类代理还是有出路的，并且最终我们会有一些长期可用的 QUIC 类代理。
Reply to this message to post a comment on GitHub.
by @RPRX
之前有人建议加 Hysteria 时我说得很清楚是 [还需观望](https://github.com/XTLS/Xray-core/issues/2635#issuecomment-1761217856)，并且给出了两点理由：
一是作为主流代理软件的 Xray 一加，大家一用 Brutal，公网会炸，而且大家都用了就是无意义内卷体验比现在还差并没有利好谁，仅此而言就不应当加 Brutal。我觉得责任感还是比市占率更重要，Xray 不会为了市占率而抛弃作为主流代理软件的责任感去加这样的东西，后来好像是 TCP 作者之一也在推上表达了类似的观点。本质上是这么多年了绝大多数人对协议还是只能看到一时爽而不会去思考大规模铺开的后果，~~我一直有这样的思考是经常当预言家的原因之一~~，就像我经常给伊朗人说不要看到个能用的协议就奔走相告恨不得人人都用上，会凉得很快，~~反正他们也没听过劝就成现在这样了~~。
~~以防有人说：什么责任感？ray 系没用 CDN 吗？我想说这是为了 anti-censorship，这本来就是这些代理软件存在的根本原因。~~
二是当时并不清楚 GFW 会如何对 QUIC 动手，不妨等 GFW 开始封锁、协议迭代后再加一个真正能 anti-censorship 的协议，不然我们刚加一个协议就被 GFW 封了也是挺浪费时间精力的。昨天 GFW 开始大规模封锁 UDP 类代理，看了一些讨论是 UDP 流量一大就会被封且不仅限于 Hy，~~这下和第一条对上了又预言上了，所以在这个时间点又建议加 Hy 是怎么想的，really？~~
我看到你的理由包括“让我很烂的 VPS 也可以在晚上发挥作用”，但你大概没有想过这样的代价其实是其它协议、其它流量在晚高峰的体验更差，并且最后一个坚守的软件 Xray 加了 Brutal 后晚高峰就等着一起爆炸，你的这个理由就不复存在。
最后你附上了 Hy 作者的 回应 说法存在些问题，只是当时出于正好没空、~~社区和谐~~等原因没有再回复，现在评价一下：
首先是 Hy 文档 QA 中也存在的偷换概念问题，“运营商承诺的带宽”并不等于“从你家到境外 VPS 的带宽”，我说这个应该秒懂，**本地运营商最多给你签本运营商的带宽，到境外 VPS 那么复杂的线路可不全是他家的，你一用 Brutal 就是针对整条链路这合适吗？** 即使是本地带宽，要求运营商按签给你们的带宽乘以人头去实际扩容放那里也不现实，因为除了晚高峰它们就是闲置，这是对资源的严重浪费，**何况运营商签给你的普通家宽本就不是长时间拉满独占，所以并不是没有破解限速就是合理的行为，这就是滥用。**
其次就算 BBR 也是在"弱化 Cubic 的体验"，它也懂得退让，所以大家能一起换到 BBR、一起提升体验，而大家一起 Brutal 就会炸。Brutal 并不是传统的拥塞控制，本质上是抢占带宽，至于“联机游戏” UDP 没有拥塞控制，人家又不是为了抢占带宽，流量也不大。
最后就是，我之前提到的“和普通 QUIC 的不同”，就比如 Brutal，GFW 完全可以发现这样的东西就无脑封，~~虽然现在更暴力，UDP 流量一大就封~~。总之以上只是技术性讨论，我认为 QUIC 类代理还是有出路的，并且最终我们会有一些长期可用的 QUIC 类代理。
Reply to this message to post a comment on GitHub.
👍151❤24😁7🎉3🔥2
Forwarded from GitHub
💬 New comment on Xray-core#3543 (uncompleted) SpiltHTTP: Client Support HTTP/3
by @RPRX
> 这下 Xray 不小心也有了基于 HTTP/3 的 QUIC 类代理
而且还能套 CDN，~~前无古人，遥遥领先，总之就是赢！麻了~~
Reply to this message to post a comment on GitHub.
by @RPRX
> 这下 Xray 不小心也有了基于 HTTP/3 的 QUIC 类代理
而且还能套 CDN，~~前无古人，遥遥领先，总之就是赢！麻了~~
Reply to this message to post a comment on GitHub.
🎉62😁11👍8🔥3👀2❤1
Telegram
风扇滑翔翼 in Project X
gfw也不封ws啊(
而且跑的没ws之类的快也是事实
而且跑的没ws之类的快也是事实
https://t.me/projectXray/3776627
SplitHTTP 的下行很纯粹，原理上速度应该差不多，但 H2 是多路复用会被单 TCP 连接限速，所以多线程测速不如 WSS，而 H3 取决于运营商的 UDP 策略，我这边 H3 似乎比 WSS 快很多，并且 WSS 有时会被阻断。
SplitHTTP 的下行很纯粹，原理上速度应该差不多，但 H2 是多路复用会被单 TCP 连接限速，所以多线程测速不如 WSS，而 H3 取决于运营商的 UDP 策略，我这边 H3 似乎比 WSS 快很多，并且 WSS 有时会被阻断。
😁18👍3❤1🔥1
Telegram
⑥ in Project X
我们对splithttp能跑多少速度其实都不在意的，毕竟协议方式有限制性可以理解。但有人出来标榜能跑300mbps就...
https://t.me/projectXray/3776732
有没有一种可能 SplitHTTP 的下行并没有什么限制性，我这边套 cf 的 h3 确实能跑到三百兆，有的运营商就是 quic 比 tcp 更快，有的则相反，总之希望各位自己实测一下
有没有一种可能 SplitHTTP 的下行并没有什么限制性，我这边套 cf 的 h3 确实能跑到三百兆，有的运营商就是 quic 比 tcp 更快，有的则相反，
🔥17😁4❤3👍1
Project X Channel pinned «Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.20»
GitHub
Release Xray-core v1.8.21 · XTLS/Xray-core
SplitHTTP for HTTP/3, the last hope of *ray's QUIC
正如 v1.8.16 所预告的，SplitHTTP 现已初步支持 HTTP/3（QUIC）。
尽管你可以直接设置并连接 SplitHTTP H3 服务端，但更推荐的做法是 在服务端前套一个反代软件，这样才可以使用 BBR。
当然你也可以套一个 CDN，值得一提的是，在近期的 UDP ...
正如 v1.8.16 所预告的，SplitHTTP 现已初步支持 HTTP/3（QUIC）。
尽管你可以直接设置并连接 SplitHTTP H3 服务端，但更推荐的做法是 在服务端前套一个反代软件，这样才可以使用 BBR。
当然你也可以套一个 CDN，值得一提的是，在近期的 UDP ...
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 已经开启了一个崭新的时代。
SplitHTTP for HTTP/3,
总之，SplitHTTP H3 是第一个完全基于标准 H3、支持套 CDN 的 QUIC 类代理，亦可用反代、Browser Dialer 来隐蔽自身。
毫无疑问，SplitHTTP H3 已经开启了一个崭新的时代。
⚡39🎉20👍5🔥3👀3❤1
😁32🔥5⚡3👀2👍1
Telegram
世界 in Project X
我就不知道一个首包长度是怎么让某些人高潮 trojan 被检测了的，是个人都知道每个 trojan 本来每个实现特征都不同，用户别人一开 utls 多路复用就歇逼了
https://t.me/projectXray/3786927
首先我和 opengfw 写的 trojan 检测器检测的都是时序特征，包含时序而不包含 client hello 指纹，你确定开 utls 有用？其次建议你去给 trojan-gfw 项目 pr 一个多路复用。一个是使用最广泛的原版协议设计上的根本问题，一个是与协议本身关联性不强的问题，有的人就是要装傻弄混。
🔥20😁4👍2❤1👀1
Telegram
世界 in Project X
一个检测首包长度还能时序特征了？时序检测什么时候是你写的了？又开始装傻带节奏
https://t.me/projectXray/3787034
有没有一种可能，我写的检测针对的是“服务端发数据前客户端发的数据量”以及“客户端再次发数据前服务端发的数据量”而不只是“首包长度”，怪不得某人以为不通用，我建议你至少看一下代码再来扯“技术细节”。其次我并没有暗示 trojan 被 gfw 检测，毕竟都不用暗示，是原版 trojan 被大规模封锁后我才放出的检测，既然你觉得它不会被封锁，建议号召大家好用多用。
🔥13😁3👍1👀1
Telegram
世界 in Project X
二极管小作文都不会写了，也就你这种吹自己协议的在乎用户用什么协议，其次我并没有暗示你的协议会被封，是现在 quic 大规模被封，而且 quic-go 又能检测，既然你觉得你的新时代协议不会被封，建议 xray 爱好者多用
https://t.me/projectXray/3787154
我最佩服世界的一点就是至少在 trojan 检测这个话题上每次他被“技术细节”回怼后都能忘掉自己的错误，当无事发生开始顾左右而言他。不过至于你说的 quic 大规模被封，都是直连而 cdn 没什么报告，这下他又要说 abuse cdn 了。
🔥14👀3
Telegram
世界 in Project X
转移话题满分，不是你自己说一个被检测的协议开启新时代吗
https://t.me/projectXray/3787363
我寻思关于 quic-go 的问题我第一条消息就已经说得很清楚了，你自己评论个 trojan 又成我转移话题了。套 cdn 是 anti-censorship 的一种途径，若有必要我甚至还能用微软网盘或任何能跨境传输数据的东西，错的是 censorship 而不是套 cdn，何况 Xray 又不是没有 REALITY 在当直连主力。
👍20👀3🔥1
Telegram
世界 in Project X
还在装傻，不是你刚进新时代一天的新协议被检测了么
https://t.me/projectXray/3787709
我也不知道是谁在装傻，甚至不懂 quic-go 不全等于 splithttp。况且现在的版本就已经有 Brower Dialer 了你可以去用，uQuic 也在推进，都在 release notes 中写得清清楚楚，你又当看不见。关于你觉得滥用 cdn，至少 cloudflare 的梦想是接管互联网上尽可能多的流量，甚至免费给你 warp 当 vpn 来用，我们用的也主要是 cloudflare。哦，不像某些人加了 Brutal 这种不为了 anti-censorship 且连 TCP 发明人之一都批评的东西。
😁25👍3
Forwarded from 064dd86427cf
😁23👍4⚡1🎉1