-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Comments
dup |
之前有人建议加 Hysteria 时我说得很清楚是 还需观望,并且给出了两点理由: 一是作为主流代理软件的 Xray 一加,大家一用 Brutal,公网会炸,而且大家都用了就是无意义内卷体验比现在还差并没有利好谁,仅此而言就不应当加 Brutal。我觉得责任感还是比市占率更重要,Xray 不会为了市占率而抛弃作为主流代理软件的责任感去加这样的东西,后来好像是 TCP 作者之一也在推上表达了类似的观点。本质上是这么多年了绝大多数人对协议还是只能看到一时爽而不会去思考大规模铺开的后果,
二是当时并不清楚 GFW 会如何对 QUIC 动手,不妨等 GFW 开始封锁、协议迭代后再加一个真正能 anti-censorship 的协议,不然我们刚加一个协议就被 GFW 封了也是挺浪费时间精力的。昨天 GFW 开始大规模封锁 UDP 类代理,看了一些讨论是 UDP 流量一大就会被封且不仅限于 Hy, 我看到你的理由包括“让我很烂的 VPS 也可以在晚上发挥作用”,但你大概没有想过这样的代价其实是其它协议、其它流量在晚高峰的体验更差,并且最后一个坚守的软件 Xray 加了 Brutal 后晚高峰就等着一起爆炸,你的这个理由就不复存在。 最后你附上了 Hy 作者的 回应,我 说过 说法存在些问题,只是当时出于正好没空、 首先是 Hy 文档 QA 中也存在的偷换概念问题,“运营商承诺的带宽”并不等于“从你家到境外 VPS 的带宽”,我说这个应该秒懂,本地运营商最多给你签本运营商的带宽,到境外 VPS 那么复杂的线路可不全是他家的,你一用 Brutal 就是针对整条链路这合适吗? 即使是本地带宽,要求运营商按签给你们的带宽乘以人头去实际扩容放那里也不现实,因为除了晚高峰它们就是闲置,这是对资源的严重浪费,何况运营商签给你的普通家宽本就不是长时间拉满独占,所以并不是没有破解限速就是合理的行为,这就是滥用。 其次就算 BBR 也是在"弱化 Cubic 的体验",它也懂得退让,所以大家能一起换到 BBR、一起提升体验,而大家一起 Brutal 就会炸。Brutal 并不是传统的拥塞控制,本质上是抢占带宽,至于“联机游戏” UDP 没有拥塞控制,人家又不是为了抢占带宽,流量也不大。 最后就是,我之前提到的“和普通 QUIC 的不同”,就比如 Brutal,GFW 完全可以发现这样的东西就无脑封, |
我就知道会有人说 Hy 可以不用 Brutal 而用 BBR,那有没有一种可能这些想让 Xray 加 Hy 的人实际上就是想让 Xray 加 Brutal 而不是 BBR,你只有 BBR 人家乐意用吗?人家都说了“让我很烂的 VPS 也可以在晚上发挥作用”。无语了,帮忙转发到频道 comments。 |
又看到有个评论是“但是垃圾线路的小鸡只有hy2跑的动”,只能说是眼前一黑,完全没看我写了啥, |
这段加粗了, |
是在隔空回复 https://t.me/projectXtls/239 下面的一些评论,
|
但我又想了一下, |
R佬的观点主要停留在 1、国际出口小而不够用。2、人人都用Brutal 体验下降出口会炸掉。 |
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或阻断策略。 |
这个咋 locked 了, 要以理服人而不是以权服人 |
虽然但是,不好意思,笑出声了 |
|
BBR 拥塞控制不会像你所说的这样。在(大多数 Linux 内核可以使用的)BBRv1 中,ProbeBW(探测最大宽带)阶段其实在一定程度上会抢占宽带,同时 BBRv1 其实降低发包速率不够激进(比如不会因为丢包降速),所以 BBR1 实际上并不会把宽带都给让出来。 你所谓的这种情况,更像是古早的 Reno 干的事(遇到丢包发包速率减半) |
因为我删的那条过于yygq的 觉得再搞下去没啥意义了( |
希望百家争鸣,而不是一拖N |
简单来说,Brutal破坏了带宽使用的公平性 举一个形象的例子:十字路口,南北向 的车不遵守红绿灯,尽可能的通过路口,这会让南北向通过更多的车。但是,也会挤占 东西向 车的通过; Brutal就是不太遵守红绿灯的情况 |
怎么从 Closed 挖坟 |
大佬,今天我研究hysteria2的时候发现brutal的流量特征可能也许大概应该有……不敢说…… 再加上其基于QUIC的流量,判别……感觉……还是不敢说…… 我不确定,因为很多视频流也会这样的流量发送……来保证流量速率。但是境外流量+quic+这个反比流量……可能有一点流量特征吧,感觉没几个协议用,再加上特别关照一下什么SNI长链接流量之类的就可以直接…… 唉,还是不敢说…… 我就是一个没有任何知识的高中生,对RPRX大神充满敬仰,闲暇时间随便看看流量特征这种东西…… 而且似乎hysteria的封锁8月测试了一通……似乎误封锁率很高……现在应该还在测试 不知您觉得uquic怎么样…… 如果我是错的把我删帖吧……对不起浪费您的时间…… |
作为 Hysteria 1 就在用的老用户,从今年10月开始,使用体验明显下降了,成都电信应该是开始在qos或者识别阻断了,我本身未开启 Brutal,也对所谓的跑满速不感兴趣,主要诉求还是稳定,现在 Hysteria 知名度上去了,用的人多了,反而不是一个稳定的选择,Xray 不支持是对的,至少是延迟处刑 Hysteria |
我这边用了测速很一般,相比vless并没有什么优势,而且上传是很明显不如vless,果断还是用vless了。 |
这两个底层就是不一样的,一个TCP,一个UDP,UDP有的时候被QoS当然慢 |
建议使用 https://github.com/sduoduo233/brutal-nginx |
我是在VPS中跑两个服务,一个XRAY,一个HY2,没有感觉有多大区别。现在一个XRAY配了XHTTP、REALITY、MKCP,这两年VPS还算稳定,没有封IP,最多有时封了端口,过段时间就放了。这两天配XHTTP,过CF,昨天死活不通,就是能到NGINX,无法到XRAY,看了基础知识,将MODE改为PACKETUP,一下就通了。感谢RPRX! |
先说一下我的理由:
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)
The text was updated successfully, but these errors were encountered: