XTLS
Xray会支持歇斯底里2么？
目前来说 Hysteria 等协议的目标是 通过激进的发包策略来提升弱网环境的代理可用性，但是有以下缺点：
- 激进发包其实就是抢资源，会弱化其他人的体验，如果大家都用，那只会更爆炸
- 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议
所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，~~反正预言是放这儿了~~
目前来说 Hysteria 等协议的目标是 通过激进的发包策略来提升弱网环境的代理可用性，但是有以下缺点：
- 激进发包其实就是抢资源，会弱化其他人的体验，如果大家都用，那只会更爆炸
- 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议
所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，~反正预言是放这儿了~
讲究，点赞！
-
Hysteria 发包是否 "激进" 仁者见仁，不过绝对不是多倍发包（这个我相信 RPRX 知道，只是为了和路人强调下），详细的解释可以看这里 https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ 。我的观点是用户使用运营商承诺的带宽发包，没有破解限速就是合理的。至于拥塞控制即使是 TCP 不同的操作系统和配置也不同，BBR 也是在 "弱化 Cubic 的体验"。而且互联网上天然就有很多流量没有拥塞控制，比如联机游戏可不会因为延迟和丢包率高而降低 tickrate。
-
Hysteria 还是特意注意没有魔改 QUIC 基本协议层的东西的，毕竟还要作为普通 HTTP/3 server 处理浏览器请求。行为上应该和其他用 quic-go 实现的 HTTP/3 web server (比如 caddy) 一致。当然往深了说目前各种 QUIC 实现都是有细微差异的，像 quic-go, quiche, quinn, ngtcp2, neqo 在默认参数和行为上都不完全相同，如果一定要把服务端用的是什么库本身作为特征的话应该是可以的。但是正如你所说 "尚不清楚 GFW 会如何针对性封锁这些协议"，我不想提前修改，偏离 quic-go 而 potentially 造成新的特征。如果 GFW 真的能够针对性封锁了，我相信只要不是白名单或者完全封锁了 UDP 流量都是能解决的。人固有一死但是今天的饭还得吃
另外 RPRX 发了这个回复以后我看到两边的用户群都开始有站队的现象，我想声明一下我十分清楚 RPRX 的目的只是技术讨论，没有任何 "攻击 Hysteria" 的意思。无论是否加入 Hysteria 我都会继续支持 RPRX 和 Xray 这个项目。no hard feelings
- Hysteria 发包是否 "激进" 仁者见仁，不过绝对不是多倍发包（这个我相信 RPRX 知道，只是为了和路人强调下），详细的解释可以看这里 https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ 。我的观点是用户使用运营商承诺的带宽发包，没有破解限速就是合理的。至于拥塞控制即使是 TCP 不同的操作系统和配置也不同，BBR 也是在 "弱化 Cubic 的体验"。而且互联网上天然就有很多流量没有拥塞控制，比如联机游戏可不会因为延迟和丢包率高而降低 tickrate。
- Hysteria 还是特意注意没有魔改 QUIC 基本协议层的东西的，毕竟还要作为普通 HTTP/3 server 处理浏览器请求。行为上应该和其他用 quic-go 实现的 HTTP/3 web server (比如 caddy) 一致。当然往深了说目前各种 QUIC 实现都是有细微差异的，像 quic-go, quiche, quinn, ngtcp2, neqo 在默认参数和行为上都不完全相同，如果一定要把服务端用的是什么库本身作为特征的话应该是可以的。但是正如你所说 "尚不清楚 GFW 会如何针对性封锁这些协议"，我不想提前修改，偏离 quic-go 而 potentially 造成新的特征。如果 GFW 真的能够针对性封锁了，我相信只要不是白名单或者完全封锁了 UDP 流量都是能解决的。人固有一死但是今天的饭还得吃
另外 RPRX 发了这个回复以后我看到两边的用户群都开始有站队的现象，我想声明一下我十分清楚 RPRX 的目的只是技术讨论，没有任何 "攻击 Hysteria" 的意思。无论是否加入 Hysteria 我都会继续支持 RPRX 和 Xray 这个项目。no hard feelings
我也已经用上hysteria2了。使用的是官方的docker-composer.因为是全docker配置，和xray也是共存使用。我觉得是互补的选项。我的线路大部分时候都挺好的。在线路状况正常的情况，reality对比hys2的速度。目前看都差不多的。我打算试一试有时候晚高峰拥堵的时候的对比。
总体来说，挺好。我觉得，技术，就应该百花齐放。
software anti-pattern
mature protocol/software should not include/bundle other mature protocol/software directly; this is an ant-pattern
The focus should be on innovation, performance and less bugs rather then making a God Class (OOP anti-pattern) like tools Hy2 should not add vless Xray should not add hy2
there are tools got overwhelmed by users requests do so and most of them (as long as I know and tested) became more unstable
examples
take Softether4/5 for example instead of refactoring/improving their API they added WireGuard and who is using wg of SE! there ovpn and SSTP are good but their API are buggy for years I love SE but it is hard to work with their API
the right solution
If still you feel doing so it should be based on architectural design like micro-kernel architecture to add/remove plugins/modules. Bundling different protocols/tools into one giant software is an anti-pattern and it is not about proxies, you can look at jira by atlassian which experts are running away from and meanwhile WordPress with its countless plugins allows easy integration (please note that I do not talk about code quality, since some rush to say WP is insecure, etc)
exclusion
Tools like Clash and sing-box which bundling others protocols are exception, their motive were doing so at the beginning Even thought they are doing it well since they lack plugin-based design, further developments become exponentially expensive . e.g how long does it take to support XHTTP in sing-box (?)
integration
The people motivation are usually to have a unified interface under a single tool which leads to coupling (anti-pattern) while if integration is desired it should be with abstract interfaces like REST APIs decoupling (pattern)
For example recently I tired to use SS in singbox using SSM API while I had some users on HY2, People feel so good to have HY2 bundled directly into sing-box right ? Yes it feels right but actually wrong mindset. I used http auth of HY2 itself to authenticate users from SS in sing-box
[hy2 client auth] ===> [ hy2 ] <===> [singbox(ss)]
|
[ss client auth] ======================+
in this model HY2 stays up-to-date, bugs are fixed faster, etc and the same for sing-box (sing-box does not need hy2 server side ==> less code ==> more time on core development)
Real users need
We have learned that in SDLC and Agile most user stories (user needs) are shorted-goal, emotional, and biased and PM should not get overwhelmed; instead their focus should be on correct architecture design, long-goal while open-minded for adoption.
final thought
- a built-in authentication module standardized across any modern proxies so they can speak to each other
- a built-in remote auth module (core server side) to communicate with other cores
- dropping support for any other core server-side protocols (e.g hy2 -server in xray, vless-server in hy2) YAGNI principle
- it is okay to support client-side part (hy2-client in xray, sb, clash, etc)
- plugin-based integration for bundlers and decoupled interfaces for communication between different protocols/tools server side (And all are possible through standardization and tools mainaters cooperation)
@shakibamoshiri 我部分支持你的看法，比如说我觉得对 Xray-core 来说，相比于努力引入一个又一个不同的协议但随着时间的推移、后续维护乏力等原因导致跟不上新版本，不如专注于把 VLESS 打造成全场景覆盖的协议并认真维护，显然性价比更高、更可持续
但是有两个例外，一是过于通用的协议，二是 Xray 出站会加被机场普遍使用的协议，Hy2 就属于这种，并且被 Q 麻了危害也不大了
definitely I am not at that point advising/recommending you or any core developers. @RPRX
What I know is that mistake in architectural design decision gets exponentially expensive afterwards. I can share some examples here
good design decision
hy2
- hooks
- notification support? do it yourself
- user management support? do it yourself
- yaml config (JSON is a machine readable markup, YAML is a human readable markup)
- remote auth (third-party auth support? do it yourself)
or
- ocserv hooks
- notification support? do it yourself
- user management support? do it yourself
bad design decision
Hopefully I do not offend any hard work done to this project and just mention one example.
To me adding WireGurad into Xray/SE5 (or any others) is like adding MS powershell into Linux distros. You are modern rule based proxy (the best one) yet adding something that never designed to pass FWs and meanwhile WireGuard developers are so focused to core minimal design that tun interface is created by iproute2 package not WireGuard code
We already know unseasoned developers feel great when their code-base gets larger while seasoned ones feel great when theirs gets smaller (less is more) so lets take look at hooks for example
if a proxy does not have a hook
the developers are bombarded with
- how to measure traffic
- how to notify admins
- how to disallow mutil-user-login
- etc, AND
- please add X, Y, Z to do so (measure traffic, etc)
- accept this PR for X, Y, Z to do so (measure traffic, etc)
and eventually who is paying for all these unnecessary cognitive loads ? the core developers time and mind
if a proxy has a hook
you simply say , here is the API, read the doc, do it yourself, done.
This is what I did myself for hy2 and ocserv, I am using their hooks to manage users
Essentially I am saying core developers should not directly take any shoulders for something that others can do/maintain/debug/etc yet design interfaces so others can interact with their software.
I cannot innovate protocols to penetrate GFW but I can work with hooks, with API, etc so why your time and mind are spent for something less important.
here is an example of a good interface and standard one modern proxies have (socks5 or http)
People are asking to support built-in tun while Xray has socks5 inbound (good design decision) thus external tools like tun2socks (Go) or hev (C) + iproute2 can solve the problem. Therefor any request for adding built-in tun can be replied with
- use a tun2socks layer
- use iproute2
- or
- you can fork the repo
- make a new tool or a custom one that has build-in
tun