ProxyCat研发过程中发现的Yakit伪并发

机缘巧合

关注早期ProxyCat项目的师傅应该会发现测试并发性能的时候一般都是通过Yakit这个工具来进行的，从100到500再到后面3000并发，都是使用Yakit进行测试并截图证明。

但是在用户使用的时候经常会有人提及并发能力不够，并发量一大就崩了，我一开始以为是代理池的问题，但是测试后发现直接使用代理池是能够支撑高并发的。

详细经过

那么问题来了，为什么在Yakit上测试3000+并发没问题，但是其他用户使用的时候就会出现并发不够的情况呢？可惜当时我并没有想到是Yakit本身的问题，它是伪并发！

可以从Github上的更新日志上看到从2024年08月24日开始一直到2025年01月07日我都在致力于提高ProxyCat并发能力上，可是在2024年12月初的时候我才发现，其实是Yakit的重放模块中的并发是伪并发！同时在2024年12月04日与Yakit的开发师傅进行了一场沟通并告知了这个问题。

随后Yakit更新了版本增加了连接池的方式提高“并发能力”。但是测试一下就能发现其实只是略微提高了一点点，但是根本原因并没有得到处理。

关于连接池等概念我个人认为是减少新连接创建，在一定的连接数内进行不断的数据交换，而不是按照HTTP常规的交互结束就关闭连接。这样的效果是减少了连接创建和关闭的时间，但实际上它无法解决伪并发的问题。

这是因为连接池的使用依然是顺序发送，即使建立了连接也仍然是按顺序来进行，（即：创建连接 -> 请求 -> 处理 -> 响应 -> 请求 -> 处理 -> 响应 -> 关闭连接）这样是无法同时进行并发请求的。按正常并发理解来说，创建连接后的请求应当是同时发送，（即：创建连接 -> 请求500 -> 处理 -> 响应500 -> 关闭连接）只有在同时发起请求的时候，这才能保证同时进行处理而不是等待处理并返回结果后才进行下一个请求。

这方面我觉得Yakit的开发师傅思路可能有些问题，以上是我个人的一些想法和判断，如果有用的话可以参考一下。

值得一提的是，来自Yakit的师傅响应速度也是非常的快，在我发出几分钟后就联系了我，这种官方对用户非常上心的状态，我觉得是非常有利于项目进步的，值得夸赞。

复现过程

接下来的复现过程都是今天午休（2025年03月04日）的时候截图编写的，节省篇幅就只拿一个目标进行测试证明，有兴趣的可以自行拓展。

环境为Yakit最新版本

采用请求内容与响应内容都较少（内容少的话可以极大程度减少处理过程，包括但不限于各种解码解包处理等等）的IP查询站点来验证：https://ipinfo.io/ip

可以从配置上看到是启用了连接池（也就是官方发出的修复方案），并发配置为500，但实际上也就是一百左右的并发量

因为Yakit存在大量包会简略显示的情况，所以前面不完整的包不算时间，大概是从第3131个包开始看，这一秒的最后一个包是31分48秒的响应。

从第3132个包开始算起，500并发应该是至少500个包，也就是到第3632个包，期间可能受网络、网站影响，允许上下波动1秒左右（响应时间基本在200ms+）也就是现在是31分49秒，可以允许到31分50秒左右。

仅到第3322个包的时候就出现31分50秒的了，为了避免波动引起的误差，继续往下看。

从第3468个包开始直接就到31分51秒了，仅仅三百个包就出现2-3秒这很明显与预计的有不小差距。

接下来相同请求包、相同网络环境、相同配置来对比Burp的情况

测试逻辑跟Yakit一样，截图也是按照第一个包开始算，从记录可以很明显的看到，从第298个包一直到第798个包，500并发是正确的，并且从第一个包到最后一个5000个包，一共用时12秒，去掉开头误差和响应误差，5000/500=10秒基本是差不多的

而且这是响应内容和请求内容都比较少的站点，如果换到请求一些内容较多（例如www.baidu.com这样超多html内容）的目标，这样的时间差距还会进一步拉长。

反观Yakit的请求都不需要看第一个包，直接就是几分钟后了，这个差距是肉眼可见。

最后一说

到这里其实已经很明朗了，Yakit的并发有点类似于Python伪并发的问题，因为我不会Yak语言所以我也无法下判断，就交由Yakit的开发师傅来研究修复吧。

Yakit作为国产软件会比较倾向于国人，我个人是非常喜欢它的重放界面、浏览器小插件这些东西，所以我也希望能越做越好，对我的生产力也会有很大的帮助。

另外ProxyCat也是被不少公司直接拿来生产环境使用了，这对于我来说也是一种肯定，说明它的存在是有意义的，是被大家认可的！

也希望能有更多的朋友能尝试一下我这款开源工具，如果好用的话也希望您可以帮忙点一下Star、分享安利一下、有点小钱的话打赏赞助一下，这对开源作者非常关键！