研发请求:自适应服务器故障分流[解决代理服务器不稳定]

[z826540272]

希望增加自适应服务器分流,

类似概念:
Mutlipath TCP (MPTCP) 即多路径 TCP，是对传输控制协议 (TCP) 规范的一组扩展，可让客户端通过不同网络适配器建立到同一目标主机的多个连接。这可在各主机间建立灵活而高效的数据连接，并且仍与现有的网络基础设施兼容。

发起连接后,当前线路不通时,自动切换至备用节点重新发起连接,选取返回最快的节点作为使用节点,60/300秒后再次检测主节点是否联通,联通再切换到主节点
特点因注重在用户端无感,例如打开google网站,浏览器载入中,只要有任何备用服务器在线,即5秒之内打开谷歌.期间不断连,不显示错误
整个过程在5秒之内完成.

非主动式连接检测,主动式连接检测间隔期间仍导致代理不通,就算切换到新服务器,原有连接依然是不通或者关闭状态,必须要程序再次发起连接才可以使用.
这样的话就不会遇到服务器不稳定影响上网体验了

[AkinoKaede]

v2fly/v2ray-core#589

[badO1a5A90]

都会有的

[z826540272]

v2fly/v2ray-core#589

和这个健康检查不是一回事,我说的是那种无感切换,发起连接超时后自动向后备服务器发起连接

[z826540272]

v2fly/v2ray-core#589

主动式检测我觉得不太好,因为有间歇性发包的规律,和浪费一点点带宽和资源

[quintus-lab]

不同意。
这类功能放在客户端上实现即可，core上无必要增加。

[z826540272]

不同意。
这类功能放在客户端上实现即可，core上无必要增加。

不同意,不能实现.

[quintus-lab]

客户端怎么不能实现了？
不知你用什么客户端，何不去客户端那里提增加功能的需求。非要把前端的功能放到后端的core上，你这是一种什么样的思维？

[z826540272]

客户端怎么不能实现了？
不知你用什么客户端，何不去客户端那里提增加功能的需求。非要把前端的功能放到后端的core上，你这是一种什么样的思维？

客户端不能实现连接保持切换，只能实现主动检测，你什么都不懂。

[youngzyl]

VLESS的目标是规避探测。故障转移功能，应该由客户端发起可用性检测，比如5秒钟1次的可用性检测，不知道这是不是你所说的主动性检测。

而像你描述的无感知切换会遇到2个问题，
1、客户端无法判断是节点下线还是访问目标下线，只会知道是否成功连接，那这时候究竟要做出什么样的反应呢？
2、浏览器是否错误，这个不是由协议或者客户端决定的，而是浏览器自身的超时设定决定的。

[z826540272]

VLESS的目标是规避探测。故障转移功能，应该由客户端发起可用性检测，比如5秒钟1次的可用性检测，不知道这是不是你所说的主动性检测。

而像你描述的无感知切换会遇到2个问题，
1、客户端无法判断是节点下线还是访问目标下线，只会知道是否成功连接，那这时候究竟要做出什么样的反应呢？
2、浏览器是否错误，这个不是由协议或者客户端决定的，而是浏览器自身的超时设定决定的。

不是，我的意思是客户发起的连接如果在5秒内没有回应的话，就重发数据到备用服务器，浏览器不断连

[z826540272]

VLESS的目标是规避探测。故障转移功能，应该由客户端发起可用性检测，比如5秒钟1次的可用性检测，不知道这是不是你所说的主动性检测。

而像你描述的无感知切换会遇到2个问题，
1、客户端无法判断是节点下线还是访问目标下线，只会知道是否成功连接，那这时候究竟要做出什么样的反应呢？
2、浏览器是否错误，这个不是由协议或者客户端决定的，而是浏览器自身的超时设定决定的。

至于客户端判断服务器故障还是访问目标故障的话，可以添加一个测试回应机制。
甚至更简单一些，直接tcping.
不断开连接，浏览器就不会网络错误。
几秒检测一次的轮训机制，故障产生检测期间是不通的。期间发起的连接不会得到回应

[youngzyl]

不是，我的意思是客户发起的连接如果在5秒内没有回应的话，就重发数据到备用服务器，浏览器不断连

这个很显然是原理上理解有些错误。首先浏览器并不存在断连这种说法，应该说是访问超时，也就是在一定时间内没有收到握手信息浏览器就会显示错误。

