建议增加平均延迟下限条件

[moarlov]

如果不设置sl，会找到不少延迟几十毫秒但是速度是0的ip，如果设置sl，那么开始下载测速后挺长一段时间找到的节点数都是0，然后才陆续增加
我猜测开始下载后长时间节点数是0是因为从延迟最低的开始测，而延迟低的都不是正常cf节点
每个网络环境是相对固定的，用过一段时间后就能有个感觉。例如在我这里，我知道正常cf节点延迟不会低于120ms，那么如果让CloudflareST丢弃所有延迟低于120ms的，就能缩短下载测速时间

[XIU2]

你说的平均延迟 [几十 ms] 的 IP，其实是这个月才出现的（月初开会后）。
经过我的检查是属于 TCP 劫持（应该是一些海外网站默认解析这些 IP 被针对了，误伤了我们，也没发现什么规律）。

一般这种 IP 在下载测速时，都会因为不可用而直接断开连接（即很快就跳过去了），不过偶尔会遇到一些奇怪的 IP，这种 IP 会持续链接直到超时后才会继续测速下一个（往往测速为 0.01 MB/s）。

我会考虑添加 [平均延迟下限] 功能的，不过 Windows 64位 版本误报的情况比较烦（32位 及 其他系统没事），等我解决之后再折腾该功能。。。

[XIU2]

似乎进入 4 月后，就没有 Cloudflare CDN IP 的 TCP 劫持事件了（敏感时期过去了）。
具体时间我也不清楚，这两星期都没有遇到过几十 ms 的异常 IP 测速结果了。

[moarlov]

这段时间确实是比较少见到了

[XIU2]

你说的那些 IP 就是被假蔷的 IP。
因为很多人被假蔷勒索，然后它们套 Cloudflare 来抵御假蔷，结果就是 Cloudflare 大量 IP 被假蔷。
虽然被假蔷的 IP 很快就会解封，但是因为假蔷勒索泛滥，导致一直有新的 Cloudflare IP 被假蔷。

现在似乎越来越泛滥了，我还是给加上吧~

更新内容

1. 新增 [平均延迟下限] 参数。
   用于过滤被假蔷的 IP，这些 IP 因为被 TCP 劫持，所以延迟很低只有几十 ms
（一般除了移动直连香港外，几乎不存在低于 100ms 的，自行测试适合的下限延迟）

# 平均延迟上限：200 ms，平均延迟下限：40 ms （一般除了移动直连香港外，几乎不存在低于 100ms 的，自行测试适合的下限延迟）
CloudflareST.exe -tl 200 -tll 40
./CloudflareST -tl 200 -tll 40

# 平均延迟下限和其他的上下限参数一样，都可以单独使用、互相搭配使用！

[XIU2]

@moarlov
本来因为假蔷攻击泛滥导致 Cloudflare 大量 IP 被假蔷，但是自从前段时间 Cloudflare 限制了通过 CFP 来 CNAME 接入后，Cloudflare 大量 IP 被假蔷的情况已经大大缓解了。
因为要套 Cloudflare 抵御假蔷，就必须 CNAME 接入并轮询解析指向 CDN IP 才行。
现在虽然以前 CNAME 接入的还能继续，但是已经无法新域名 CNAME 接入了（限制了白票 CNAME 接入，加钱的话还可以）