最近分析模块监控，发现有一些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可以排查客户端输入流是否有正常关闭。若客户端流未正常关闭可能造成服务端主动关闭客户端连接的情况。并伴随着输入端socket buffer有堆积情况。