我回头研究一下这个，有更详细的测试过程嘛

time_wait 这个问题我也没想好怎么解决，已经port.close()之后还是会存在

有 我用的ip列表 几千个数量 然后字典用的500条的
-t 测试用的话必须>100 200-400比较好

fscan -m ssh -np -p 22 -user root -pwdf /sft/dict/dict.txt -hf /data/list -time 3 -t 100
然后我写了个脚本 能监控wait / time_wait数量
可是2个程序数量都差不多 这让人反而更疑惑了

这是ncrack的
SYN=20 EST=237 WAIT=2322 TW=2276 FIN=27
SYN=18 EST=234 WAIT=2262 TW=2215 FIN=26
SYN=29 EST=229 WAIT=2315 TW=2267 FIN=28
SYN=20 EST=235 WAIT=2308 TW=2263 FIN=25

From 192.168.1.1: bytes=60 seq=0001 TTL=64 ID=c5d5 time=9.541ms
From 192.168.1.1: bytes=60 seq=0002 TTL=64 ID=c5d6 time=15.769ms
From 192.168.1.1: bytes=60 seq=0003 TTL=64 ID=c5d7 time=1.717ms
From 192.168.1.1: bytes=60 seq=0004 TTL=64 ID=c5d8 time=1.326ms
From 192.168.1.1: bytes=60 seq=0005 TTL=64 ID=c5d9 time=1.283ms
From 192.168.1.1: bytes=60 seq=0006 TTL=64 ID=c5da time=0.981ms
From 192.168.1.1: bytes=60 seq=0007 TTL=64 ID=c5db time=0.820ms
From 192.168.1.1: bytes=60 seq=0008 TTL=64 ID=c5dc time=58.704ms
From 192.168.1.1: bytes=60 seq=0009 TTL=64 ID=c5dd time=1.288ms
From 192.168.1.1: bytes=60 seq=000a TTL=64 ID=c5de time=0.992ms
rtt就小有波动然后立刻恢复了

fscan的我等会补下数据
连续跑了一阵 现在是
SYN=29 EST=226 WAIT=2288 TW=2205 FIN=66
SYN=17 EST=237 WAIT=2251 TW=2168 FIN=62
SYN=14 EST=241 WAIT=2285 TW=2202 FIN=63
SYN=13 EST=242 WAIT=2223 TW=2140 FIN=62

fscan
SYN=29 EST=73 WAIT=2205 TW=2192 FIN=16
SYN=26 EST=78 WAIT=2258 TW=2251 FIN=8
SYN=23 EST=82 WAIT=2310 TW=2304 FIN=7
SYN=31 EST=71 WAIT=2374 TW=2360 FIN=15

网关延时目前没什么异常 (但是连接很小 time_wait却和ncrack跑200多并发时候一样)
SYN=32 EST=171 WAIT=99 TW=8 FIN=4
SYN=24 EST=178 WAIT=224 TW=113 FIN=24
SYN=60 EST=143 WAIT=370 TW=220 FIN=61
SYN=40 EST=160 WAIT=494 TW=362 FIN=49
SYN=38 EST=166 WAIT=620 TW=499 FIN=40
SYN=43 EST=159 WAIT=754 TW=624 FIN=42
SYN=48 EST=157 WAIT=885 TW=759 FIN=40
SYN=49 EST=164 WAIT=1009 TW=888 FIN=34

上面是重新开-t 200的参数 网关立刻卡了
From 192.168.1.1: bytes=60 seq=043f TTL=64 ID=ca13 time=44.681ms
From 192.168.1.1: bytes=60 seq=0440 TTL=64 ID=ca14 time=79.018ms
From 192.168.1.1: bytes=60 seq=0441 TTL=64 ID=ca15 time=77.313ms
From 192.168.1.1: bytes=60 seq=0442 TTL=64 ID=ca16 time=55.437ms
From 192.168.1.1: bytes=60 seq=0443 TTL=64 ID=ca17 time=84.720ms
From 192.168.1.1: bytes=60 seq=0444 TTL=64 ID=ca18 time=94.563ms
From 192.168.1.1: bytes=60 seq=0445 TTL=64 ID=ca19 time=71.428ms
From 192.168.1.1: bytes=60 seq=0446 TTL=64 ID=ca1a time=102.685ms
From 192.168.1.1: bytes=60 seq=0447 TTL=64 ID=ca1b time=97.516ms
From 192.168.1.1: bytes=60 seq=0448 TTL=64 ID=ca1c time=101.325ms
From 192.168.1.1: bytes=60 seq=0449 TTL=64 ID=ca1d time=125.576ms
From 192.168.1.1: bytes=60 seq=044a TTL=64 ID=ca1e time=87.738ms
From 192.168.1.1: bytes=60 seq=044b TTL=64 ID=ca1f time=104.736ms
From 192.168.1.1: bytes=60 seq=044c TTL=64 ID=ca20 time=139.213ms
From 192.168.1.1: bytes=60 seq=044d TTL=64 ID=ca21 time=126.899ms
From 192.168.1.1: bytes=60 seq=044e TTL=64 ID=ca22 time=103.964ms

重新开了下 这时候就卡了 网关rtt连续变成好几十
SYN=66 EST=138 WAIT=125 TW=34 FIN=67
SYN=32 EST=169 WAIT=238 TW=180 FIN=39
SYN=41 EST=159 WAIT=398 TW=330 FIN=47
SYN=45 EST=153 WAIT=543 TW=483 FIN=37
SYN=34 EST=165 WAIT=676 TW=616 FIN=37
很奇怪 time_wait当时不怎么高 而且这个TW本身就是要卡一阵才消失
网络变卡的时候 关了程序 那些TW还在 但是网关负载顿时下去了.
这总不会是数据传输造成的卡顿把. 让人想不明白. 可是其他程序也是用这个并发 比他还大 反而没问题.
让我感觉莫名其妙的.