kcptun_client端经常会有大量的CLOSE_WAIT连接

[maddie]

如题，服务器和客户端使用的都是20170303版本。其实这个问题一直都有，但是最近实在是非常影响使用所以就提个issue看看其他人有没有同样的问题。

配置：

crypt: salsa20
mode: fast2
mtu: 1400
nocomp: true

服务器端：

sndwnd: 2048
rcvwnd: 2048

客户端：

sndwnd: 512
rcvwnd: 2048
dscp: 46
conn: 4
autoexpire: 60

运行环境：
服务端ArchLinux，分别部署在DigitalOcean, Vultr和Linode上，内核是 4.9.7 或者 4.9.11
客户端有ArchLinux也有Ubuntu 16.04.2，内核分别是4.9.11和4.4.0

由于产生了大量的CLOSE_WAIT，连接会特别特别慢甚至连不上，必须要重启kcptun客户端才能恢复正常。kcptun两端是shadowsocks-libev 3.0.3，如果使用ss-local直连ss-server就没有问题

如需要提供其他信息，请告知

[xtaci]

CLOSE_WAIT是在哪端出现的？

[maddie]

client端，server端没有CLOSE_WAIT

[maddie]

刚刚更新20170308，重启服务不到几分钟：

$ sudo lsof -i -n -P | grep kcp | grep CLOSE_WAIT | wc -l
17

这是在client端的

[xtaci]

意思就是这个CLOSE_WAIT是kcp进程的？

[maddie]

是，都是kcptun_client的

[xtaci]

-scavengettl改过么

[maddie]

没有~除了开始提到的参数以外，其他都是默认值

[xtaci]

确定是release下载的，不是自己编译的，我这里第一次知道这个问题。

[maddie]

每次都是从release下载的，没有自己编译过。。

[xtaci]

看看其他人有没有碰到这个问题，我这里所有的 CLOSE_WAIT都不是client产生的。

[xtaci]

大概推断是因为你的autoexpire太短导致的。

[baggiogogo]

@xtaci
autoexpire正常情况下设置多少为宜？

[maddie]

@xtaci 同问

[xtaci]

只是猜测，我设置的300s， 但和CLOSE_WAIT是否有关系，其他人是否也有此问题也不知道，从来没人提过。

[maddie]

我把autoexpire直接去掉了，观察一段时间看看，回头过来汇报结果

[baggiogogo]

我到是没有遇到过影响使用的情况，只是在路由器防火墙连接里面会发现很多连接，前几个版本也有这个情况，不知是否正常。

autoexpire一直是150
conn是1

[xtaci]

连接多很正常，切换导致的，但CLOSE_WAIT不正常

[baggiogogo]

明白，感谢。

[ccsexyz]

有可能是因为阻塞在sess.OpenStream这里了,然后客户端到kcptun客户端的连接断开了

[xtaci]

@ccsexyz https://github.com/xtaci/smux/blob/master/session.go#L328
OpenStream是不会阻塞的

[maddie]

把autoexpire去掉半个小时以后，CLOSE_WAIT数量在client端达到了2400多。。😂

然后我想起了原本就是因为这样，我才加上autoexpire的，情况有所改善。。但是用的人多的时候（连接数多的时候），CLOSE_WAIT慢慢也会变很多，但是比不使用autoexpire的时候要好很多

[xtaci]

先分析下吧，主要是从来没有人提起，我这里因为kcptun导致的一个都没有。

[xtaci]

问题的核心是，kcptun在什么时候没有关闭掉accept的tcp连接。

[maddie]

对。。我这边不知道有什么排查方法

[xtaci]

kcptun-linux-386-20170308.tar.gz
kcptun-linux-amd64-20170308.tar.gz
@maddie 试下

这里可能引起 CLOSE_WAIT : a25c9eb

高频短链接可能会导致。

[maddie]

的确这里有可能在defer之前就return了。。

然后就是半个小时过去了，CLOSE_WAIT一直为0，看来是可以了。明天再看看就知道结果了~

[maddie]

就在这个时候 server 端突然就蹦出二十几个CLOSE_WAIT来

kcptun_se 473840     nobody   14u  IPv4 127659152      0t0  TCP 127.0.0.1:23806->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   26u  IPv4 127658049      0t0  TCP 127.0.0.1:23542->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   29u  IPv4 127641877      0t0  TCP 127.0.0.1:17872->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   42u  IPv4 127651489      0t0  TCP 127.0.0.1:21716->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   66u  IPv4 127656023      0t0  TCP 127.0.0.1:23014->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   76u  IPv4 127656259      0t0  TCP 127.0.0.1:23086->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody   95u  IPv4 127633283      0t0  TCP 127.0.0.1:13020->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  127u  IPv4 127654880      0t0  TCP 127.0.0.1:22702->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  131u  IPv4 127656151      0t0  TCP 127.0.0.1:23062->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  149u  IPv4 127659488      0t0  TCP 127.0.0.1:23998->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  165u  IPv4 127660414      0t0  TCP 127.0.0.1:24358->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  170u  IPv4 127657597      0t0  TCP 127.0.0.1:23422->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  177u  IPv4 127629144      0t0  TCP 127.0.0.1:11046->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  185u  IPv4 127657424      0t0  TCP 127.0.0.1:23370->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  208u  IPv4 127659744      0t0  TCP 127.0.0.1:24094->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  223u  IPv4 127660393      0t0  TCP 127.0.0.1:24332->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  228u  IPv4 127660002      0t0  TCP 127.0.0.1:24190->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  230u  IPv4 127660434      0t0  TCP 127.0.0.1:24382->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  237u  IPv4 127660262      0t0  TCP 127.0.0.1:24286->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  240u  IPv4 127660242      0t0  TCP 127.0.0.1:24262->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  243u  IPv4 127660562      0t0  TCP 127.0.0.1:24430->127.0.0.1:55555 (CLOSE_WAIT)
kcptun_se 473840     nobody  247u  IPv4 127631200      0t0  TCP 127.0.0.1:12012->127.0.0.1:55555 (CLOSE_WAIT)

这个可能就是其他问题了

[xtaci]

问题有没有解决？

[maddie]

18 hrs过去了，client端CLOSE_WAIT连接数为0，问题应该是解决了

另外想问问，server端的CLOSE_WAIT，一般是由什么原因造成的？好像是会慢慢累积，昨天重启到现在有200多个，而且不会减少的样子

[xtaci]

kcp server -> -target
kcpserver socket close()之后， target没有调用close()之前，处于CLOSE_WAIT状态。
也就是-target没有正确close()

[xtaci]

所以有怀疑要说出来哈，确实就是个BUG， 最新的release已经包含此fix

[maddie]

ok~~ 非常感谢~

服务端我每天重启一下好了，反正数量也不多

[jsvisa]

kcptun version 20170525

@xtaci 你好，我这边观察到的现象是 ss-redir 和 kcptun-client 之间有大量的 close_wait 状态连接（数量只增不减），然后查看进程 kcptun-client 打开的文件描述符，确认是 ss-redir 已经关闭了连接，然而 kcptun-client 没有把连接关闭导致的

[able8]

关注 。。