标签：状态 tcp time close 连接 wait

前言

两条竖线分别是表示：

• 主动关闭（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 分钟）

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

标签：状态,tcp,time,close,连接,wait
来源： https://www.cnblogs.com/jmcui/p/15657676.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。