高并发状态下，TCP连接TIME_WAIT怎么处理

在实际开发过程中，难免遇到高并发状态，无论是上线时还是测试环境，会出现大量的 TIME_WAIT 的 TCP 连接。

不用多久，这些TIME_WAIT会消失，被回收，其他服务也暂时表现正常。所以，在高并发的场景下，TIME_WAIT 连接存在，属于正常现象。

大量的TIME_WAIT状态有什么业务上的影响吗？

Nginx 作为反向代理时，大量的短链接可能导致 Nginx 上的 TCP 连接处于 time_wait 状态：

• 每一个 time_wait 状态，都会占用一个「本地端口」，上限为 65535(16 bit，2 Byte)；
• 当大量的连接处于 time_wait 时，新建立 TCP 连接会出错，address already in use : connect 异常

我们可以统计 TCP 连接的状态：

TCP 本地端口数量，上限为 65535（6.5w），这是因为 TCP 头部使用 16 bit，存储「端口号」，因此约束上限为 65535。

本质原因

• 大量的短连接存在
• HTTP 请求中，connection头部取值被设置为close时，需要由「服务端」发起主动关闭连接
• TCP四次挥手关闭连接机制中，为了保证ACK重发和丢弃延迟数据，设置time_wait为2倍MSL（报文最大存活时间）

TIME_WAIT状态

• TCP连接中，主动关闭连接的一方出现的状态；（收到 FIN 命令，进入 TIME_WAIT 状态，并返回 ACK 命令）
• 保持 2 个MSL时间，即4 分钟；（MSL 为 2 分钟）

解决办法

time_wait 状态大量存在会导致新连接创建失败，一般解决办法：

• 客户端，HTTP 请求的头部，connection 设置为 keep-alive，保持存活一段时间：现在的浏览器，一般都这么进行了
• 服务器端，允许 time_wait 状态的 socket 被重用、缩减 time_wait 时间，设置为 1 MSL（即，2 mins）

TCP 三次握手和四次握手