RPRX
关于 gentle 发包，这个是我想弄的与 brutal 相对的策略，合理积极探测网络上限、适度对抗丢包，而不是没达到想要的速率就使劲发包，整得跟饱和攻击一样，~~虽然饱和攻击的优点是利于对抗丢包~~，而且引入 brutal 要协议层面交换期望速率，但引入 gentle 不需要，至于为什么不弄 bbrv3 是因为懒得研究且懒得按它的标准去实现，我觉得自己弄个简单粗暴一点、适合代理用的就行
我研究了一下 quic-go 和其 h3 的 EnableDatagrams，它可以被转译为 h2，Nginx 应该支持转发，只是不知道 ~~CF~~ CDN 是否支持 目前如果想做到 UDP 包走 XHTTP/3 datagram 是完全可行的，鉴于 UDP 可能被 Q 还可以允许配置为只让 UDP 包走 XHTTP/3 虽然路由也能做这件事，还有如果只想让少量 UDP 包走 XHTTP/3，还得把被代理流量的 UDP 443...
> 放h2里不变可靠流了 没意义了 Nginx 最多只支持 h2c 回源，意义在于它和 Xray 通信，CDN 同理，容易丢包的阶段是境内到境外段，这一段需要 datagram
~~频道消息下面有个广告~~
现在重点在于研究如何在 Xray 服务端构造出来能被 Nginx 转义为 H3 datagram 的 h2c 包，或许 @yin1999 有空研究下？
我今天粗略看了下 9297，人家说的是 HTTP datagram 而不只是 h3，给出了 h2 的情况并指出丧失了“不可靠性”
这倒不是大问题，h3 datagram 的格式和非 h3 时 capsule protocol 的格式都在 9297 中写明了，改代码很简单 毕竟我们还要 patch Nginx 让它支持别的 QUIC 拥塞控制，一个 patch 版的 Nginx 是不可避免的，这就是 XHTTP 接下来的方向
如果实在想把 QUIC transport 加回来，可以是 TLS ALPN 有且只有 h3 的形式，我之前把 TCP 改成 RAW 就是为这种情况做铺垫
我不确定它是如何工作的，不过它可以与 Xray-core 客户端/服务端交互吗？比如说输出分享链接？
输入 SSH 密码直接搭建挺好的，上一个这么做的是 ProxySU 但是如果客户端、服务端均为这个 VPN，完全隐藏了 Xray-core 及协议的细节，加进来感觉怪怪的，如果是有分享链接还好