1、TIME_WAIT的产生原因是TCP连接是双向的，关闭连接时两个方向都需要分别关闭。 发起FIN数据包的一方执行主动关闭，而发起FIN数据包的一方执行被动关闭。 主动关闭的一侧为TIME_WAIT状态，在该状态停留2倍的MSL时间。 TIME_WAIT问题总结网易杭州QA网易杭州QA Team MSL是指报文段的最大生存时间，如果报文段在网络上进行MSL时间活动，但尚未收到，则将其丢弃。 关于MSL的大小，RFC 793协议建议的时间为2分钟，但实际上设置可能因操作系统而异。 以Linux为例，通常是一半。 两倍的MSL是1分钟，也就是60秒。 然后，这个数值被硬编码在内核中。 也就是说，除非重新编译内核，否则无法更改。 TIME_WAIT状态存在的必要性。 为什么自主关闭的糟糕自行车不会直接进入关闭状态，而是先进入time_wait，停留两倍的MSL时间呢？ 这是因为TCP是建立在不可信网络上的可信协议。 主动关闭的坏自行车收到被动关闭的坏自行车发来的FIN数据包后，返回ACK数据包，同时进入TIME_WAIT。 但是，由于网络的原因，主动关闭的坏自行车发送的ACK数据包可能会延迟，被动关闭的一方可能会重新发送FIN数据包。 那样的话，在极端的情况下正好是2MSL。 如果主动关闭的坏自行车直接关闭，或者低于两倍的MSL时间关闭，就会被动关闭发出重发FIN数据包到达，不存在旧连接，出现系统只能发回RST数据包的问题延迟数据包可能干扰新连接。 TCP可能不可靠。
2、TIME_WAIT的过多危害是在生产过程中，如果服务器使用短连接，在一次请求结束后会主动断开连接，引起大量的TIME_WAIT状态。 因此，系统通常采用较长的连接，以减少建立连接的消耗，同时也减少TIME_WAIT的发生，但即使没有实际使用较长的连接进行配置，TIME_WAIT的生产速度也远远高于其消耗速度TIME_WAIT状态的连接过多会导致一些问题。 如果客户端的TIME_WAIT连接太多且不断出现，则客户端端口将耗尽，不再分配新端口，并出现错误。 如果服务器端的TIME_WAIT连接过多，客户端请求连接可能会失败。 下面举这个为例。
情况1 :
将nginx作为反向代理时，连接到tomcat等服务器。 在测试过程中，由于不同的并发压力，nginx服务端口资源耗尽问题多次重复出现。 表示nginx服务器上发生了大量time_wait状态的连接，端口资源已耗尽。 (nginx错误： cannot assign请求地址)。 首先，确保nginx打开了长时间连接的keepalive。 但是，系统中仍然存在大量的TIME_WAIT。 如上所述，如果系统生成TIME_WAIT的速度大于消耗速度，这与累计TIME_WAIT相同。 原因是keepalive的配置太小，增大它可以解决问题。 (PS:nginx的总keepalive连接池大小=keepalive可能的值* nginx工作器数量)
情况2 :
应用某一层次的系统架构Nginx tomcat，Tomcat服务器出现了大量的TIME_WAIT。
作为反向代理，Nginx的长连接配置主要有三个方面： upstream的keepalive设置单个工作器的最大请求数，参数proxy_http_version 1.1被强制转换为http1.1协议。 (proxy_set_header Connection将请求标头的connection留空(http1.0请求的默认连接标头为close )，后面两个置于服务器域中。 配置后的问题可以解决。 但是，不禁怀疑TIME_WAIT是否出现在Tomcat而不是Nginx上。 从捕获中可以看出，Nginx发送到Tomcat包头的连接是关闭的，因此Tomcat在处理头请求后会自动关闭，因此Tomcat服务器上显示TIME_WAIT
参考： http://www.zuoqin.me/time_wait问题总结/