Replies: 2 comments
-
我目前使用的方案是 利用好负载均衡 Load Banlance 提前建立16条 TCP 连接,每个连接都使用 gRPC,在 0-RTT 的同时,尽可能地少在一条连接上复用太多连接就可以稍微缓解一些 TCP 队头堵塞的问题。 |
Beta Was this translation helpful? Give feedback.
0 replies
-
太久没关注代理工具了, 最近才关注 Xray 的频道, 火星了, 我还停留在 gRPC 不用握手很快的时代, 下一代流控是 MUX 复用然后分离的设置, 狠狠支持大佬, 希望早点出 1.9 版本 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
下一代 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 会怎么设计?
Beta Was this translation helpful? Give feedback.
All reactions