search

XIU2 / CloudflareSpeedTest

🌩「自选优选 IP」测试 Cloudflare CDN 延迟和速度，获取最快 IP ！当然也支持其他 CDN / 网站 IP ~
GNU General Public License v3.0
19.28k stars 3.76k forks source link

新的下载测速模式需求 #500

Closed qwerttvv closed 7 months ago

qwerttvv commented 7 months ago

功能需求

因为只有cf的下载测速，这两天试了试，观察了一下，发现一些现象不知道是不是个例

简单一句话：tcp ping的快慢和下载速度的快慢不一定有绝对的关系

解决思路：

从ping的结果开始测下载，逐一记录下载速度结果，如果第n结果明显低于之前的结果，则标记为待定，n+1如果和n-1及n-2之前的差异不大则跳过，如果n+2又明显低，则继续标记待定，凑够目标ip数10个，如果实际测到了15个，10个正常，5个慢，则那5个待定的丢弃，如果测了20个，只有5个很快，其余15个都慢一些，那么按速度排序输出前10个。

这里需要两个参数变量，第一个是标记待定的阈值，就是比之前下载结果慢多少算待定，可以用百分比或者绝对数值，比如慢1mb/s就标记待定，或者2mb/s，自己设置。另一个是一共测多少个ip，比如需要10个输出，前5个速度快，之后有快有慢，凑不到10个小于之前设定阈值的ip了，那么就一共测试20个，取前10，也就是5个最快的，5个比最快慢的。

这样就跳过了那些ping快，下载慢的

【下面是另一个进阶的想法，于主题无关】 进一步讲，可不可以下载测速两次，比如一共要输出10个ip，下载测速过程一共测20个，那么这20下载测速完毕之后再从头来一次，有可能有些被阻断/干扰的就挑出来了，丢弃

预期目标

预取目标：丢弃tcp ping快而下载慢的ip

XIU2 commented 7 months ago

延迟和速度本来就不是绝对反比，因为影响因素很多，不过延迟低的 IP 遇到速度快的概率命令比延迟高的概率多很多，所以设计时就是先延迟测试，然后排序后从最低延迟开始测速。

对速度影响最大的还是丢包（也代表了线路拥塞堵车了，低优先级的包就被丢弃了，被丢弃的包一段时间后会重新传输，但因为拥塞还可能再被丢弃，所以只要丢包了，速度/稳定性就是断崖式下降），所以排序时也会先按丢包率排序，再按延迟排序，这样丢包的 IP 都会被排到末尾（即使延迟很低）。

你说了这么多，我简单看了下没啥意义，因为同一个 IP 不同时间测速结果差别很大，甚至通过 IP 你连续下载测速几次得到的结果都可能是天差地别。

至于你说的 【下面是另一个进阶的想法，于主题无关】，这个以前有人提过类似的需求（#454 #204 ），但这种功能是不会添加到软件内的，因为可以通过外部脚本实现。

我把 CloudflareST 设计成命令行程序，除了方便跨平台系统运行外，就是为了方便与第三方工具、脚本搭配使用，可以实现各种各样的需求，毕竟大家的需求都千奇百怪，真要都塞到 CloudflareST 里，那代码复杂程度直线上升，运行参数估计能翻几番，而且使用起来还非常不灵活。

只需要写个脚本，先指定参数运行一次 CloudflareST 获得输出的 结果.txt，然后从中提取输出的 IP 写入到 1.txt 中，然后再次运行 CloudflareST 并指定 -f 1.txt 参数即可，这样就实现了你说的测速一遍后再次对其测速筛选一遍。

qwerttvv commented 7 months ago

延迟和速度本来就不是绝对反比，因为影响因素很多，不过延迟低的 IP 遇到速度快的概率命令比延迟高的概率多很多，所以设计时就是先延迟测试，然后排序后从最低延迟开始测速。

对速度影响最大的还是丢包（也代表了线路拥塞堵车了，低优先级的包就被丢弃了，被丢弃的包一段时间后会重新传输，但因为拥塞还可能再被丢弃，所以只要丢包了，速度/稳定性就是断崖式下降），所以排序时也会先按丢包率排序，再按延迟排序，这样丢包的 IP 都会被排到末尾（即使延迟很低）。

你说了这么多，我简单看了下没啥意义，因为同一个 IP 不同时间测速结果差别很大，甚至通过 IP 你连续下载测速几次得到的结果都可能是天差地别。

