问题根源：

为什么会产生time-wait？

当客户端与服务器之间进行四次断开时,当客户端接收
到服务器端发送过来的断开确认报文后,会发送最后一次
ACK报文,发送之后客户端会进入time-wait状态,这个过
成会持续一分钟,用来完成接收剩余所有从服务器端发送
过来的数据[由于网络延迟等原因导致数据延迟达到],
同时也可以确自己发送的最后一个ACK断开确认报文能被
服务器端收到！

time-wait状态的危害：

1 time-wait状态会占据一定量的内存资源,虽然很少但
是如果这种连接在一个繁忙的服务器中过于多的话,会额外消耗内存资源

2 time-wait状态会占据文件描述符,因为要通过网络和
web程序通信,需要监听套接字文件,这样不仅会占用端
口还会占用文件描述符,在高并发短连接的场景中,额外
致命,往往一个连接请求一个资源需要几秒中,但是time
-wait连接却要等待1分钟,这往往会迅速消耗端口和描述符资源
当达到设置的阀值时,新的TCP连接的建立将会受到影响

如何检测这种状态：

方法1：
netstat -tnl | awk '/^tcp/{print $6}' | uniq -c
可以设置周期性任务计划将这类数据追加至一个文件中
进行查看！

方法2：
使用zabbix自定义key time-wait connection
在agent端使用UserParameter= 来创建一个收集这个值
的命令定期传递给服务器端,在服务器端设置触发器来
监控这个值的正常范围

解决方案思路：

1 linux系统自身参数设置过小：
调整如下参数：

所有用户一共可以打开的文件数：
[root@zabbix-server13:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

单用户可打开的文件数：
[root@zabbix-server13:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

web服务器自身是否开放进程数过小：
可以调整最大并发访问值等参数

linux系统端口范围：
[root@zabbix-server13:44:32~]#sysctl -a | grep ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768    60999
可以选择开放1024端口之上的所有端口！
1024 ~ 65535

2 如果是因为软件开发原因导致可暂时设置如下参数：

net.ipv4.tcp_tw_recycle = 1 
表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭

net.ipv4.tcp_tw_reuse = 1 
表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_fin_timeout = 60
缩短系统设定的time-wait时间

net.ipv4.tcp_syncookies = 1
表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN***，默认为0，表示关闭；

先有效控制time-wait的数量然后在排查问题所在！