由于TCP协议整个机制也非常复杂我只能尽可能的在某一条线上来说，不可能面面俱到，如果有疏漏或者对于内容有异议可以留言。谢谢大家。
查看服务器上各个状态的统计数量：
netstat -ant | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'
单独查看TIME_WAIT，ss -nat | grep TIME-WAIT
ss命令中的TIME WAIT的写法和netstat中有所不同
TIME_WAIT的作用主动断开的一方的TCP连接会在这个状态下保持2MSL，其作用就2个：
确保对方收到自己发送的最后一个ACK（因为对方发送了FIN），如果对方没有收到自己发送的ACK必定会重新发送FIN，这样保证4次断开的完整性。因为MSL是最大报文生存时间，如果在1个MSL时间内自己发送的ACK对方没有收到那就注定收不到了，而且对方肯定还会发送FIN，那么一个FIN发送过来的最长时间也是1个MSL，所以这里要等待2MSL。
另外一个原因就是避免延迟的IP报文，在频繁短连接的场景下客户端通常会对同一个IP和端口在短时间内发起多次连接，而客户端使用的端口是自己系统随机分配的高位端口，有一定概率发生上一个socket四元组和下一个socket四元组一样，如果这时候一个原本属于上一个socket四元组的被延迟的IP报文送达，那么这将发送数据混乱的状态，所以为了避免这种情况就利用MSL这个报文最大生存时长机制让残余的IP报文在网络中消失。这时候同样的四元组又可以被使用了。
另外你无须担心这个迟到的IP报文是有用的，因为TCP是可靠连接，它有重传机制，所以这个迟到的IP报文消失不会影响之前通信的数据完整性。哪怕这个报文是在2MSL期间到达也将会被抛弃。
处于该状态的socket什么时候可以再次使用：
2MSL之后
如果处于2MS期间，重用连接那么要保证新连接的TCP的Seq也就是序列号要比之前的大
如果处于2MS期间，重用的连接要保证后续的时间戳要比之前的连接的时间戳更晚
只有满足上面的条件才不会在发生新连接上出现老连接的延迟的IP分组，满足第一个条件则不会出现延迟的IP分组，如果满足后面的条件那么延迟的IP分组即使出现在新连接上也会被直接丢弃进而不会影响现有通信数据。
使用Wireshark抓包在TCP中显示的Seq都是从0开始的，这是这个软件做了处理，如下图：
要想看真正的序列号需要做一个配置：
Wireshark-->Preferences-->Protocols-->Tcp
点击确定你就可以看到真实的Seq
2MSL到底有多长呢？这个不一定，1分钟、2分钟或者4分钟，还有的30秒。不同的发行版可能会不同。在Centos 7.6.1810 的3.10内核版本上是60秒。v3.10/source/include/net/tcp.h
TIME_WAIT会影响什么端口：但是这是对于通信过程中扮演客户端角色的一端来说，因为客户端使用随机端口来访问服务器，当它主动断开的时候会出现这个状态，比如第一次系统给它分配了一个51000的随机端口访问服务器，然后客户端主动断开了，在2MSL期间，该端口就处于TIME_WAIT状态，如果它再次访问相同的服务器，那么系统会为它再次分配一个随机端口，如果51000端口还处于TIME_WAIT状态，那么这个随机端口就肯定不是51000，如果51000端口不处于TIME_WAIT状态，那么这个随机端口就有可能是51000。所以这个状态在一定期间内对于客户端角色来讲会影响并发量，大量这个TIME_WAIT就导致可用随机端口不断减少。
内存：这个量会很小，无需担心，哪怕是上万的TIME_WAIT。
文件描述符：但是处于TIME_WAIT状态的套接字其实是已经关闭了文件描述符，也就是说这个状态并不占用文件描述符这也就是意味着该状态不会对应一个打开的文件。
如何解决网上很多人给出的答案是调整内核参数比如下面的参数，但是这些答案有很多误区，在不同场景下并不一定适用，所以这里先对参数做一下澄清：
net.ipv4.tcp_tw_reuse = 1
表示开启重用。允许将一个处于TIME-WAIT状态的端口重新用于新的TCP连接，默认为0，表示关闭，其防止重复报文的原理也是时间戳，具体看后面。
net.ipv4.tcp_tw_recycle = 1