splithttp协议下基于nginx的多服务器负载均衡方式

[christarcher]

分析了一下刚出的splithttp协议,它使用http post和get来传输
它不同于像ws这种流,实现负载均衡可以是基于单个连接的
xray本身支持负载均衡.nginx的可控性更高,负载均衡的选择也更多,消耗也更低(因为不需要真正的解析流量和路由)

如果说预算够的,当然可以架设一台中间服务器用来分配流量
这里只是验证可行性,踩了一些坑和一些想法写在这里

如果使用ip_hash策略,针对同一个用户只能导向同一个出口,这个策略机场可以使用,但个人没必要
而如果使用基于轮询或者权重的策略,问题就在于,splithttp(1.8.16)的格式是 POST /{UUID}/{Seq}
同一个uuid(即同一个连接),被发给了不同的服务器出口就会造成问题,所以均衡策略的hash应该根据uuid来
下面使用正则来匹配uuid,作为负载策略的判定

我感觉使用workers来实现这样的负载均衡比较困难,因为可能会命中不同的worker实例,无法判定流量到底该发给哪一个.

场景:两个搭建了splithttp的落地机,一个vps.

map $uri $uuid {
    ~^/([0-9a-fA-F-]+) $1;
    default "";
}
upstream backend {
    hash $uuid consistent;
    server 1.2.3.4:8080;
    server 2.3.4.5:8080;
}
server {
    listen 80 ; 
   (省略)
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_redirect off;
    }
    root /var/log/; 
}

经过简单的测试,两台服务器都可以正常收到请求并处理

多线程测速:

只使用1台服务器作为出口的情况下只能跑到60mbps左右,vps带宽是100mbps,针对多线程下载还是有提速效果的.

[RPRX]

首先你根据 UUID 来路由的话，鉴于一个 UUID 就是一个连接，用 Xray 就能实现这样的负载均衡，其次 WS 也能用这样的负载均衡

[RPRX]

就是说精神可嘉，但没看懂为什么非要 nginx，VLESS 出站的 clients 多写几个或者用路由的 balancer 都比插个 nginx 进来更高效

[RPRX]

SplitHTTP 协议的特性是 Split，上下行可以分离，甚至上行每个包都可以分离，但根据 UUID 来路由的话其实并没有实际上 Split

[mmmray]

I think this can still make sense in these scenarios:

1. the server owner can only distribute sharelinks, and so would have to produce one config per xray backend. In this case, the user has to manually select a new config when another breaks, not many clients automatically connect to a different config. end user considerations
2. adding/removing backends happens very frequently, for some reason
3. users cannot be trusted with distributing the traffic evenly across machines
4. when restarting xray, the traffic can be slowly migrated between servers by adding weights to the load balancer -- clients cannot do this cannot be achieved with splithttp, see next post

of course, I made those scenarios up. From a reliability perspective, having more configs is always better.

[mmmray]

Some more random thoughts.

In regular deployment scenarios, certain load balancers can wait for old connections to be closed on old backends, and route new connections to the new backend. So a new version of xray can be deployed without disrupting a single user connection. This works for websocket, for example.

In the case of splithttp, it's not possible to gracefully migrate connections using standard software. Nginx has consistent hashing, but does not know about "connection state", as it exists virtually within xray memory. One would have to migrate individual sessonid values over to the new backend when there is no longer a GET request running, which is too complicated for most load balancers.

[christarcher]

xray客户端来负载均衡当然是好的.但是使用一个服务器来分担流量主要是针对这两个情况:
1.流行客户端对负载均衡的支持都不好,需要手动导入配置,无论怎么说都是麻烦的.
2.针对有多个路由绕路的落地机的情况

[aceslup]

前置Nginx，配合日志分析，也方便做访问控制，更像个站

[RPRX]

还有目前只写一个 VLESS 出站且 clients 只有一个的话，SplitHTTP 的 H2 默认会有多路复用，对多线程测速不友好，以后可以设 concurrency