-
Notifications
You must be signed in to change notification settings - Fork 9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
添加按照出口网速进行选择的负载均衡 #1924
添加按照出口网速进行选择的负载均衡 #1924
Conversation
0308ab3
to
9c75dd0
Compare
还是觉得 #1825 提的方法好一些,因为不用下载完整数据,服务器压力小很多。 我不太懂代码,根据你的描述来看,大概是通过定时下载某个用户指定的网址来测出最快的服务器。这样会有问题。假设某个服务器用github作为target测出来很快,但是那个服务器禁止访问youtube那么用这个方法选服务器就会没法看youtube。 非常感谢大佬努力,等了这么久终于有人开发负载均衡功能!大佬加油! |
下载什么内容,下载大小都是自己可以配置的,你可以配置一个返回内容小的测试请求比如gstatic/generate_204 |
好像以前提过类似的建议,可以按照给outbound不同的权重、或者直接按照顺序循环来调用。 |
@strongbugman 值得期待的功能,现在合入主干了吗? 2楼提的ping值不太好,只有下载完整数据才能得到真正网速。如果二级代理用了kcp,ping一点意义也没有。 |
是否可以将负载均衡策略作为可配置模块进行开发? |
95460a4
to
d1e88cf
Compare
@ALL 目前功能已完成,看看怎么把测试补上就提交PR了,感兴趣的同学可以先自行编译,在配置文件中加入如下配置: "balancers": [
{
"tag": "b1",
"strategy": "optimal", //new
"optimal_strategy_config": {
"timeout": 60,
"interval": 120, //多久进行一次测速
"url": "https://github.com/v2ray/v2ray-core/releases/download/v4.21.3/v2ray-linux-64.zip",
"count": 1 // 一次测速中测试几轮,最后会取平均值得分
},
"selector": [
"jms4",
"jms3",
"jms2",
"jms1",
]
} |
727ef8f
to
88d4357
Compare
这样呢? "inbounds": [ |
能弄成clash那样的路由策略就好了...省得每次都要到客户端自己手动设置 |
f3bcb8c
to
94c7d35
Compare
@chancat87
|
我基于这个 PR 做了一些修改,我的分支: 与这个 PR 的 diff: 主要修改内容:
同样不常写 golang 项目,欢迎大家指正交流。 |
@jonas-burn 我有几个疑问哦
还是感谢改我的烂代码,但要记得保留我的commit哦,另外这个PR还没官方回复,如果我们达成一致,可以先PR到我的分支上 |
向上跟踪 https://github.com/jonas-burn/v2ray-core/blob/1cc7702/app/dispatcher/default.go#L205-L225
https://github.com/jonas-burn/v2ray-core/blob/1cc7702/common/task/periodic.go#L63
是指“全部测速完成之后再更新实际使用的出口”这个修改吗?一个 outbound 超时应该不会影响测速结果吧,只不过会等待一个 timeout 而已,其它部分没有等待测速结果,因此这个 timeout 引入的延迟不会影响到实际功能,只是测速结果更新慢一点而已。 我做这个更改的主要考虑是,不希望在测速过程中持续变更 outbound,因为 outbound 的变更通常意味着出口 IP 的更改,这种变化可能会给很多应用带来问题,因此希望能够尽可能少的变更出口 IP。
这个测速我认为跟场景无关,正如你说的,需要优化网页访问,就填一个响应比较小的测速地址,如果希望优化串流之类的,就填一个响应大一点的。 测速时关闭压缩的主要考虑有两点,一是启用压缩会导致使用者不能非常准确的判断一个测速地址实际的传输大小(比如一个 JS 文件,下载下来 10k,压缩传输也许只有 5k),二是启用压缩可能会带来额外的性能开销,比如服务端压缩可能会引入延迟,客户端解压缩还会无意义地消耗 CPU 时间。 换句话说,我希望“测速”测的是链路的尽可能真实的传输速度,而不是一个包含各种客户端、服务端处理延迟的请求速度,这些不应该是 v2ray 应该考虑的。 如果没有问题,会先 PR 到你的分支上的。 |
@jonas-burn 多谢解答 我觉得没问题 |
我建议 @strongbugman 把 json 中 |
It has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days |
已经合并到主分支了吗 |
相关issues:#1857 #1825
简单实现了下按照网速快慢来进行负载均衡,定时向相关的outbound发送请求,按照网速选择最优
TOOD:
2,支持HTTP/HTTPS测试 done
3,测试覆盖率 done
关于测试链接的选择,就这俩天自己使用情况来看,如果是为了照顾浏览网页等内容小但频率高的场景,可以选择返回内容少的targer,进行多轮测试选择平均值;相反,如果为了看视频更快点,可以选择返回内容多的targer,进行单轮测试拿到网速进行比较选择。网络环境错综复杂,如果有更好的策略欢迎讨论
waiting for review 第一次写go项目,欢迎各种指正😅