time_wait close_wait场景分析

最近分析模块监控，发现有一些tcp连接处于time_wait和close_wait状态。故结合实际场景温习一下Tcp连接释放的过程。

如图，tcp四次挥手过程中，主动发起连接关闭的一方会经历TIME_WAIT状态。

客户端TIME_WAIT

在常见的C/S体系中，连接断开请求一般由客户端发起，在经历2MSL后连接才算正常关闭。Linux 系统里有一个硬编码的字段，名称为TCP_TIMEWAIT_LEN，其值为 60 秒。也就是说，Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。在服务器同时作为客户端的场景下，60秒的等待时间意味着此端口在60秒内都不能作为客户端端口发起连接，在并发度高时，这个阻塞时间是不能被接受的，可能会造成端口耗尽。

解决方案是net.ipv4.tcp_tw_reuse选项，该选项

Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0.It should not be changed without advice/request of technical experts.

即允许新连接在1S后复用处于TIME_WAIT状态的端口。

服务端TIME_WAIT

服务端的主动关闭连接常见于连接长时间未使用服务端回收，或者服务端未正常关闭时。如，mysql设置了 wait_timeout 会主动关闭超过配置时长未使用的连接。

这时如果需要尽快重用端口，或想要服务快速重启并提供服务，可以在tcp服务启动时配置用户态选项SO_REUSEADDR，使处于TIME_WAIT状态的端口可以复用并提供服务。

客户端CLOSE_WAIT

根据上图，连接被动关闭的一方会进入CLOSE_WAIT状态， CLOSE_WAIT状态什么时候终结， 取决于应用程序什么时候来close socket, 所以， 从理论上来讲， 只要被动关闭端不断电， 进程不退出， 那么CLOSE_WAIT状态就会一直持续下去。

所以，CLOSE_WAIT对于客户端的影响是很大的，他可能长期占用端口导致端口不可用。如果客户端出现大量CLOSE_WAIT可以排查客户端输入流是否有正常关闭。若客户端流未正常关闭可能造成连接半关闭的情况，只能等待服务端关闭连接。通过tcpdump抓包可以看出，服务端关闭连接发送FIN包，客户端只响应了ACK。由于流未正常关闭，队列Recv-Q还未清零，客户端不能正常发送FIN包，CLOSE_WAIT状态将永久，直到有请求复用连接，会发现连接不可用，收到服务器发来的RST包，客户端才会将不可用连接清除。