RPRX
``` --- FAIL: TestVMessQuic (4.11s) ```
@mmmray 试着修一下这些 tests，应该不难，~~修不好就算了~~
``` --- FAIL: TestVMessQuic (4.10s) ``` FAIL 只剩这个了，~~其实我觉得要不这个版本就把 QUIC Transport 删掉吧，反正也没人用吧~~
打算把这个 PR 合了然后把 QUIC 传输层删了，@yuhan6665 说应该还有人用，~~我说删一下就知道了，总之不想再带这坨代码玩了~~
> 这不太对吧 错的也不是它啊/ **TestVMessQuic**
https://github.com/XTLS/Xray-core/pull/3550/commits/dd876d59eb7e10a59b7d1d4e59c09a78a0f771b8 这个 commit 不行，应该会导致用户能手动修改浏览器指纹的 ALPN？~~还好看了一眼~~
感谢 PR，为了防止损坏现有功能，我倾向于这个 PR 放下个版本之后
首先我不确定服务端能否很好地处理这种情况，不过如果用不同的 sessionId 应该可以 其次就是我不太确定这个东西是否实用，**因为对于 XHTTP 首包延迟是无关紧要的，运营商有没有 Q UDP 才是最重要的** **就是说后面的请求都是 0-RTT，延迟都差不多，而带宽能跑到多少更影响使用体验，这个目前由用户自己的体感决定**
我觉得在这方面确实会更像，但也会导致带宽不可控，因为有些运营商 Q UDP，或许本就想用 QUIC 的更适合用这个？
~~其实现在的 quic-go 都不是 Chrome 指纹~~