反连模块的阻塞问题

[djerryz]

问题1：连接逻辑

Xray webscan listen模式启动时，若webhook端口还未开放或者 reverse的端口还未开放，则整个扫描过程中webhook和reverse功能都是失效的。 这样就严格要求了启动顺序，对于使用而言体验并不太好，建议可以改成定期检查，或者就算检查不通过，依然向webhook吐输出。

问题2：阻塞

当在Retry Reverse的Warning状态时，Xray mimt返回的状态为502或500，且此时投料的URL不会进入任务队列。 一旦Listen和Reverse之间由网络波动，导致Listen进入Retry逻辑，期间经过Listen的Url任务全部丢失不说，而且严重影响了上层业务逻辑(502的原因) 检查Reverse可以异步进行，不需要高实时性，尤其对于我而言是将xray listen作为了Linux service ， 导致listen和reverse有长时间的连接，这部分开销是没有必要的，可以将获取数据结果的时间间隔拉长，在退出之前再统一拉一次结果即可。

且Retry期间URL不进入任务队列的BUG建议发版修改掉！！

类似问题： https://github.com/chaitin/xray/issues/1637

[djerryz]

大部分开销都用来retry了:

大部分人的反连平台都是部署再云虚拟机，而xray是本地化，存在网络波动非常正常，但是获取reverse数据没必要这个高的实时性啊！

[djerryz]

修复建议

1. 去掉webhook和反连连接的前置性检查
   2. 构造Array - 长度2000， 存放推送到webhook过程失败的数据(连接失败或者状态码非200),
2. 单独的线程依次枚举Array数据推送，再次失败进行加权
3. 失败数据量到达Array最大长度，根据加权值和插入数据时间，去掉旧的且尝试次数多的数据，插入新数据

被去掉的数据当作连通性错误的牺牲品，避免影响整个流程执行。 反连数据的获取和webhook可以用一套逻辑，通过维护Array通过线程来完成，而不占用主流程，最好连通成功之后的请求一次多拉取点数据。

[Jarcis-cy]

webhook确实可能存在阻塞问题，但是反连的检测是独立出来的，并不会造成阻塞，同时我也测试了一下，并没有不接受新的目标。 后面会优化一下webhook可能造成阻塞的问题

[Jarcis-cy]

我们在xray 2.0 里面，可以自定义golang插件，理论上插件定义漏洞事件，即可实现自定义的webhook，等后续golang插件的教程出来之后，会有一个示例