下一代 XTLS 应该如何设计?

[qwerr0]

下一代 XTLS 应该是两个目标吧，首先是 0-RTT，其次是解决或是缓解 TCP 队头堵塞问题。
目前解决了这两个问题的是基于 QUIC 协议的，如 TUIC 和 Hysteria2
QUIC 的缺点也比较明显，就是使用 UDP，国内因为特殊国情，跨运营商和出海流量很容易被 QoS，除了 QoS 外，UDP 流量特征过于明显，还需要类似于端口跳跃的技术，最后是实现在用户层的 CC 吃性能和内存，速度稍微跑高一些，内存占用遥遥领先，在我的硬路由器上如果使用 Hysteria2 （Sing-Box 服务端 + Clash Meta Alpha 客户端）参数上指定一个较高的速率，那么一测速就 OOM 断流，（我一度以为是我的线路问题，没想到是路由器内存不足了，OOM 了然后代理工具在重启，Hysteria2 一下子就能吃掉接近300M的内存，代理工具还没来得及 GC）

对于多路复用的 gRPC，他解决了 0-RTT，但是没有解决 TCP 队头堵塞的问题，在内网测速中，要么特别吃性能，要么因为队头堵塞问题吃很少的性能，速率只有200~400Mbps，还有断流的问题。
对于 XTLS，他不吃性能，因为不需要复用，完全不存在 TCP 队头堵塞问题，但是 TCP 至少也需要 1-RTT 握手（TFO启用）。

如果 XTLS 能和 gRPC 结合就好了，于是就有第一种想法如果 gRPC 能够及时把复用的连接分离出来：
新连接发起时，使用之前的连接进行复用，然后在后台立刻向服务器建立新的连接，建立好后，将复用的连接分离到该连接上。

不同于 QUIC 设计时需要考虑到不同的WEB服务器，代理工具在代理前是能提前拿到服务器地址建立连接的，因此第二种就是 XTLS 0-RTT 的方向：
a. 提前建立连接，很容易想到线程池，于是可以考虑弄一个连接池，提前建立好一定数量的连接，根据目前连接情况新建或销毁，这种设计最简单，但要适应不同环境肯定需要很多参数。
b. TFO 支持在 SYN 和 ACK 上携带一些数据，不过这种方式特征比较明显，有一些限制，实现起来也比较麻烦。

所以，下一代 XTLS 会怎么设计？

[qwerr0]

我目前使用的方案是 利用好负载均衡 Load Banlance 提前建立16条 TCP 连接，每个连接都使用 gRPC，在 0-RTT 的同时，尽可能地少在一条连接上复用太多连接就可以稍微缓解一些 TCP 队头堵塞的问题。

[qwerr0]

太久没关注代理工具了, 最近才关注 Xray 的频道, 火星了, 我还停留在 gRPC 不用握手很快的时代, 下一代流控是 MUX 复用然后分离的设置, 狠狠支持大佬, 希望早点出 1.9 版本