至于你说的 【下面是另一个进阶的想法，于主题无关】，这个以前有人提过类似的需求（#454 #204 ），但这种功能是不会添加到软件内的，因为可以通过外部脚本实现。

我把 CloudflareST 设计成命令行程序，除了方便跨平台系统运行外，就是为了方便与第三方工具、脚本搭配使用，可以实现各种各样的需求，毕竟大家的需求都千奇百怪，真要都塞到 CloudflareST 里，那代码复杂程度直线上升，运行参数估计能翻几番，而且使用起来还非常不灵活。

只需要写个脚本，先指定参数运行一次 CloudflareST 获得输出的 结果.txt，然后从中提取输出的 IP 写入到 1.txt 中，然后再次运行 CloudflareST 并指定 -f 1.txt 参数即可，这样就实现了你说的测速一遍后再次对其测速筛选一遍。

那这样的话，下载测速这个步骤就多余，只ping一下就好了，反正下载测速的结果不确定因素太多。

tcp ping过后的结果无论如何是否下载测速，无论下载测试结果，最终都会无条件输出，这样的结果和是否下载测速没有任何联系了，下载测速就是多余的步骤啊，最多就是下载测试了，看一眼结果，然后哦一下，接受结果……

qwerttvv commented 7 months ago

按这个逻辑，第二次测速也没有意义，没办法剔除被干扰的ip

第一次20个全10mb/s，然后第二次测速，ping阶段也不会丢弃ip，下载测速也不会丢弃ip，我目标结果输出10个ip，然后实际15个下载被干扰，那最终结果10个里有5个就是完全不靠谱的也不会被剔除

这样的结果无意义，或者如果说哪怕5个排头可用的ip也可能被干扰的话，那整套软件就完全无意义了，没有存在的必要

XIU2 commented 7 months ago

本质上还是因为去年墙对 Cloudflare CDN 的 IP 干扰导致的 #217 ，这个问题不解决，你折腾什么都一样。 而在此之前，是完全不需要考虑这种事情的，当时只需要考虑 Cloudflare 的 IP Anycast 路由变动导致的延迟/速度变化。

当然，也是因为太多人用代理套 Cloudflare 了，墙又不能一刀切完全封死 Cloudflare CDN，所以选择了对其 IP 干扰，只要这种套 CDN 的方案还是主流，那么 Cloudflare 就会一直被干扰下去。

另外，CloudflareST 并不仅仅只能用于测速 Cloudflare CDN，其他 CDN、网站 IP 什么的都行，这工具本身就是我自用的顺便分享出来罢了（我开源的所有项目都是这样），自从去年墙开始对其 IP 干扰后，我就很少拿来测速 Cloudflare 了，因为我改用 IPv6 了，不过因为 IPv6 数量太多，所以我也就单纯延迟测速。

所以下载测速有没有用，取决于你的目的及怎么用，不是什么情况下都适用的，否则我为什么一开始就加上了 -dd 参数功能？

另外大部分时间，我拿 CloudflareST 都是用来测速找到某个网站众多 IP 中速度最快的，就像我项目里所说的那样，我就是为了加速网站访问才临时写的这个工具。

说实话，你描述的需求有点抽象，不知道是你写的逻辑问题还是我理解能力不行，说实话我都看不太懂你具体说的是什么。。。所以上面我只是挑着我能看懂的一部分回复了你。

需要说明的是，即使我完全看明白了你说的需求，我也基本上不会考虑添加，因为去对抗墙对 Cloudflare CDN IP 的随机干扰阻断是没有意义的，触发能找到其随机干扰阻断的规律，但即使运气好找到了，也不代表能解决。

包括你刚才说的 那最终结果10个里有5个就是完全不靠谱的也不会被剔除，因为我压根不清楚你说的 剔除、丢弃 什么的，所以我只能建议你加上 延迟测速条件、下载测速条件 这些参数来简单筛选，比如第一次速度快，第二次速度慢甚至没速度的就筛选掉了。 另外你也可以使用 HTTPing 来进行第二次测速，目前墙的阻断机制只有在建立 HTTP 协议链接时才会随机触发，因此 TCPing 和 HTTPing 的结果可能相差很大，前者测的再多也不会触发阻断干扰，而后者就容易出现。

HTTPing 就相当于一次只访问不下载的下载测速一样，而且因为只获取头部信息，所以不受下载测速地址文件大小影响。

我能帮你的就这么多，我也只是一个 CloudflareST 的使用者罢了~