在实际开发过程中，难免遇到高并发状态，无论是上线时还是测试环境，会出现大量的 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 连接的状态：
|
1 2 3 4 5 |
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' ESTABLISHED 1154 TIME_WAIT 1645 |
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 三次握手和四次握手
原创文章，作者：蓝洛水深，如若转载，请注明出处：https://blog.lanluo.cn/11492
微信扫一扫 
支付宝扫一扫 