大多数的博客在介绍tcp的三次握手和四次挥手时，只是介绍了握手和挥手的流程，有些博客还会分析四次挥手时主动关闭连接的一端的time_wait状态的作用，但却几乎没有博客会介绍被动关闭连接的一端维持last_ack...状态的作用，以及在四次挥手中如果出现丢包，last_ack将如何处理等。...实际上，last_ack（持续时间一般为一个RTO（retransmission timeout，数据包重传的timeout时间）的时间，这个时间根据RTT动态计算出来）有两个作用：作用一是处理重用连接...参考文档： 1、https://blog.csdn.net/stpeace/article/details/75675581 tcp四次挥手中LAST_ACK状态一般持续多久？
所有的GNU/Linux发布版都自带GAWK，它与AWK和NAWK完全兼容. 它一般和sed一起处理文件日志等等，我们先看一下它的工作流是如何工作的： ?...LAST_ACK tcp4 0 0 192.168.1.100.56706 223.6.248.220.http LAST_ACK tcp4 0...0 192.168.1.100.56705 223.6.248.220.http LAST_ACK tcp4 0 0 192.168.1.100.56704...LAST_ACK tcp4 0 0 192.168.1.100.56706 223.6.248.220.http LAST_ACK tcp4 0....http LAST_ACK tcp4 0 0 192.168.1.100.56706 223.6.248.220.http LAST_ACK tcp4
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...FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK
Linux下查看Nginx的并发连接数和连接状态 : 查看Web服务器（Nginx Apache）的并发请求数及其TCP连接状态： netstat -n | awk '/^tcp/ {++S[$NF]}...netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}' 返回结果一般如下： LAST_ACK...正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK...但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。...因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了
tcp_diag是一个用于分析统计的模块，可以获得Linux内核中第一手的信息，这就确保了ss的快捷高效。...为了验证ss比netstat更快更高效，可以如下做几个实验看看效果： 几乎所有的Linux系统都会默认包含netstat命令，但并非所有系统都会默认包含ss命令。...LAST_ACK 在TCP四次挥手时，被动关闭端发送FIN包后，进入LAST_ACK状态，等待对方的ACK包。...TIME_WAIT 被动连接端可能的状态有： LISTEN SYN_RECV ESTABLISHED 被动关闭端可能的状态有： CLOSE_WAIT LAST_ACK...CLOSED 在Linux下，如果连接数比较大，可以使用效率更高的ss来替代netstat。
小王：Linux（这年头谁还在写window程序） 大王；那你对网络编程一定很熟悉 吧？ 小王：那是当然（都是小菜一碟）。 大王：请绘制TCP状态转换过程？ 小王：。。。。...服务正常，网络正常： B发送FIN，进入LAST_ACK状态，A收到这个FIN包后发送ACK包，B收到这个ACK包，然后进入CLOSED状态 服务正常，网络拥塞，网络连接良好 B发送FIN，进入LAST_ACK...处于TIME_WAIT状态的一端在收到重传的FIN时会重新计时(rfc793 以及 linux kernel源代码tcp_timewait_state_process函数 保证这次连接的重复数据段从网络中消失...保障每次发送出去ack都最终结果（收到或者消失） 如果在网络出断网，或者服务节点重启，或者对方不启tcp重传机制上面方法是无法处理的 应该超时或者返回Rst包出路 结束last_ack状态。
答案来自此链接： 这里假设主动关闭方为A，被动关闭方为B，TIME_WAIT状态是在主动关闭方A接收到主动关闭的FIN报文的ACK报文后，此时被动关闭方B会发出FIN报文，A在收到FIN报文后会发出Last_ack...假如A在发出Last_ack报文后，B未能在超时前收到报文，就需要重新发送FIN报文。...如果A在发出Last_ack报文后直接关闭连接，那么B重发的Fin报文到达A后就可能被错误接收，因此A必须等待，那么这个时间应该为多长，考虑的主要是不对后边新建立的连接产生影响。...那么考虑最坏的情况A在发出Last_ack后，经过MSL的时间才到大B，B就可以正常断开连接了，而B在接收到这个包前一刻重传了Fin包，也经过MSL的时间才到达A，那么A就能在2MSL的时间等到B的最后一个重传
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF...]}END{for(key in State)print key "\t" State[key]}'LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...# netstat -an | awk '/^tcp/ {++State[$NF]}END{for(key in State)print key "\t" State[key]}' LAST_ACK 140
然后，被动方没有收到 ACK 报文前，还是处于 LAST_ACK 状态。如果这个 ACK 报文没有到达被动方，被动方就会重发 FIN 报文。...另外，老版本的 Linux 还提供了 tcp_tw_recycle 参数，但是当开启了它，就有两个坑： Linux 会加快客户端和服务端 TIME_WAIT 状态的时间，也就是它会使得 TIME_WAIT...很多情况下，我们是没法保证时间戳单调递增的，比如使用了 NAT、LVS 等情况； 所以，不建议设置为 1 ，在 Linux 4.12 版本后，Linux 内核直接取消了这一参数，建议关闭它： 另外，...处于 CLOSE_WAIT 状态时，调用了 close 函数，内核就会发出 FIN 报文关闭发送通道，同时连接进入 LAST_ACK 状态，等待主动方返回 ACK 来确认连接关闭。...当被动方发送 FIN 报文后，连接就进入 LAST_ACK 状态，在未等到 ACK 时，会在 tcp_orphan_retries 参数的控制下重发 FIN 报文。
在本文中，我们将深入探讨 TCP 三次握手的过程，Linux 内核的实现逻辑，以及 TCP 队列中的全连接（FULL）与半连接（SYN）队列的概念和作用。...在Linux内核的TCP实现逻辑 在开始之前，我们先了解两个队列 半连接队列（SYN queue） 当客户端发送SYN报文，服务器接收后进入SYN_RECV状态，此时连接被放入半连接队列。...LAST_ACK状态： 问题：当服务器端关闭连接后，等待客户端的最终ACK确认，如果客户端没有及时发送ACK，服务器端会长时间处于LAST_ACK状态。...排查命令：使用netstat -an | grep LAST_ACK查看LAST_ACK状态的连接，检查是否有异常的连接。...Linux 内核相关参数优化 可以查看另外一篇博文：每日一问题探索-高并发下的linux优化 通过对TCP三次握手过程中的队列管理以及可能出现的问题的深入分析，我们可以更好地理解网络连接的建立与维护
LINUX中默认一个MSL是30s，也就是说TIME_WAIT的时间是60s。...上图如果服务端没有收到最后一个ACK报文会处于LAST_ACK状态，如果此时客户端发起了一个新的SYN报文请求建立连接，服务端会发送RST报文给客户端，连接建立失败。...中的默认值，也就是说Linux操作系统中至少经过2小时11分15秒才可以发现一个死亡连接。...以前代表SYN队列大小，但是在Linux 2.2以后就是全连接队列的大小(accept队列的大小)。...服务端处理完所有的数据以后，会读取到EOF，此时会调用close方法关闭Socket，然后发送一个FIN包进入LAST_ACK状态。 后面的其实就是TCP最终断开连接。
那么可以这么理解，当client进入time_wait的等待时间是2个MSL 让我们看一下一台linux服务器的网络状态： # netstat -an | awk '/^tcp/ {++State[$NF...]}END{for(key in State)print key "\t" State[key]}' LAST_ACK 7 LISTEN 9 SYN_RECV 2 CLOSE_WAIT 125 ESTABLISHED...time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，所以我们可以通过linux...# netstat -an | awk '/^tcp/ {++State[$NF]}END{for(key in State)print key "\t" State[key]}' LAST_ACK 140
e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1|FIN_WAIT2|LAST_ACK...an | awk '/^tcp/ {print $0}'|grep -wc "FIN_WAIT2")echo $result;;#远端关闭，当前socket被动关闭后发送FIN报文，等待对方ACK报文LAST_ACK...)result=$(netstat -an | awk '/^tcp/ {print $0}'|grep -wc "LAST_ACK")echo $result;;#接收到SYN报文SYN_RECV)result...e "\033[32mUsage: sh $0 {ESTABLISHED|LISTEN|TIME_WAIT|CLOSED|CLOSE_WAIT|CLOSING|FIN_WAIT1|FIN_WAIT2|LAST_ACK
在 Linux 上可用netstat查看服务器的 TCP 状态(连接状态数量统计)： netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print...close_wait产生太多原因：被动关闭方没有迁移到Last_ACK状态，也就是被动关闭方没有发送FIN包。...方法，被动关闭方没有执行close方法,说明服务端socket忙于读写,没有主动关闭 socket ,发 FIN 给 Client，此时服务端 Socket 会处于 CLOSE_WAIT 状态,而不是 LAST_ACK...发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。
这里总结下该如何查看和维护Linux机器。...FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK
从linux源码看socket的close 笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。...last_ack 应用层在发现对端关闭之后已经是close_wait状态，这时候再调用close的话，会将状态改为last_ack状态，并发送本端的fin,如下代码所示: void tcp_close(...else if (tcp_close_state(sk)){ // tcp_close_state会将sk从close_wait状态变为last_ack // 发送fin包 tcp_send_fin...总结 linux内核源代码博大精深，阅读其代码很费周折。之前读>的时候由于有先辈引导和梳理，所以看书中所使用的BSD源码并不觉得十分费劲。...直到现在自己带着问题独立看linux源码的时候，尽管有之前的基础，仍旧被其中的各种细节所迷惑。希望笔者这篇文章能帮助到阅读linux网络协议栈代码的人。
首先我们需要了解如下要点： TCP 连接中的一端发送了 FIN 报文之后如果收不到对端针对该 FIN 的 ACK，则会反复多次重传 FIN 报文，大约持续几分钟； 被动关闭处于 LAST_ACK 状态的一端在收到最后一个...不处理这些报文可能导致前后两个使用相同四元组的连接中的后一个连接出现异常（详见《UNIX网络编程》卷 1 的 2.7 节 第三版）； 处于 TIME_WAIT 状态的一端在收到重传的 FIN 时会重新计时（rfc793以及 Linux...这个连接的两端分别是 A 和 B，其中 A 是主动关闭连接的一端，因为刚刚向对端发送了针对对端发送过来的 FIN 报文的 ACK，此时正处于 TIME_WAIT 状态；而 B 是被动关闭的一端，此时正处于 LAST_ACK...同时处于 LAST_ACK 状态的 B 因为收到了 ACK，所以它直接就进入了 CLOSED 状态，而不会向网络发送任何报文。
LAST_ACK：同时Server端向上层应用告知客户端关闭消息，发送FIN包回Client端，然后进入LAST_ACK阶段，等待客户端ACK。
给主动关闭端，同时将FIN作为文件结束符发送给上层应用程序，状态由ESTABLISHED变为CLOSE_WAIT FIN_WAIT2：主动关闭端接收到ACK，状态由FIN_WAIT1变为FIN_WAIT2 LAST_ACK...：被动关闭端一段时间后，接收到文件结束符的上层应用程序，调用CLOSE关闭连接，此时被动关闭端会发送FIN请求给主动关闭端，状态由CLOSE_WAIT变为LAST_ACK TIME_WAIT：在主动关闭端接收到...给被动关闭端，状态由FIN_WAIT2变为TIME_WAIT CLOSING：两端同时发起关闭请求时，会由FIN_WAIT1变为CLOSING CLOSED：1）被动关闭端收到主动关闭端的ACK，状态由LAST_ACK
首先我们需要了解如下要点： TCP连接中的一端发送了FIN报文之后如果收不到对端针对该FIN的ACK，则会反复多次重传FIN报文，大约持续几分钟； 被动关闭处于LAST_ACK状态的一端在收到最后一个ACK...不处理这些报文可能导致前后两个使用相同四元组的连接中的后一个连接出现异常(详见UNIX网络编程卷1的2.7节 第三版)； 处于TIME_WAIT状态的一端在收到重传的FIN时会重新计时(rfc793 以及 linux...我们设想有一个处于拆链过程中的TCP连接，这个连接的两端分别是A和B，其中A是主动关闭连接的一端，因为刚刚向对端发送了针对对端发送过来的FIN报文的ACK，此时正处于TIME_WAIT状态；而B是被动关闭的一端，此时正处于LAST_ACK...同时处于LAST_ACK状态的B因为收到了ACK，所以它直接就进入了CLOSED状态，而不会向网络发送任何报文。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
