[Feature Request] 支持高可用 或/及 负载均衡功能

[lslqtz]

由于众所周知的原因 (墙), 使用 rathole 在与其它国家的服务器长期传输数据时可能会出现端口阻断的问题, 进而降低了服务可用性.

在我的案例中, 使用 rathole 以 TCP+nodelay, 开启 noise, 以 5Mbps 对称传输数据, 在 3 天左右被阻断.

通过支持高可用 (及健康探测), 可以直接的提高可用性. 而通过负载均衡则可以降低每一个端口的流量以避免出现端口阻断问题.

尽管 Out of Scope 列举了其可以与负载均衡器等工具一起使用, 但这仍然出现缺失高可用功能的问题, 也对用户带来了额外的复杂性和性能损失.

望考虑, 谢谢!

(上述所指高可用功能为将流量集中在相同节点, 但在节点失效后自动更换节点)

[lslqtz]

另: 若要更好的实现这一功能, 可能还需要先实现 #157 (对于 bind_port)

[fernvenue]

而通过负载均衡则可以降低每一个端口的流量以避免出现端口阻断问题.

Is there any evidence of this? I don't believe that, and I don't think the GFW is an issue that this project should consider.

尽管 Out of Scope 列举了其可以与负载均衡器等工具一起使用, 但这仍然出现缺失高可用功能的问题, 也对用户带来了额外的复杂性和性能损失.

I don't think so, in fact, making the functionality of rathole more complex is what causes this problem.

But I do think that another related issue here, #283, may be helpful for this. This way, we can take actions using systemd or other ways after max_retries.

[lslqtz]

Is there any evidence of this?

这是其第二次发生的记录, 这不能证明负载均衡有作用, 但证明了高可用是有必要的. :)
https://doubibackup.com/wkcjzpyd-2.html
XTLS/Xray-core#1397
https://hostloc.com/thread-458023-1-1.html

https://gfw.report/blog/gfw_shadowsocks/zh.html
一旦GFW主动识别出Shadowsocks服务器，GFW可能会丢弃所有发送自服务器IP地址，或服务器Shadowsocks端口的数据包。但GFW也可能不立即采取封锁措施。

这些案例足够证明其实质存在.

已经通过 rinetd 转发多个端口到本机的一个端口, 外加 haproxy 解决问题, 但在服务器侧 rinetd 额外引入了 30% 的 CPU 占用. (使用 rinetd 是由于不确定多个 rathole 重复监听同一个端口的行为)

猜测: 在 Noise 协议下的数据包可能会被视作一种无协议的翻墙工具, 从而 / 或只是被视为大流量 而被端口阻断. 但为了保证通信安全, 这种手段是有必要的.

(手滑点到 Close)

[zhfish]

拿rathole科学上网其实并不合适，关键一跳还是交给Xray，shadowTLS等做专业协议伪装

当然刨除协议伪装，我觉得有负载均衡也很好。。

[lslqtz]

并非科学上网, 是用于跑 Web 服务. 在关闭 rathole 的 Noise 协议后, 未有再被封锁情况, 但 HTTP 流量不得不以明文传输.

[zhfish]

并非科学上网, 是用于跑 Web 服务. 在关闭 rathole 的 Noise 协议后, 未有再被封锁情况, 但 HTTP 流量不得不以明文传输.

本来明文可以过检测的流量，变成了密文被当成科学了是吧。。。

[lslqtz]

并非科学上网, 是用于跑 Web 服务. 在关闭 rathole 的 Noise 协议后, 未有再被封锁情况, 但 HTTP 流量不得不以明文传输.

本来明文可以过检测的流量，变成了密文被当成科学了是吧。。。

是的, 而且印象中大流量 HTTPS 直接跑也是有概率被封锁的... 不直接使用 HTTPS 的目的是为了提升性能和降低配置成本. 出于成本的目的我已经改用 Cloudflare Tunnel 有一段时间了, 由于这个问题最后还是有些涉及 Out of Scope, 看起来我还是 Close 这个 Issue 比较好.

由于是只遇到了端口封锁, 所以有一个高可用的想法: 通过健康探测实现节点或端口的替换. 其实现难度相对负载均衡来说低很多, 而且能提升服务可用性.

而负载均衡是在高可用的健康探测上延伸出来的流量平均分载, 即通过多个节点或单个节点的一个端口范围代替一个端口同时进行服务, 能够降低每个端口的流量避免本身被关注.

考虑到这是一种特殊地区的情况, 觉得高可用相对来说是比较有必要的, 但是如果不是对于多个端口而是对于多个节点来说, 它们本身的入口 IP 不一样, 这会导致一些问题 (除非它们的前面还有一台机器).