Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

建议 Xray 支持 Hysteria 协议 #3547

Closed
TrayBer opened this issue Jul 17, 2024 · 26 comments
Closed

建议 Xray 支持 Hysteria 协议 #3547

TrayBer opened this issue Jul 17, 2024 · 26 comments

Comments

@TrayBer
Copy link

TrayBer commented Jul 17, 2024

先说一下我的理由:

1、翻墙协议不是“N选1”,而是“N选多”
有时候某种翻墙方式被阻断,可能并不是这个协议“被识别、破解、针对了”,而仅仅是 GFW 怀疑你流量可疑,或者干脆是特殊时期一刀切;多一种协议支持,意味着翻墙行为多一点存活的概率。

2、翻墙成本开销
我没有刷 4K 视频的嗜好,能正常收发 Gmail、刷刷 Twitter、看看 720p 的 YouTube 视频,我就心满意足了。我使用 VPS 自建节点(成本在40美元/年),但是 IP 被封是常见的事情,天天换 IP 根本不现实,所以挂 Cloudflare 是必然选择。但后果就是晚上网速非常慢,看YouTube 视频更是不用想。而 Hysteria2 则解决了这个问题,让我很烂的 VPS 也可以在晚上发挥作用。

那我为什么没有选择在自己的 VPS 上仅使用 Hysteria2 协议,而仍然在使用 Xray 提供的协议(例如 Trojan、VLESS、VMess)?因为不管使用哪种协议都存在被阻断的情况,而被阻断时,我切换到另一个协议,可以保证网络正常可用。

我还是那个观点,多种协议的存在,是为了保证翻墙连接存活的概率,而不是为了证明哪个协议更强大。在经费充足、团队专业、针对性研究上,任何个人、小团体的翻墙协议在 GFW 面前都不堪一击。就算你协议牛逼,GFW 无可奈何,不是还可以请协议的开发者喝茶么(Shadowsocks 就是活生生的案例)。

关于 Hysteria 协议是否存在过度占用带宽的说法,实际体验是,流量大了,任何协议都扛不住阻断。况且个人宽带本身就有上传、下载限速。长期跨境大流量使用,运营商自然会特别关照这个宽带用户。除了 GFW,各运营商的“墙中墙”普遍存在,翻墙实际上是非常困难的一件事——至少相比5年前、10年前。因此,翻墙协议、工具的设计,带宽流量占用不应该是主要考虑的因素,因为有太多因素可以把大流量掐断。

下面是我翻看 Xray、Hysteria 协议作者的讨论,希望 RPRX 能够再次考虑这一提议。
#2635 (comment)

@Fangliding
Copy link
Member

Fangliding commented Jul 17, 2024

dup
pr welcome(或许)

@Fangliding Fangliding closed this as not planned Won't fix, can't repro, duplicate, stale Jul 17, 2024
@TrayBer
Copy link
Author

TrayBer commented Jul 17, 2024

issue 开了 10 分钟就关闭了,没必要这么急嘛。
希望两位作者能够关注,感谢!
@RPRX
@tobyxdd

@RPRX
Copy link
Member

RPRX commented Jul 17, 2024

之前有人建议加 Hysteria 时我说得很清楚是 还需观望,并且给出了两点理由:

一是作为主流代理软件的 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 类代理。

@RPRX
Copy link
Member

RPRX commented Jul 17, 2024

我就知道会有人说 Hy 可以不用 Brutal 而用 BBR,那有没有一种可能这些想让 Xray 加 Hy 的人实际上就是想让 Xray 加 Brutal 而不是 BBR,你只有 BBR 人家乐意用吗?人家都说了“让我很烂的 VPS 也可以在晚上发挥作用”。无语了,帮忙转发到频道 comments。

@RPRX RPRX pinned this issue Jul 17, 2024
@RPRX
Copy link
Member

RPRX commented Jul 18, 2024

又看到有个评论是“但是垃圾线路的小鸡只有hy2跑的动”,只能说是眼前一黑,完全没看我写了啥,大概这就是 from endest user 吧

@RPRX
Copy link
Member

RPRX commented Jul 18, 2024

我看到你的理由包括“让我很烂的 VPS 也可以在晚上发挥作用”,但你大概没有想过这样的代价其实是其它协议、其它流量在晚高峰的体验更差,并且最后一个坚守的软件 Xray 加了 Brutal 后晚高峰就等着一起爆炸,你的这个理由就不复存在。

这段加粗了,endest user 直接看这段就行垃圾线路同理,一个人用 Brutal 会导致其他人的体验更差,最后大家都用就一起爆炸

@RPRX
Copy link
Member

RPRX commented Jul 18, 2024

