来源：http://ningg.top/computer-basic-theory-tcp-time-wait/
写在开头，大概 4 年前，听到运维同学提到 TIME_WAIT 状态的 TCP 连接过多的问题，但是当时没有去细琢磨；最近又听人说起，是一个新手进行压测过程中，遇到的问题，因此，花点时间，细深究一下。
之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章，不过当时基本属于浅尝辄止，并没深入说明问题的来龙去脉，碰巧这段时间反复被别人问到相关的问题，让我觉得有必要全面总结一下，以备不时之需。
Nginx 作为反向代理时，大量的短链接，可能导致 Nginx 上的 TCP 连接处于 time_wait 状态：
TIME-WAIT是服务器优化必然会谈到的一个话题，而我们常见的问题就是TIME-WAIT过多怎么处理？
工作中无论是开发环境还是线上环境，我们都出现过大量的 timewait 状态的连接，例如下面这个例子
然后打开Google，输入关键词：too many timewait。一定能找到解决方案，而排在最前面或者被很多人到处转载的解决方案一定是：
里头的分析过程有提到，通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。
很多面试中，特别是后端岗位，特别是和服务器相关岗位的面试中喜欢问这两个状态，首先回忆下这两个状态出现的时间，下面是三次握手和四次挥手的状态图
统计在一台前端机上高峰时间TCP连接的情况，统计命令： netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/ajianyingxiaoqinghan/article/details/89736329
相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep TIME_WAIT | wc -l " 查看一下, 接着发现有几百几千甚至几万个TIME_WAIT 连接数. 顿时慌了~
TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：
最近有同事在用 ab 进行服务压测，到 QPS 瓶颈后怀疑是起压机的问题，来跟我借测试机，于是我就趁机分析了一波起压机可能成为压测瓶颈的可能，除了网络 I/O、机器性能外，还考虑到了网络协议的问题。
TCP 连接关闭时，会有 4 次通讯（四次挥手），来确认双方都停止收发数据了。如上图，主动关闭方，最后发送 ACK 时，会进入 TIME_WAIT 状态，要等 2MSL 时间后，这条连接才真正消失。
之前使用github.com/olivere/elastic库遇到了一个TIME_WAIT堆积的问题，因为问题比较共性（引入新库、性能测试、TIME_WAIT原理），所以简单记录下，新同学可以关注下
TCP 断开连接四次挥手过程中，主动断开连接的一方，在第四次挥手（回复 ACK 报文）后，会进入 TIME_WAIT 状态，等待 2*MSL 后才进入 CLOSE 状态。
测试环境有一个后台服务，部署在内网服务器A上（无外网地址），给app提供接口。app访问这个后台服务时，ip地址是公网地址，那这个请求是如何到达我们的内网服务器A呢，这块我咨询了网络同事，我画了简图如下：
在构建基于 TCP 协议的 C/S 系统的时候，经常会因为一些简单的错误而导致严重的影响系统的可扩展性。 其中一些错误是因为对TIME_WAIT状态不理解导致的。 在本文中，我将会讲解为什么要存在TIME_WAIT 状态，它的存在所造成的一些问题以及如何解决这些问题。
在Liunx服务器上发现有 10倍于 LISTEN 服务的 time_wait 状态，服务并非高并发，日常的连接数也比较少，因此该现象明显异常
从图中可以看出，若服务器主动关闭连接，在四次挥手的最后一个ACK后连接端口会变为TIME_WAIT状态， 状态停留时长为两个MSL（最大分段寿命），这个状态只有在主动关闭连接方会出现， 另一端可以在连接断开后立刻投入后续使用。
网络上类似的图有很多，但是有的细节不够，有的存在误导。有的会把两条线分别标记成 client 和 server。给读者造成困惑。对于断开连接这件事，客户端和服务端都能作为主动方发起，也就是 active close 可以是客户端，也可以是服务端。而对端相应的就是 passive close。不管谁发起，状态迁移如上图。
昨天频繁的收到MySQL实例关于Aborted告警邮件，看到告警邮件的实例信息，测试实例，优先级没没那么高，晚点抽空在看，可能到时候就好了，抱着侥幸的心理继续划水，但是没过1个小时，收到50多封告警邮件，实在受不了了，准备放下手头的事情优先处理该告警问题； 如下是告警邮件相关信息截图：
注意事项：代码均可优化，因我写的为了结合案例，未曾使用框架，可替换内容，可自行优化。
该文章讲述了TCP连接中的TIME_WAIT状态，即TCP连接在关闭之后，等待2*MSL时间后才能重新被调用。同时，也介绍了TCP连接的Close_wait状态，即TCP连接在关闭之后，发送方等待2*MSL时间才能重新调用该连接。此外，文章还介绍了如何通过三次挥手来关闭TCP连接，并强调了TCP连接的半关闭状态，即只关闭了应用层未关闭传输层。
博主在因为获取知识的需求，开通腾讯云-轻量云服务器，在日常使用中没有什么问题，但是最近一直频繁收到邮件提醒，之前也没有想着去解决这个问题，今天又收到，就来解决了一下相关问题。
三次握手，四次挥手。 意思是tcp建立连接时需要三次交互来完成，A发起连接 A --- SYN --> B A <-- SYN + ACK --- B (1) A --- ACK --> B 而关闭tcp连接需要四次交互，A发起关闭 A --- FIN --> B A <-- ACK --- B (1) A <-- FIN --- B A --- ACK --> B (2) 这里在（1）时B开始处于CLOSE_WAIT状态，一直到收到ACK后B才转为CLOSED ，而
根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。
为了摸底项目的性能，需要进行性能测试。经过一番调研之后，决定使用基于腾讯云TKE的分布式jmeter进行压测，好处是有jmeter-suite可用，搭建环境方便；容器化部署可以方便的增加pod来提升压力。
相信很多小伙伴都碰到过一个问题，服务运行过程中，产生大量的未关闭的TCP链接，导至服务不可用直至服务异常。 该如何定位、排查这些未关闭的链接? 之前碰到过这个问题，解决了，今天有小伙伴又聊到这个问题，
TCP是全双工传输协议，也就是说双方都可进行读写操作，当一方不需要写数据时，会通过发送FIN报文告知对方，我要关闭连接了，对方接受到并返回ACK报文，这就表示一方的连接已经关闭，此时另一方的连接还是OK的，也就是说另一方还是可以继续写数据的，等到另一方也发完数据之后就可以发送FIN报文。
简单看下即可，由于含有定制化业务背景，架构图看不懂也没关系，后面我会对里面的核心技术点单独剖析讲解
上周有个读者在面试微信的时候，被问到既然打开 net.ipv4.tcp_tw_reuse 参数可以快速复用处于 TIME_WAIT 状态的 TCP 连接，那为什么 Linux 默认是关闭状态呢？
之前有读者在字节面试的时候，被问到：TCP 和 UDP 可以同时监听相同的端口吗？
MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”.
客户将mysql从IDC迁移至公有云后，时常有出现建立连接超时的情况，业务使用的场景是PHP短连接到mysql，每秒的新建连接数在3000个左右，这个量算是比较大。 客户反馈在IDC内自建时也是这样的使用场景，从未遇到过这个问题。
在断开连接之前客户端和服务器都处于ESTABLISHED状态，双方都可以主动断开连接，以客户端主动断开连接为优。
来源：https://github.com/wangcy6/weekly 每日一题 第二题
- 不像Windows 可以修改注册表修改2MSL 的值，linux 需要修改内核宏定义重新编译，tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2状态超时时间.
图中可以看到：主动关闭方将进入TIME_WAIT状态；被动关闭方将进入CLOSE_WAIT状态。
linux TIME_WAIT 相关参数: net.ipv4.tcp_tw_reuse = 0 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭 net.ipv4.tcp_tw_recycle = 0 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭 net.ipv4.tcp_fin_timeout = 60 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间（可改为30，一般来说
貌似 1.9.3 的客户端有 python2.7 的环境要求，于是弹出了警告，我们今天主要是了解 ssdb 状态，暂时不理会此警告
统计连接数，使用netstat命令或ss命令都可以 1）统计连接数（80端口） [root@wang ~]# netstat -nat|grep -i "80"|wc -l 872 或者：netstat -ant | grep $ip:80 | wc -l [root@wang ~]# netstat -ant | grep 111.142.132.192:80 | wc -l 872 2）查看当前并发访问数（统计已连接上的），状态为“ESTABLISHED” [root@wang ~]# netsta
在TCP断开连接四次挥手时, 主动发起关闭方会产生 TIME_WAIT, TIME_WAIT 是 TCP 协议可靠性设计的重要一个环节, 虽说增强了可靠性, 但是对于高并发场景下, 会产生大量的 TIME_WAIT, 导致高峰时段无端口可以使用.
测试工具选用locust，locust中文意思为蝗虫，可以想象，locust就像成片的蝗虫，扑向我们的服务。
** 若TIME_WAIT事件设置过短, 会导致错误后果 TIME_WAIT结束过早, 导致之前迷失的第三次握手突然到达, 新连接突然成功
FIN_WAIT_1 : FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
在Linux网络管理和监控领域，conntrack命令是一个强大的工具，它提供了对netfilter连接跟踪系统的直接访问🔍。这篇文章将深入探讨conntrack的由来、底层原理、参数意义，以及其常见用法，并对返回结果的每个字段进行详细解释。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