至于客户端判断服务器故障还是访问目标故障的话，可以添加一个测试回应机制。
甚至更简单一些，直接tcping.
不断开连接，浏览器就不会网络错误。
几秒检测一次的轮训机制，故障产生检测期间是不通的。期间发起的连接不会得到回应

tcping肯定是行不通的，那只是判断服务器能否接受tcp传入而已，甚至没有可用性检测的作用。浏览器没有网络错误也是有问题的，就像之前说的，是否显示网络错误是超时的表象。
事实上许多浏览器本身就会在访问失败后重新尝试，如果你希望是在网络错误后重新更换连接的话，那就一样是客户端的操作了。我能想到能达到这一目的的方法就是高频率的gstatic握手检测。

[z826540272]

不是，我的意思是客户发起的连接如果在5秒内没有回应的话，就重发数据到备用服务器，浏览器不断连

这个很显然是原理上理解有些错误。首先浏览器并不存在断连这种说法，应该说是访问超时，也就是在一定时间内没有收到握手信息浏览器就会显示错误。

至于客户端判断服务器故障还是访问目标故障的话，可以添加一个测试回应机制。
甚至更简单一些，直接tcping.
不断开连接，浏览器就不会网络错误。
几秒检测一次的轮训机制，故障产生检测期间是不通的。期间发起的连接不会得到回应

tcping肯定是行不通的，那只是判断服务器能否接受tcp传入而已，甚至没有可用性检测的作用。浏览器没有网络错误也是有问题的，就像之前说的，是否显示网络错误是超时的表象。
事实上许多浏览器本身就会在访问失败后重新尝试，如果你希望是在网络错误后重新更换连接的话，那就一样是客户端的操作了。我能想到能达到这一目的的方法就是高频率的gstatic握手检测。

我说的断连就是连接失败的意思
"不断连"的意思是转一会圈网页还是打开了

[zhfish]

总感觉实现这个会套娃啊。。
不要抢浏览器的生意啊

[KyonCN]

基本没有人和你有相同需求 建议自己弄个branch开坑
目前xray还有一大堆更为重要的坑没填

[even0306]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

[z826540272]

基本没有人和你有相同需求 建议自己弄个branch开坑
目前xray还有一大堆更为重要的坑没填

那是没什么人意识到这种需求

[z826540272]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

不用检查,没得到正确回应直接像后备服务器发起连接

[even0306]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

不用检查,没得到正确回应直接像后备服务器发起连接

但这样就无法做到选择最快的节点连接的需求啊

[z826540272]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

不用检查,没得到正确回应直接像后备服务器发起连接

但这样就无法做到选择最快的节点连接的需求啊

你说的最快要么是时间最快要么是速度最快,发起连接选返回信息最快的结果就行了.

[even0306]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

不用检查,没得到正确回应直接像后备服务器发起连接

但这样就无法做到选择最快的节点连接的需求啊

你说的最快要么是时间最快要么是速度最快,发起连接选返回信息最快的结果就行了.

你的需求啊，选取返回最快的节点。可如果只是一个节点不通就切下一个，直至切到通的，你的这个需求就满足不到了。想满足这个需求，又必然要检查连接延迟，速率，抖动等，综合后选取最快节点

[z826540272]

他的意思应该是定时检查多台服务器的连接稳定性，自动切换到最好的吧。我也觉得要做也是由客户端来做。而且定期自动向所有服务器发包确实会占用线路资源

不用检查,没得到正确回应直接像后备服务器发起连接

但这样就无法做到选择最快的节点连接的需求啊

你说的最快要么是时间最快要么是速度最快,发起连接选返回信息最快的结果就行了.

你的需求啊，选取返回最快的节点。可如果只是一个节点不通就切下一个，直至切到通的，你的这个需求就满足不到了。想满足这个需求，又必然要检查连接延迟，速率，抖动等，综合后选取最快节点

速度统计必然要有大幅流量才能做到,所以只能做到回应最快,并发选取最快回应即可.

[AkinoKaede]

建议先了解什么叫做 timeout

[mclovin-2k]

Somebody just told him PR welcome and close this please.

[ghost]

@z826540272

You may find my patch interesting. Feel free to use it on your own build or make a PR with this.

v2fly/v2ray-core#377 (comment)

[ghost]

v2fly/v2ray-core#589 will probe actively, and it's unclear if this is the battery-friendly way on mobile devices.

[z826540272]

Somebody just told him PR welcome and close this please.

你来