redis TIME_WAIT问题

发表于 更新于 分类于 本文字数： 3.7k 阅读时长 ≈ 3 分钟

我们知道TIME_WAIT状态是因为没有收到FIN-ACK的ack才会存在的。 下面这个是我们常见的tcp建立和关闭的流程图。

说下场景吧：

使用ab -n -c 对某一个接口进行压测，没有加-k的参数。
nginx是集成了lua-resty-redis进行使用的。所有lua代码里都加了

1
2
3
4
5
local ok, err = red:close()
if not ok then
    ngx.log(ngx.ERR, "failed close redis: ", err)
    return
end

redis的相关配置如下

1
2
timeout 3
tcp-keepalive 0

也就是不启用keepalive，timeout为3秒。

但是测试后发现，操作系统过了63秒才把所有TIME_WAIT回收了。

那这里就出现了2个问题：

  1. 我每次都close了，为什么还会有TIME_WAIT出现？
  2. 为什么是刚好60秒+timeout的时间回收？

下面是抓包的图例：

可以看到只有我nginx给redis的fin-ack回了ack，但是redis没有给nginx的fin-ack回ack。

1
2
3
$ redis-cli -h 127.0.0.1 client list
id=2 addr=10.10.11.18:6379 fd=5 name= age=23699 idle=0 flags=M db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=set
id=5099 addr=127.0.0.1:23233 fd=6 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

而且通过client list里也没有对应的连接，说明至少在redis应用认为这个连接是已经关闭了的。但是下面的网络状态里确实是实实在在存在。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ netstat -anpl | grep  '127.0.0.1:6379'
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.1:6379              0.0.0.0:*                   LISTEN      32249/redis-server
tcp        0      0 127.0.0.1:18935             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:22933             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:21807             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:23023             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:22617             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:19381             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:19825             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:20345             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:22963             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:20971             127.0.0.1:6379              TIME_WAIT   -
tcp        0      0 127.0.0.1:22411             127.0.0.1:6379              TIME_WAIT   -

TIME_WAIT的官方的解释是“FINs have been received and ACK has been sent passive TCP. active TCP is waiting 2MSLs to remove the connection from the connection table.”
也就是说redis已经发了ack了，但是nginx未必会收到，所以需要等待2MSLs时间。
我们这个系统的MSL是30秒

1
2
$ cat /proc/sys/net/ipv4/tcp_fin_timeout
30

所以正常就是60秒回收，然后加上之前设置的3秒timeout时间，那就是63秒回收了。第二个问题解了，那第一个还是没有出现转机。

按这个思路分析，看来是redis层面已经断开了，但是tcp层面却没有。看了下时间，这都是发生在几微秒之间的，会不会是因为这个原因呢。

想了下会不会是由于ab客户端的问题呢，因为nginx本身也有一样数量的TIME_WAIT存在。但是我尝试使用curl以http1.0的协议，同时header里加上了close也依然会产生TIME_WAIT。

1
2
3
4
5
6
7
8
9
10
$ netstat -anpl | grep  '120.xx.yy.zz:80'
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:57813        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:60279        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:58449        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:58837        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:59959        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:57651        TIME_WAIT   -
tcp        0      0 120.xx.yy.zz:80           120.xx.yy.zz:59497        TIME_WAIT   -

下面这个是把nginx的keepalive改为了0，请求里加了close和keepalivetime=0了，结果依然如此。现在只能说这个TIME_WAIT是所有服务器端都会碰到的问题了,
你没有要求客户端都回你一个FIN-ACK的ACK。但是在linux下的避免方法是可以设置net.ipv4.tcp_max_tw_buckets，这样限制了整体的timewait的数量。或者就是尽量用keepalive了，这个也是现在推荐的方式。