前言

两条竖线分别是表示：

• 主动关闭（active close）的一方
• 被动关闭（passive close）的一方

网络上类似的图有很多，但是有的细节不够，有的存在误导。有的会把两条线分别标记成 client 和 server。给读者造成困惑。对于断开连接这件事，客户端和服务端都能作为主动方发起，也就是 active close 可以是客户端，也可以是服务端。而对端相应的就是 passive close。不管谁发起，状态迁移如上图。

问题描述

模拟高并发的场景，会出现批量的 time-wait 的 tcp 连接：

短时间后，所有的 time-wait 全都消失，被回收，端口包括服务，均正常。即，在高并发的场景下，time-wait 连接存在，属于正常现象。

线上场景中，持续的高并发场景：

• 一部分 time-wait 连接被回收，但新的 time-wait 连接产生；
• 一些极端情况下，会出现大量的 time-wait 连接；

所以，上述大量的 time-wait 状态 tcp 连接，有什么业务上的影响吗？

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

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

统计 tcp 连接的状态：

// 统计：各种连接的数量
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1154
TIME_WAIT 1645

tips: tcp 本地端口数量，上限为 65535 ，这是因为 tcp 头部使用 16 bit 存储端口号，因此约束上限为 65535。

问题分析

大量的 time-wait 状态 tcp 连接存在，其本质原因是什么？

• 大量的短连接存在；
• 特别是 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 分钟）

顺便提一嘴服务端出现大量 close_wait 的原因。多是由于服务端处理请求耗时过长，导致客户端超时，发起关闭链接，导致服务端大量的 close_wait。

参考链接：https://www.zhihu.com/question/298214130

出　　处：https://www.cnblogs.com/jmcui/p/15657676.html