是在隔空回复 https://t.me/projectXtls/239 下面的一些评论,321,上链接!

https://t.me/projectXray/3765445 我记得 hy2 可以指定使用 bbr 算法 而不是 brutal

https://t.me/projectXray/3768645 但是垃圾线路的小鸡只有hy2跑的动

@RPRX
Copy link
Member

RPRX commented Jul 19, 2024

垃圾线路同理,一个人用 Brutal 会导致其他人的体验更差,最后大家都用就一起爆炸

但我又想了一下,我在干什么,“很烂的 VPS”指的不就是“垃圾线路”吗,虽然可能 VPS 本身也烂

@tomxiang1
Copy link

R佬的观点主要停留在 1、国际出口小而不够用。2、人人都用Brutal 体验下降出口会炸掉。
第一点,国际出口小而不够用是一个偏见。四大运营商都有自己的出口,并且在不段增长,如果你不用,或者说怕用满,运营商也没动力去增加出口。所以国际出口的大小不是我们个人操心的事。
第二点,人人都用Brutal 体验下降出口会炸掉,其实Hy作者说得很清楚,在丢包时会补偿提高发包率,但补偿也是有限的也就10%,该丢还是得丢,Best-effort delivery "尽力而为"。
个人觉得,个人用户使用都不会7*24小时最大下载或上传,在晚高峰时BBR就等于是你让我,我让你,多个和尚没水喝的境地。反而Brutal做到了Best-effort delivery ,实在不行该丢包还得丢包,尽力而为。

@Fangliding
Copy link
Member

Fangliding commented Jul 25, 2024

Fangliding added #from_end_user label 2 hours ago

@RPRX
Copy link
Member

RPRX commented Jul 26, 2024

Fangliding added #from_end_user label 2 hours ago

楼上这种还能进行技术性分析的(尽管是瞎扯)还不够 end,真正的 end user 是“我不懂技术,我只知道我的小鸡只有 Hy 拉得动”

@tomxiang1
Copy link

Fangliding added #from_end_user label 2 hours ago

楼上这种还能进行技术性分析的(尽管是瞎扯)还不够 end,真正的 end user 是“我不懂技术,我只知道我的小鸡只有 Hy 拉得动”

Hy主要有两大特色,1、Brutal算法,使用尽力而为的原则,尽量争取到国际出口。2、端口跳跃,由于H3底层传输用到了upd协议,udp在国内四大运营商的网络中都不受待见,如果长时间大流量就会被Qos或短暂阻断。Hy利用了H3中的连接迁移特性,可以自定义时间更换底层udp连接而上层业务不中断,五元组中的端口改变后就不会触发本地运营商Qos或阻断策略。
最后诚请R佬可以考虑在Xray的底层传输协议QUIC或SplitHTTP中的H3增加端口跳跃特性,感谢!

@XTLS XTLS deleted a comment from us254 Jul 26, 2024
@XTLS XTLS locked as off-topic and limited conversation to collaborators Jul 26, 2024
@RPRX
Copy link
Member

RPRX commented Aug 1, 2024

这个咋 locked 了,这样不好,Project X 一向允许大家说话,即使偶尔会有傻逼

要以理服人而不是以权服人

@XTLS XTLS unlocked this conversation Aug 1, 2024
@RPRX
Copy link
Member

RPRX commented Aug 1, 2024

在晚高峰时BBR就等于是你让我,我让你,多个和尚没水喝的境地。

虽然但是,不好意思,笑出声了

@RPRX
Copy link
Member

RPRX commented Aug 1, 2024

不要移到 discussion,放在 issue 区更直观

@AsenHu
Copy link
Contributor

AsenHu commented Aug 1, 2024

在晚高峰时BBR就等于是你让我,我让你,多个和尚没水喝的境地。

BBR 拥塞控制不会像你所说的这样。在(大多数 Linux 内核可以使用的)BBRv1 中,ProbeBW(探测最大宽带)阶段其实在一定程度上会抢占宽带,同时 BBRv1 其实降低发包速率不够激进(比如不会因为丢包降速),所以 BBR1 实际上并不会把宽带都给让出来。

你所谓的这种情况,更像是古早的 Reno 干的事(遇到丢包发包速率减半)

@Fangliding
Copy link
Member

这个咋 locked 了,这样不好,Project X 一向允许大家说话,即使偶尔会有傻逼

要以理服人而不是以权服人

