-
Notifications
You must be signed in to change notification settings - Fork 106
关于quic与hysteria
本作就算使用了hy阻控，依然是纯quic，也就是说，你可以一端用hy阻控，另一端不用。
vs虽然添加了hy阻控的选项，但是并没有使用hysteria的数据头，因为我们内部还是使用的vless进行验证。
就算没有客户端支持vs，也是不要紧的，因为 vs 的quic 使用hy阻控 作为服务端时， 可以加速客户端的下载方向，而这个方向才是最主要的。所以这个模式值得推荐。
就是说，你目前 在手机上 使用 普通的 支持 vless + quic 协议的 客户端，就能连上 我们 vs 的使用 hy阻控 的 服务端。
本质上hysteria既是一个app，又是一个协议，又是一个阻塞控制方式。我们只采用它的阻塞控制。
配置文件请参考 examples/quic.client.toml 和 examples/quic.server.toml
总之就是如下配置
advancedLayer = "quic"
extra = { congestion_control = "hy", mbps = 3000 }
如果不喜欢hy阻控就把extra这行注释掉.
因为我们不使用hysteria协议头，所以没必要区分 上行流量和下行流量, 我们这里统一是上行。因为只有发送方 可以控制这个参数
如果mbps没指定，则默认为100mbps
关于对hysteria代码的研究可以参考 https://github.com/e1732a364fed/hysteria-
本作quic兼容 v2ray/xray的quic，但是你需要配置一下 v2ray/xray的 alpn配置：
"tlsSettings": {
"alpn":["h3"]
}
本作quic的默认alpn是h3，而它们俩内核可能用的是旧版的quic包，所以默认不指定alpn;
我们这里要求必须指定alpn
nextProtoH3Draft29 = "h3-29"
nextProtoH3 = "h3"
h3算是标准的http3的alpn了，所以是正确的, 不会暴露。
因为我们是纯quic，所以就算用了hy阻控，也不支持和hysteria内核对接。只能和vs/v2/xray内核对接。可以理解为更快的quic.
一，显然我们的hy阻控可以比普通的quic强
二，vs解决了 xray/v2ray的quic的老问题。
我发现，它们的开发者并不会妥善关闭quic的子stream， 实际上只要深入考察quic-go包中的文档就可以解决。
使用hy阻控时，配置了 hy_manual 后，可以手动调节速度，可参考quic示例文件。
进入交互模式 verysimple -i 后，会有相应选项。调节即可。
我讲一下。比如，vps供应商告诉你，每个vps的带宽为 10Mbps，此时有多种可能
-
它真的就给你了 “你专用的” 10Mbps带宽，此时，应该没有什么拥塞的情况，hy也就没什么用
-
它给你了 “大家共用的10Mbps” 带宽，此时，假设10人共用10Mbps，那么只有另外九个人都不用的时候，你才能占满10Mbps
此时，hy很有用, hy会霸占带宽，让其它不使用hy的人都被挤跑
- 它实际上只给了你 “你专用的1Mbps” 带宽，此时神也没法给你升带宽
不过，随着大家现在都在使用hy，所以互相挤压，可能有时就算使用hy也没什么效果了？
还有就是，现在vps会对 udp大流量进行qos，所以此时要用 faketcp
假设 你的网是我说的第二种情况，则有救，
此时，本来因为10人共用，导致正常的流量被压榨成了每人1Mbps，此时，我们最大的7.5倍，可以以7.5Mbps霸占带宽
所以个人认为手动挡在一些情况下还是有用的
经过近一步测试，我得出两个结论
- 在优秀网络下，开hysteria阻控 或者甚至 手动挡，都会产生反作用，降低实际速度
- 多路复用确实会影响最佳网速，每叠加一路，就会降低一定性能，基本呈线性关系
由于xray/v2ray默认 的quic 是 32路复用，太多了，肯定会导致性能损失，
目前的设计是，默认 4路复用，每个session最多包含4个stream, 超过了就会另起一个新udp连接。
当然，这个路数是可以调节的，extra = { maxStreamsInOneConn = 6 } ，这个配置只能在服务端配置，客户端自动适配。
编译时，若 noquic tag给出，则不使用 quic，否则 默认使用 quic。
不使用quic的话，编译文件可以减小2M左右。
经过测试，发现 内网极速测试时，quic 会占满 一整个cpu 核心，而其它协议一般只占用 40% 左右的核心。这应该是quic实现造成的，和本作无关。
这应该就是为什么 我的 quic 只测到了 1400mbps 左右的速度，而其它 协议都能测到 3000以上 的原因。cpu占满了，速率就提不上来。
也就是说，lucas的 quic包 对cpu的占用特别大，比一般的tcp要高一倍多。