1. TIME_WAIT状态原因TCP协议包括11种不同的状态，其中TCP连接基于发送和接收的消息转换状态。 下图的状态机显示了不仅是正常状态，还可能包括异常状态下的状态转移的所有转移。
使用TCP协议wgdjm的两者在关闭连接时触发TIME_WAIT状态。 关闭连接的操作实际上传递到wgdjm的另一个自己没有需要发送的数据，但仍为保持了接收对方数据的能力。 关闭常规连接的过程包括：
客户端没有要发送的数据时，向服务端发送FIN消息，发送消息时为FIN_WAIT_1状态。 服务端接收到客户端的FIN消息时，处于CLOSE_WAIT状态，向客户端发送ACK消息，客户端接收到ACK消息时，处于FIN_WAIT_2状态。 如果服务端没有要发送的数据，服务端会向客户端发送FIN消息。 客户端接收到FIN消息后，将进入TIME_WAIT状态，向服务端发送ACK消息，服务端接收后将进入关闭状态。 客户端在等待http://www.Sina.com/(maximumsegmentlifetime，MSL )的时间后仍处于关闭状态。
上述过程表明，TIME_WAIT仅发生在主动断开的一侧，被动断开的一侧直接处于关闭状态，进入TIME_WAIT的客户端需要等待2 MSL才能实际关闭连接。 TCP协议需要TIME_WAIT状态的原因与客户端需要等待两个MSL不直接进入关闭状态的原因相同。
延迟的数据段不被使用相同源地址、源端口、目的地址和目的端口的其他TCP连接接收。 确保TCP连接的远程正确关闭。 也就是说，被动关闭连接的一方等待接收与FIN对应的ACK消息； 2 .原因分析——阻止延迟段linux上的一个TCP端口打开两次或更多次。 客户端处于time_wait状态时，无法使用此端口建立新连接。 如果不存在time_wait状态，则新连接可能会接收旧连接的数据。
每个TCP段都包含唯一的序列号，序列号保证了TCP协议的可靠性和顺序性。 如果不考虑序列号溢出零，序列号是唯一TCP协议的重要约定，如果违反此规则，可能会导致混乱和结果。 为TCP连接分配新序列号之前，为其分配两个最大数据段生命周期，以防止新TCP连接的数据段与网络上仍在传输的历史连接的数据段重叠。
在上图所示的TCP连接中，服务器发送的SEQ=301消息在TCP连接断开之前由于网络延迟而未被接收。 如果重用使用相同端口号的TCP连接，则会向客户端发送一条SEQ=301的消息，但此过期消息可能会被客户端成功接收，这会引起比较严重的问题，因此http://www.Sina .
RFC 793指出TCP连接需要TIME_WAIT等待两倍的MSL，但没有说明这里的两倍来自哪里。 合理的解释是— 至少静默数据段在网络中能够存活的最长时间，即 MSL，所以每次需要等待两倍的时间。
RFC 793文档将MSL的时间设置为120秒，即2分钟。 但是，这不是严格估计的数字，而是工程上的选择，根据服务历史经验要求更改操作系统设置也没有问题。 事实上，在Linux的早期版本中，为了更快地回收TCP连接资源，我们开始将TIME_WAIT的等待时间TCP_TIMEWAIT_LEN设置为60秒。
在Linux上，客户端的可用端口号为32，768到61，000，共有28，232个端口号连接到远程服务器。 可以从约3万个端口号中任意选择APP应用程序。
$ sysctl net.IP v4.IP _ local _ port _ range net.IP v4.IP _ local _ port _ range=3276861000但是主机在过去一分钟内将成为目标主机
3 .根据原因分析——保证连接停止根据RFC 793的TIME_WAIT状态的定义，此状态的另一个重要作用是等待足够长的时间来确认远程TCP连接是否接收到对应于其发出的连接结束消息FIN的ACK。
如果客户端等待时间不够长，则在服务器没有收到ACK消息的情况下，客户端重新建立与服务器的TCP连接会出现以下问题： 由于服务端没有收到ACK消息，因此认为当前连接是合法的。 当客户端重新发送SYN消息并请求握手时，服务器将收到RST消息，连接建立过程将结束。
【在调整 TIME_WAIT 策略时要非常谨慎】
默认情况下，如果客户端等待足够长的时间，则会出现以下两种情况：
服务端成功收到ACK消息，并关闭当前TCP连接。 服务端没有收到ACK消息，重新发送FIN关闭连接，等待新的ACK消息； 只要客户端等待2 MSL的时间，客户端和服务端之间的连接就会成功关闭，新创建的TCP连接受影响的概率也很小，保证了数据传输的可靠性。
参考资料之间的连接正常关闭，新创建的TCP连接受影响的概率也很小，保证了数据传输的可靠性。
参考资料https://draven ess.me/whys-the-design-TCP-time-wait /