前些天，有朋友问我关于 FIN_WAIT2 的问题：如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包，那么会怎样？...echo -n $(date +"%T") "" echo $content done done 监控发现，在本例中 FIN_WAIT2 存在的时间大约是一分钟左右： FIN_WAIT2...或许有人会问：如果 FIN_WAIT2 没有成为孤儿，那么会如何： #!...和上例中的 FIN_WAIT2 不同，其并不会成为孤儿。...至于 tcp_fin_timeout，我并不建议大家把它设置得太小，因为如上所说，正常情况下，TCP 连接并不会在 FIN_WAIT2 状态上停留太久，假设真的出现 FIN 包丢失之类的情况，那么给 FIN_WAIT2
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...服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2
当主动方收到这个 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT...FIN_WAIT2 状态的优化 当主动方收到 ACK 报文后，会处于 FIN_WAIT2 状态，就表示主动方的发送通道已经关闭，接下来将等待对方发送 FIN 报文，关闭对方的发送通道。...因此，TIME_WAIT 和 FIN_WAIT2 状态的最大时长都是 2 MSL，由于在 Linux 系统中，MSL 的值固定为 30 秒，所以它们都是 60 秒。...很多情况下，我们是没法保证时间戳单调递增的，比如使用了 NAT、LVS 等情况； 所以，不建议设置为 1 ，在 Linux 4.12 版本后，Linux 内核直接取消了这一参数，建议关闭它： 另外，...这是一种新情况，所以连接会进入一种叫做 CLOSING 的新状态，它替代了 FIN_WAIT2 状态。
这里总结下该如何查看和维护Linux机器。...首先查看机器的连接数统计： netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 61 CLOSE_WAIT 5 FIN_WAIT2...服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2
1 抓包与网络问题速查 1.1 抓包 Linux 普通抓包: 1. 打开一个到 ECS 的 ssh 连接，并以 root 身份登录。...1.2 FIN_WAIT2状态的TCP链接过多 在HTTP服务中，Server由于某种原因会主动关闭连接，例如KEEPALIVE超时的情况下。...作为主动关闭连接的Server就会进入FIN_WAIT2状态。...在TCP/IP协议栈中，存在半连接的概念，FIN_WAIT2状态不算超时，如果Client不关闭，FIN_WAIT2状态将保持到系统重启，越来越多的FIN_WAIT2状态会致使内核Crash。...建议调小net.ipv4.tcp_fin_timeout参数的值，以便加快系统关闭处于FIN_WAIT2状态的TCP连接。
此外还有一点需要说明：按照前面图例所示，当被动关闭的一方处于 CLOSE_WAIT 状态时，主动关闭的一方处于 FIN_WAIT2 状态。...那么为什么我们总听说 CLOSE_WAIT 状态过多的故障，但是却相对少听说 FIN_WAIT2 状态过多的故障呢？...这是因为 Linux 有一个「tcp_fin_timeout」设置，控制了 FIN_WAIT2 的最大生命周期。
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状态 客户端收到服务器的ACK报文后，客户端变为 FIN_WAIT2...FIN_WAIT1状态 调整发送FIN报文的重试次数，0相当于8 net.ipv4.tcp_orphan_retries = 0 FIN_WAIT2状态 调整保持在 FIN_WAIT2状态的时间 net.ipv4
Linux下查看Nginx的并发连接数和连接状态 : 查看Web服务器（Nginx Apache）的并发请求数及其TCP连接状态： netstat -n | awk '/^tcp/ {++S[$NF]}...state[key]}' 返回结果一般如下： LAST_ACK 5 （正在等待处理的请求数） SYN_RECV 30 ESTABLISHED 1597 （正常数据传输状态） FIN_WAIT1 51 FIN_WAIT2...：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2...因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了
简单地说，当处于CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接,并发送 FIN 告知对方关闭连接 FIN_WAIT2: 主动关闭端接到 ack ，就会进入FIN_WAIT2，这是一种半连接状态...这种状态下，如果对方不完成关闭过程(四次挥手), 会一直保持到系统重启, 过多的FIN_WAIT2会导致系统内核 crash LAST-ACK: 当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候...每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout
顺着这个思路，先netstat看了下nc的连接情况，发现与zk的连接处于FIN_WAIT2状态。...熟悉TCP四次挥手的应该都知道，FIN_WAIT2是主动关闭的一方没有收到对端的FIN，从而处于FIN_WAIT2状态（状态变化如下图所示） 对于对端没有对socket关闭的情况，可以快速编写服务端demo...搞清楚了FIN_WAIT2，那么nc卡主和这个又有什么关系呢？带着疑问下载了nmap的源码，查看了下nc执行的相关流程。...结合上面说的FIN_WAIT2，就可以知道nc命令为什么不退出了。...加上参数，再来进行测试，发现连接虽然处于FIN_WAIT2状态，但等待指定时长后，nc命令返回退出了。
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF..."\t" State[key]}'LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED 1070 FIN_WAIT1 17 FIN_WAIT2...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...print key "\t" State[key]}' LAST_ACK 140 LISTEN 9 SYN_RECV 7 CLOSE_WAIT 2 ESTABLISHED 972 FIN_WAIT1 21 FIN_WAIT2
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF...print key "\t" State[key]}' LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED 1070 FIN_WAIT1 17 FIN_WAIT2...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...print key "\t" State[key]}' LAST_ACK 140 LISTEN 9 SYN_RECV 7 CLOSE_WAIT 2 ESTABLISHED 972 FIN_WAIT1 21 FIN_WAIT2
thenecho -e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1|FIN_WAIT2...result=$(netstat -an | awk '/^tcp/ {print $0}'|grep -wc "FIN_WAIT1")echo $result;;#连接已关闭，套接字正在等待从远程端关闭FIN_WAIT2...)result=$(netstat -an | awk '/^tcp/ {print $0}'|grep -wc "FIN_WAIT2")echo $result;;#远端关闭，当前socket被动关闭后发送...;;*)echo -e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1|FIN_WAIT2
日常运维中用netstat -an命令发现服务器中有大量状态为TIME-WAIT的TCP连接，于是用/sbin/sysctl -a查看了一下Linux的各项内核参数，并翻阅有关资料，决定修改其中的两项参数...| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 返回结果如下： ESTABLISHED 1423 FIN_WAIT1 1 FIN_WAIT2
> close_wait -> last_ack -> closed 对于client来说状态有：closed -> syn_send -> enstablished -> fin_wait1 -> fin_wait2...然后client会收到ack，进入fin_wait2状态 2）server接着调用close，给client发送了fin，server则进入了了last_ack状态。...上面分析的client主动，则client会出现fin_wait1、fin_wait2、time_wait状态。server会出现close_wait、last_ack状态。...server先进入fin_wait1状态，然后是fin_wait2状态。后面整个就反过来了。...那么client就会一直处于fin_wait2状态，越来越多的fin_wait2状态会导致系统崩溃。所以我们需要在编程中要注意在什么情况下要关闭双方的socket。
当主动方收到这个 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT...FIN_WAIT2 状态的优化 当主动方收到 ACK 报文后，会处于 FIN_WAIT2 状态，就表示主动方的发送通道已经关闭，接下来将等待对方发送 FIN 报文，关闭对方的发送通道。...这与孤儿连接 FIN_WAIT2 状态默认保留 60 秒的原理是一样的，因为这两个状态都需要保持 2MSL 时长。...因此，TIME_WAIT 和 FIN_WAIT2 状态的最大时长都是 2 MSL，由于在 Linux 系统中，MSL 的值固定为 30 秒，所以它们都是 60 秒。...这是一种新情况，所以连接会进入一种叫做 CLOSING 的新状态，它替代了 FIN_WAIT2 状态。
从linux源码看socket的close 笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。...接着，主动关闭的这一端等待对端的ACK，如果ACK回来了，就设置TCP状态为FIN_WAIT2,如上图Step2所示,具体代码如下: tcp_v4_do_rcv |-tcp_rcv_state_process...有这样一步的原因是防止对端由于种种原因始终没有发送fin,防止一直处于FIN_WAIT2状态。 接着在FIN_WAIT2状态等待对端的FIN，完成后面两次挥手: ?...总结 linux内核源代码博大精深，阅读其代码很费周折。之前读>的时候由于有先辈引导和梳理，所以看书中所使用的BSD源码并不觉得十分费劲。...直到现在自己带着问题独立看linux源码的时候，尽管有之前的基础，仍旧被其中的各种细节所迷惑。希望笔者这篇文章能帮助到阅读linux网络协议栈代码的人。
在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries内核参数控制，这个参数是可以自定义的，默认值一般是 5。...在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定，默认值是 5。...正常情况下，如果能及时收到服务端（被动关闭方）的 ACK，则会很快变为 FIN_WAIT2 状态。...这里提一下，当客户端收到第二次挥手，也就是收到服务端发送的 ACK 报文后，客户端就会处于 FIN_WAIT2 状态，在这个状态需要等服务端发送第三次挥手，也就是服务端的 FIN 报文。...在 Linux 系统，TIME_WAIT 状态会持续 60 秒后才会进入关闭状态。 然后，服务端（被动关闭方）没有收到 ACK 报文前，还是处于 LAST_ACK 状态。
在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries内核参数控制，这个参数是可以自定义的，默认值一般是 5。...在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定，默认值是 5。...正常情况下，如果能及时收到服务端（被动关闭方）的 ACK，则会很快变为 FIN_WAIT2状态。...此时，如果主动关闭方一直没收到第三次挥手，那么主动关闭方的连接将会一直处于 FIN_WAIT2 状态（tcp_fin_timeout 无法控制 shutdown 关闭的连接）。...在 Linux 系统，TIME_WAIT 状态会持续 2MSL 后才会进入关闭状态。 然后，服务端（被动关闭方）没有收到 ACK 报文前，还是处于 LAST_ACK 状态。
FIN_WAIT2：Client端收到Server端ACK后，进入FIN_WAIT2状态，等待Server端FIN包。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