因为我删的那条过于yygq的 觉得再搞下去没啥意义了(

@Leao9203
Copy link

Leao9203 commented Aug 14, 2024

希望百家争鸣,但不是全家桶

希望百家争鸣,而不是一拖N

@axinhouzilaoyue
Copy link

简单来说,Brutal破坏了带宽使用的公平性
用更高的发包速率降低丢包的影响,对局部来有利的。但对网络整体,带来了更重的负担

举一个形象的例子:

十字路口,南北向 的车不遵守红绿灯,尽可能的通过路口,这会让南北向通过更多的车。但是,也会挤占 东西向 车的通过;
如果 南北向、东西向 的车都不遵守红绿灯,导致严重堵车。最后导致整体车流速度下降。

Brutal就是不太遵守红绿灯的情况

@ll11l1lIllIl1lll
Copy link
Contributor

怎么从 Closed 挖坟

@ghost
Copy link

ghost commented Oct 13, 2024

二是当时并不清楚 GFW 会如何对 QUIC 动手,不妨等 GFW 开始封锁、协议迭代后再加一个真正能 anti-censorship 的协议,不然我们刚加一个协议就被 GFW 封了也是挺浪费时间精力的。昨天 GFW 开始大规模封锁 UDP 类代理,看了一些讨论是 UDP 流量一大就会被封且不仅限于 Hy,这下和第一条对上了又预言上了,所以在这个时间点又建议加 Hy 是怎么想的,really?

大佬,今天我研究hysteria2的时候发现brutal的流量特征可能也许大概应该有……不敢说……
主要就是流量严格的和(1-丢包率)成反比……因为其流量速率要求保持相同……

再加上其基于QUIC的流量,判别……感觉……还是不敢说……

我不确定,因为很多视频流也会这样的流量发送……来保证流量速率。但是境外流量+quic+这个反比流量……可能有一点流量特征吧,感觉没几个协议用,再加上特别关照一下什么SNI长链接流量之类的就可以直接……

唉,还是不敢说……

我就是一个没有任何知识的高中生,对RPRX大神充满敬仰,闲暇时间随便看看流量特征这种东西……
语言表达很差,发现的99%是错的……请各位原谅……

而且似乎hysteria的封锁8月测试了一通……似乎误封锁率很高……现在应该还在测试

不知您觉得uquic怎么样……

如果我是错的把我删帖吧……对不起浪费您的时间……

@digitalhivehub
Copy link

digitalhivehub commented Oct 25, 2024

作为 Hysteria 1 就在用的老用户,从今年10月开始,使用体验明显下降了,成都电信应该是开始在qos或者识别阻断了,我本身未开启 Brutal,也对所谓的跑满速不感兴趣,主要诉求还是稳定,现在 Hysteria 知名度上去了,用的人多了,反而不是一个稳定的选择,Xray 不支持是对的,至少是延迟处刑 Hysteria

@aawwsslll
Copy link

作为 Hysteria 1 就在用的老用户,从今年10月开始,使用体验明显下降了,成都电信应该是开始在qos或者识别阻断了,我本身未开启 Brutal,也对所谓的跑满速不感兴趣,主要诉求还是稳定,现在 Hysteria 知名度上去了,用的人多了,反而不是一个稳定的选择,Xray 不支持是对的,至少是延迟处刑 Hysteria

我这边用了测速很一般,相比vless并没有什么优势,而且上传是很明显不如vless,果断还是用vless了。

@vxtls
Copy link

vxtls commented Dec 9, 2024

作为 Hysteria 1 就在用的老用户,从今年10月开始,使用体验明显下降了,成都电信应该是开始在qos或者识别阻断了,我本身未开启 Brutal,也对所谓的跑满速不感兴趣,主要诉求还是稳定,现在 Hysteria 知名度上去了,用的人多了,反而不是一个稳定的选择,Xray 不支持是对的,至少是延迟处刑 Hysteria

我这边用了测速很一般,相比vless并没有什么优势,而且上传是很明显不如vless,果断还是用vless了。

这两个底层就是不一样的,一个TCP,一个UDP,UDP有的时候被QoS当然慢

@xtccc
Copy link

xtccc commented Dec 14, 2024

建议使用 https://github.com/sduoduo233/brutal-nginx
我目前用着挺好,既有hy的打开网站低延迟,又有xray的跑满带宽。
有人想用我回头把编译出的 ngx_http_tcp_brutal_module.so 分享一下

@richgk999
Copy link

我是在VPS中跑两个服务,一个XRAY,一个HY2,没有感觉有多大区别。现在一个XRAY配了XHTTP、REALITY、MKCP,这两年VPS还算稳定,没有封IP,最多有时封了端口,过段时间就放了。这两天配XHTTP,过CF,昨天死活不通,就是能到NGINX,无法到XRAY,看了基础知识,将MODE改为PACKETUP,一下就通了。感谢RPRX!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests