前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。...回到开头的问题：FIN_WAIT1 能持续多久？...一般情况下，服务器间的 ACK 确认是非常快的，以至于我们凭肉眼往往观察不到 FIN_WAIT1 的存在，不过网上也有很多案例表明在某些情况下 FIN_WAIT1 会持续很长时间，从而诱发问题。...花絮：我曾经试图寻找一些工具来杀掉 FIN_WAIT1 连接，如果你要杀掉一个 TCP 连接，那么需要知道相应的 ACK 和 SEQ，然后才可以 RESET 连接。...留意：Nginx 的 reset_timedout_connection 选项和 FIN_WAIT1 有点关系。 最后，如果你在本文发现谬误之处，那么全因本人笨拙，还望不吝赐教。
还记得，那年那天，在我负责的一个模块的某台机器上出现了大量FIN_WAIT1的TCP连接（连上的是nginx监听的某端口） 问题现象： 1....查询每一条处于FIN_WAIT1的连接客户端，发现客户端TCP状态仍然是ESTABLISHED 2. 这种连接会一直存在（对某一条进行监视，发现一个多小时后状态仍然不变） 3....一直不处理报文，导致TCP Server端发送缓冲区塞满了数据，客户端自己的接收缓冲区里也填满了数据 Server因为收发包失败后在应用层调用了close，于是Server端TCP状态机进入FIN_WAIT1
netstat可以在linux下分组查看连接信息 Bash netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' Bash...返回结果示例： LAST_ACK 5 (正在等待处理的请求数) SYN_RECV 30 ESTABLISHED 1597 (正常数据传输状态) FIN_WAIT1 51 FIN_WAIT2...无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1
当主动方收到这个 ACK 后，连接状态由 FIN_WAIT1 变为 FIN_WAIT2，也就是表示主动方的发送通道就关闭了。...FIN_WAIT1 状态的优化 主动方发送 FIN 报文后，连接就处于 FIN_WAIT1 状态，正常情况下，如果能及时收到被动方的 ACK，则会很快变为 FIN_WAIT2 状态。...但是当迟迟收不到对方返回的 ACK 时，连接就会一直处于 FIN_WAIT1 状态。...另外，老版本的 Linux 还提供了 tcp_tw_recycle 参数，但是当开启了它，就有两个坑： Linux 会加快客户端和服务端 TIME_WAIT 状态的时间，也就是它会使得 TIME_WAIT...很多情况下，我们是没法保证时间戳单调递增的，比如使用了 NAT、LVS 等情况； 所以，不建议设置为 1 ，在 Linux 4.12 版本后，Linux 内核直接取消了这一参数，建议关闭它： 另外，
四次挥手 [FIN_WAIT1] :FIN_WAIT1和FIN_WAIT2均为等待对方的FIN报文。...两者区别为，当SOCKET在ESTABLISHED状态时，想主动关闭连接从而想对方发送FIN报文，此时进入FIN_WAIT1状态。当收到ACK报文进入FIN_WAIT2状态。...主机A收到FIN报文发送ACK表示收到并进入TIME_WAIT 在Linux系统中有一个字段，名称为TCP_TIME_WAIT_LEN，其数值为60s，也就是需要在TIME_WAIT阶段停留60s ?...巨人的肩膀 《Coping with the TCP TIME-WAIT state on busy Linux servers》 Tuning TCP and nginx on ec2 -p30 TIME_WAIT
Linux下查看Nginx的并发连接数和连接状态 : 查看Web服务器（Nginx Apache）的并发请求数及其TCP连接状态： netstat -n | awk '/^tcp/ {++S[$NF]}...print key,"t",state[key]}' 返回结果一般如下： LAST_ACK 5 （正在等待处理的请求数） SYN_RECV 30 ESTABLISHED 1597 （正常数据传输状态） FIN_WAIT1...无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1...因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF...State)print key "\t" State[key]}'LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED 1070 FIN_WAIT1...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...in State)print key "\t" State[key]}' LAST_ACK 140 LISTEN 9 SYN_RECV 7 CLOSE_WAIT 2 ESTABLISHED 972 FIN_WAIT1
——村上春树 关于 BPF/eBPF ， BCC/bpftrace 是什么这里不多讲，小伙伴可以看我之前的文章 Linux 可观测性 BPF&eBPF 以及 BCC&bpftrace 认知 认识之前，...四次挥手 客户端 服务器 FIN_WAIT1 ------ FIN(seq=u) ----> FIN_WAIT1 12:36:07 3053 4 192.168.26.99:46030 R> 192.168.26.99:3306 FIN_WAIT1 12:36:07 27...FIN_WAIT1 表明本地端已经收到来自远程端的 FIN 分片，但本地应用还未完全关闭连接，因此本地端等待应用层的关闭指示。...文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :) BCC工具包 帮助文档 https://docs.redhat.com/zh_hans/documentation/red_hat_enterprise_linux
# -ne 1 ];thenecho -e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1...CLOSING)result=$(netstat -an | awk '/^tcp/ {print $0}'|grep -wc "CLOSING")echo $result;;#套接字已关闭，连接正在关闭FIN_WAIT1...)result=$(netstat -an | awk '/^tcp/ {print $0}'|grep -wc "FIN_WAIT1")echo $result;;#连接已关闭，套接字正在等待从远程端关闭...echo $result;;*)echo -e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1
——村上春树 关于 BCC 是什么这里不多介绍，小伙伴可以看我之前的文章：Linux 可观测性 BPF&eBPF 以及 BCC&bpftrace 认知 BCC工具检查清单 下面的内容 位于BCC仓库的docs...> 192.168.26.101:57360 ESTABLISHED 12:35:55 0 4 192.168.26.99:48370 R> 192.168.26.99:3306 FIN_WAIT1...:45960 R> 192.168.26.99:3306 FIN_WAIT1 12:36:07 11139 4 192.168.26.99:45950 R> 192.168.26.99:3306...FIN_WAIT1 12:36:07 3053 4 192.168.26.99:46030 R> 192.168.26.99:3306 FIN_WAIT1 12:36:07 27...4 192.168.26.99:46014 R> 192.168.26.99:3306 FIN_WAIT1 ^C┌──[root@vms100.liruilongs.github.io]-[~]
日常运维中用netstat -an命令发现服务器中有大量状态为TIME-WAIT的TCP连接，于是用/sbin/sysctl -a查看了一下Linux的各项内核参数，并翻阅有关资料，决定修改其中的两项参数...netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 返回结果如下： ESTABLISHED 1423 FIN_WAIT1
状态由SYN_SENT变为ESTABLISHED）和Server端（接收Client端的ACk，状态由SYN_RECV变为ESTABLISHED）完成三次握手，状态置为ESTABLISHED，连接建立 FIN_WAIT1...：主动关闭端发出FIN请求主动关闭连接，状态由ESTABLISHED变为FIN_WAIT1 CLOSE_WAIT：被动关闭端接收FIN请求，并回应ACK给主动关闭端，同时将FIN作为文件结束符发送给上层应用程序...，状态由ESTABLISHED变为CLOSE_WAIT FIN_WAIT2：主动关闭端接收到ACK，状态由FIN_WAIT1变为FIN_WAIT2 LAST_ACK：被动关闭端一段时间后，接收到文件结束符的上层应用程序...CLOSE_WAIT变为LAST_ACK TIME_WAIT：在主动关闭端接收到FIN请求，并回应ACK给被动关闭端，状态由FIN_WAIT2变为TIME_WAIT CLOSING：两端同时发起关闭请求时，会由FIN_WAIT1
netstat 查看Linux中网络系统状态信息 补充说明 netstat命令用来打印Linux中网络系统的状态信息，可让你得知整个Linux系统的网络情况。...同时自己向客户端发送一个SYN，之后状态置为，在收到和发送一个连接请求后等待对连接请求的确认； ESTABLISHED：代表一个打开的连接，双方可以进行或已经在数据交互了，代表一个打开的连接，数据可以传送给用户； FIN_WAIT1...：主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态，等待远程TCP的连接中断请求，或先前的连接中断请求的确认； CLOSE_WAIT
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF...in State)print key "\t" State[key]}' LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED 1070 FIN_WAIT1...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...in State)print key "\t" State[key]}' LAST_ACK 140 LISTEN 9 SYN_RECV 7 CLOSE_WAIT 2 ESTABLISHED 972 FIN_WAIT1
这里总结下该如何查看和维护Linux机器。...无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1
linux查看 linux服务器可以利用 netstat-anp|grep tcp命令，查看服务器上各个端口和应用的连接状态。...你还可以通过修改linux的配置文件 /etc/sysctl.conf，调整各个状态的数量 SYN_SENT状态相关 主动建立连接时，发SYN（步骤2）的重试次数 nct.ipv4.tcp_syn_rctries...客户端与服务器端正常传输数据 客户端主动断开连接，向服务器端发送FIN报文，客户端变为 FIN_WAIT1状态 服务器收到客户端的FIN后，向客户端发送ACK报文，服务器变为 CLOSE_WAIT状态...FIN_WAIT1状态 调整发送FIN报文的重试次数，0相当于8 net.ipv4.tcp_orphan_retries = 0 FIN_WAIT2状态 调整保持在 FIN_WAIT2状态的时间 net.ipv4
enstablished -> close_wait -> last_ack -> closed 对于client来说状态有：closed -> syn_send -> enstablished -> fin_wait1...client进入fin_wait1状态。server收到并回复ack，server进入close_wait状态。...上面分析的client主动，则client会出现fin_wait1、fin_wait2、time_wait状态。server会出现close_wait、last_ack状态。...server先进入fin_wait1状态，然后是fin_wait2状态。后面整个就反过来了。...如果等数据发送完毕再将fin和ack一起发过去，n那么A就会长时间处于fin_wait1状态。这样就比较不好了。 实际情况中我们可能会在server忘记关闭客户端的socket。
当主动方收到这个 ACK 后，连接状态由 FIN_WAIT1 变为 FIN_WAIT2，也就是表示主动方的发送通道就关闭了。...FIN_WAIT1 状态的优化 主动方发送 FIN 报文后，连接就处于 FIN_WAIT1 状态，正常情况下，如果能及时收到被动方的 ACK，则会很快变为 FIN_WAIT2 状态。...但是当迟迟收不到对方返回的 ACK 时，连接就会一直处于 FIN_WAIT1 状态。...所以，当攻击者下载大文件时，就可以通过接收窗口设为 0 ，这就会使得 FIN 报文都无法发送出去，那么连接会一直处于 FIN_WAIT1 状态。...在 Linux 中发送缓冲区和接收缓冲都是可以用参数调节的。设置完后，Linux 会根据你设置的缓冲区进行动态调节。
FIN_WAIT1：Client端发送FIN包，然后进入FIN_WAIT1状态，等待Server端ACK。
接收到 syn j将标志位 syn 和 ack 置为1，发送给客户端 ESTABLISHED：client 收到 ack 为1，将这个ack数据包再次发给服务端，服务端确认为1后建立连接 四次挥手状态 FIN_WAIT1...: 主动关闭端调用close()发送 FIN 请求主动关闭连接，之后进入 FIN_WAIT1 状态,等待远程TCP连接中断请求的确认。...每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
对象存储
云直播
