search

MetaCubeX / mihomo

A simple Python Pydantic model for Honkai: Star Rail parsed data from the Mihomo API.
https://wiki.metacubex.one
MIT License
16.52k stars 2.65k forks source link

[Feature] 实现节点动态实时选择功能 #1433

Open Haskely opened 3 months ago

Haskely commented 3 months ago

Verify steps

Description

摘要

请求实现实时检测的、动态的节点选择功能，替代现有根据规则、ip/domain 匹配的节点选择，以极大简化配置、节约流量。

背景

目前使用该软件：

  1. 可能需要学习复杂的 yaml 配置语法和逻辑：学习不同的 ip/domain/geo 信息源，学习不同节点的分组，学习多家供应商规则的外部倒入，才能写出相对良好的节点分配规则，做到自动只对必要的流量请求 vpn，达到节约流量的目的。

  2. 虽然有按天更新的 ip/domain/geo 信息源，但是本质依然是静态配置，实际使用中还是会经常遇到 “该直连的用节点”、“该走节点的用了直连” 的现象。

  3. 对于不同的网络资源需要使用不同节点的需求，规则都必须手动明确指定

用户使用软件的本质逻辑是：当无法使用直连访问时，才有必要使用节点进行访问 。为什么不把这个逻辑直接写到软件里呢？

功能请求

  1. 软件接管电脑所有网络请求，当一个网络请求发起时，软件首先尝试建立直接连接。
  2. 如果直接连接失败，软件按照预设顺序逐一尝试节点连通性（这个顺序可以是从成本由低到高排序），直到找到第一个连通的节点，使用该节点进行连接。
  3. 软件后续会自动记住对相同 IP/DOMAIN 使用该节点。
  4. 软件定期对该 IP/DOMAIN 重新尝试节点测试，以检查它们是否可用更低成本的节点或直连（默认直连的成本最低），并在成功时切换。

注意

该功能看起来类似 fallback, 但并不相同。本功能的请求更类似于针对每一个 IP/DOMAIN 的单独的 fallback，而不是仅仅测试节点的有效性。

Possible Solution

No response

Skyxim commented 3 months ago

欢迎 PR 或者可以给出一套完整的，逻辑自洽且符合 TCP/UDP 相关特性的设计方案

techblack commented 3 months ago

功能请求[1]. 你忍受的超时时间是多少呢？ 根据设备和网络协议不同基本都是好几秒甚至十几秒 打开一个页面要等好几秒来等超时？ [4].几万几百万的量级也要这样测试？

Haskely commented 3 months ago

功能请求[1]. 你忍受的超时时间是多少呢？ 根据设备和网络协议不同基本都是好几秒甚至十几秒 打开一个页面要等好几秒来等超时？ [4].几万几百万的量级也要这样测试？

这个设想主要来源于浏览器上网、下载场景。

因此，或许我需要的是一个拥有此能力的浏览器插件，而不需要改变此软件。

忍受的超时时间：一般一个页面（或页面的子请求）5s 没反应我就会切换节点刷新了，我只需要将这个过程自动化而已。所以这个功能可以把场景限制的很死，不考虑更多泛化。

打开一个页面要等好几秒来等超时：只有第一次打开时会这样，后面会记忆策略不是每次都要测一遍。

几万几百万的量级也要这样测试：首先此规则只捕获普通个人用户日常使用场景时的网络请求（工业、工作场景不使用），每个请求的判断状态独立保存。就算长时间使用后积累了几百万总量级的不同记录，每一条的重试时间也是根据添加时间分散开来的，不会形成瞬时并发；也可以设置成时间+访问次数后重新后台异步测试，那些低概率打开的长尾记录不会频繁重测。

techblack commented 2 months ago

功能请求[1]. 你忍受的超时时间是多少呢？ 根据设备和网络协议不同基本都是好几秒甚至十几秒 打开一个页面要等好几秒来等超时？ [4].几万几百万的量级也要这样测试？

这个设想主要来源于浏览器上网、下载场景。

  • 假如直接开系统代理，如果保底 MATCH 设置成 节点，经常遇到不需要过节点（或者不能过节点）但是由于配置没有捕获默认过节点的情况；如果保底 MATCH 设置成 DIRECT，则会相反遇到触发保底但是需要过节点才能访问的情况。然后此时手动打开软件修改配置感觉很麻烦。
  • 假如安装 SwitchyOmega 这种插件，那也经常需要点一下手动切换记忆，没有上面说的自动切换能力。

因此，或许我需要的是一个拥有此能力的浏览器插件，而不需要改变此软件。

