一、TCP连接断开的四次挥手：

　　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
　　其原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段1）。
（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段2）。和SYN一样，一个FIN将占用一个序号。
（3）服务器关闭客户端的连接，发送一个FIN给客户端（报文段3）。
（4）客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段4）。

双方状态详解：
　　ESTABLISHED：双方建立了连接。
　　FIN_WAIT_1：这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
　　FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
　　TIME_WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
　　CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
　　LAST_ACK：这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

我们可以看到，主动关闭方在接收到对方发送的FIN报文后会进入TIME_WAIT状态等待2MSL时长。

二、需要TIME_WAIT的原因：

为实现TCP全双工连接的可靠释放
为使旧的数据包在网络因过期而消失

1.为实现TCP全双工连接的可靠释放

TIME_WAIT是为了等待足够的时间以确保主动关闭方最后发送的ACK能够让被动关闭方接受，从而使其正确关闭。由TCP状态变迁图可知，假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

2.为使旧的数据包在网络因过期而消失

TIME_WAIT状态会持续2MSL时长，这个时长足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失。再出现的数据包一定就是新连接产生的。

MSL（Maximum Segment Lifetime）最大报文生存时间
每个TCP实现必须选择一个MSL。它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL时间。RFC 793指出MSL为2分钟，现实中常用30秒或1分钟。

为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。而TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是“感知”不到的。这样就可能发生这样的情况：前一条TCP连接由其中一方发送的数据到达另外一方后，会被这一方的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层（而事实上，在我们假设的场景下，这些旧数据到达前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的），从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。

TIME_WAIT过多的危害

过多的 TIME-WAIT 状态主要的危害有两种：

内存资源占用；
对端口资源的占用，一个 TCP 连接至少消耗「发起连接方」的一个本地端口；

第二个危害是会造成严重的后果的，要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过如下参数设置指定：

net.ipv4.ip_local_port_range

如果「发起连接方」的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。

客户端（发起连接方）受端口资源限制：

客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就 65536 个，被占满就会导致无法创建新的连接。

服务端（被动连接方）受系统资源限制：

由于一个四元组表示 TCP 连接，理论上服务端可以建立很多连接，因为服务端只监听一个端口，不会因为 TCP连接过多而导致端口资源受限。但是 TCP 连接过多，会占用系统资源，比如文件描述符、内存资源、CPU 资源、线程资源等。

参考链接：
4.1 TCP 三次握手与四次挥手面试题
TCP面试常见题：time_wait状态产生的原因，危害，如何避免

TIME_WAIT状态产生的原因、过多的危害相关推荐

【网络编程】time_wait状态产生的原因，危害，如何避免
转自:https://blog.csdn.net/u013616945/article/details/77510925 做略微修改仅供个人学习 1. time_wait状态如何产生? 在tcp ...
TCP面试常见题：time_wait状态产生的原因，危害，如何避免
http://blog.csdn.net/u013616945/article/details/77510925 MSL(Maximum Segment Lifetime)最大报文生存时间 ...
TCP/IP详解--TIME_WAIT状态存在的原因
1. 实际问题初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAI ...
time_wait状态产生的原因，危害，如何避免
1.先来了解TCP四次挥手的过程: ①第一次:主机1(可以使客户端,也可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段:此 ...
TIME_WAIT状态及存在原因
1. 客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口状态为TIME_WAIT: 2. 主动关闭的Socket端会进入TIME_WAIT状态,并且持续2MSL时间长度, ...
服务端大量处于TIME_WAIT和CLOSE_WAIT状态连接的原因
服务端大量处于TIME_WAIT和CLOSE_WAIT状态连接的原因 1.服务端大量处于TIME_WAIT状态的连接原因? 1.HTTP没有使用长连接 2.HTTP长连接超时 3.HTTP长连接的请求 ...
服务端大量处于 time_wait和close_wait 状态连接的原因
本片好文转自 Java灵风 https://www.toutiao.com/article/7176629612062327355/?app=news_article&timestamp=16 ...
TIME_WAIT状态的原因及解决办法
相关索引:https://blog.csdn.net/knowledgebao/article/details/84626184 目录 1,基础普及: 三次握手: 四次挥手 2,正文:那么服务端如何消 ...
netstat -ano | findstr 8611查看到大量的TIME_WAIT状态的解决办法
最近使用wsdlpull开源库curl模块调用webservice服务的压力测试的时候遇到的一个问题,其直接表象是客户端在发送http请求时失败,最终原因是客户端的TIME_WAIT状态的socket ...

TIME_WAIT状态产生的原因、过多的危害