忍受的超时时间：一般一个页面（或页面的子请求）5s 没反应我就会切换节点刷新了，我只需要将这个过程自动化而已。所以这个功能可以把场景限制的很死，不考虑更多泛化。

打开一个页面要等好几秒来等超时：只有第一次打开时会这样，后面会记忆策略不是每次都要测一遍。

几万几百万的量级也要这样测试：首先此规则只捕获普通个人用户日常使用场景时的网络请求（工业、工作场景不使用），每个请求的判断状态独立保存。就算长时间使用后积累了几百万总量级的不同记录，每一条的重试时间也是根据添加时间分散开来的，不会形成瞬时并发；也可以设置成时间+访问次数后重新后台异步测试，那些低概率打开的长尾记录不会频繁重测。

看起来你的需求可以通过一个优秀的规则+量大稳定的节点完成。 但是看过一些代理软件确实实现了差不多的行为，但是不知道体验如何 例如 https://github.com/snail007/goproxy/blob/master/README_ZH.md 智能HTTP代理，HTTPS代理，SOCKS5代理，会自动判断访问的网站是否屏蔽，如果被屏蔽那么就会使用上级代理(前提是配置了上级代理)访问网站;如果访问的网站没有被屏蔽，为了加速访问，代理会直接访问网站，不使用上级代理。

zrr1999 commented 2 months ago

那些低概率打开的长尾记录不会频繁重测

我有一个想法，这个或许可以通过dns手动实现一个简易版。 假设你在你的软路由上搭建了一个dns服务，当你访问ex1.com时，dns服务会测试连通性，如果不能连接返回fakeip，否则返回正常 ip，这样结合一些其他配置，也可以实现动态分流了。

我准备先去试试

gg4924 commented 2 months ago

有gfw规则，里面全是无法直连的目标，让其走代理，其余走直连就节省流量了，对于漏掉的无法直连的自己添加下就行了，也没几个。使用下面类似规则即可，维护下自己的custom_proxy规则集。

- GEOSITE,gfw,proxy
- RULE-SET,custom_proxy,proxy
- MATCH,DIRECT

就我个人而言，我需要对哪个目标走哪个代理进行严格控制，有些目标服务虽然能直连，我也需要它走指定的代理。有些目标对不同地区提供了不同的服务，也需要控制其走特定地区的代理。 你提出的动态检测以及自动切换功能如果实现的话，我希望只是作为新增选项或者模式，自由选择是否启用，而不是替代现有的模式。

younijiuhao876 commented 2 months ago

第一反应，自动选择。。。

看了下，理想了吧？自动检测，太依赖网络质量了，包括你本地网络，节点网络，等你检测一圈下来，加起来都几秒钟了。

ttttmr commented 2 months ago

应该是类似cow的功能，不过这个项目多年没有更新了 https://github.com/cyfdecyf/cow

Fddh2012 commented 2 months ago

@ttttmr 看了下需求，这第一次连接得有多大的延迟啊？

Fddh2012 commented 2 months ago

不是有个项目是CN-list么 ？这个项目里的所有域名都是大陆直连质量良好的，直接指定这些不就得了。 https://github.com/felixonmars/dnsmasq-china-list/ https://github.com/Loyalsoldier/v2ray-rules-dat/blob/release/china-list.txt

ttttmr commented 2 months ago

我来详细描述一下吧

不会劣化现有的代理体验

这个功能可以理解是对于- MATCH,DIRECT这个直连兜底策略的优化，不影响现有的域名分流功能

所有能够走到这个策略的就是一个未知的域名

不会增加第一次连接的延迟

使用这个策略的现状

  1. 尝试直连，正常访问 or 直接失败

实现自动选择功能后，大概的流程

  1. 在内部缓存查找规则
  2. 如果没有找到，尝试直连 2.2. 如果成功，正常访问 2.1. 如果失败，在内部缓存中增加一条规则：DOAMIN,xxx,PROXY，重试连接
  3. 如果找到，使用对应的代理链路访问 4.1. 如果成功，正常访问 4.2 如果失败，直接失败

此处只有2.1情况下的重试会增加延迟，即首次直连失败的场景，这点对比对于现有情况是直接失败，延迟不是问题

高质量域名列表无法解决问题

现有的名单是有限的，添加和更新名单是无止尽的

小众域名永远都会面临这个问题：直连访问不了，域名不在名单里，需要手动加到规则里，然后再重试

具体要做什么

实时评估当前连接质量，质量较低时自动尝试其他链路，并把成功的结果缓存下来

重点在于是实时评估决策，而不是用预定义的列表决策

这里面困难的是：如何评估当前连接质量

评估依据比如：超时，丢包率，速度...

符合一定的条件就可以判定为连接质量低，这些选项都可以作为配置项暴露出来