close wait 过多原因_实践解读CLOSE_WAIT和TIME_WAIT

最新推荐文章于 2023-11-13 09:59:22 发布
最新推荐文章于 2023-11-13 09:59:22 发布
阅读量626 收藏 2
点赞数
文章标签： close wait 过多原因
18b4caf55376f612f3e772e770f799a0.gif点击上方蓝字「编程往事」 关注我吧

CLOSE_WAIT和TIME_WAIT是如何产生的？大量的CLOSE_WAIT和TIME_WAIT又有何隐患？本文将通过实践角度来带你揭开CLOSE_WAIT和TIME_WAIT的神秘面纱！遇事不决先祭此图：

85f8fa631568385f740b3b97b545dba2.png

稍微补充一点：TIME_WAIT到CLOSED，这一步是超时自动迁移。

两条竖线分别是表示：

  • 主动关闭(active close)的一方
  • 被动关闭(passive close)的一方

网络上类似的图有很多，但是有的细节不够，有的存在误导。有的会把两条线分别标记成Client和Server。给读者造成困惑。对于断开连接这件事，客户端和服务端都能作为主动方发起，也就是「主动关闭」可以是客户端，可以是服务端。而对端相应的就是「被动关闭」。不管谁发起，状态迁移如上图。

1. 耗尽的是谁的端口？

首先解答初学者对socket的认识存在一个常见的误区。作为服务端，不管哪个WAIT都不会耗尽客户端的端口！

举个例子，我在某云的云主机上有个Server程序：echo_server。我启动它，监听2605端口。然后我在自己的MacBook上用telnet去连接它。连上之后，在云主机上用 netstat -anp看一下:

[guodong@yun test]netstat -anp|grep 2605
tcp    0    0 0.0.0.0:2605    0.0.0.0:*            LISTEN      3354/./echo_server
tcp    0    172.12.0.2:2605   xx.xx.xx.xx:31559    ESTABLISHED 3354/./echo_server

xx.xx.xx.xx是我Macbook的本机IP

其中有两条记录，LISTEN的表示是我的echo_server监听一个端口。ESTABLISHED表示已经有一个客户端连接了。第三列的IP端口是我echo_server的(这个显示IP是局域网的；第四列显示的是客户端的IP和端口，也就是我MacBook。

要说明的是这个端口：31559是客户端的。这个是建立连接时的MacBook分配的随机端口。

我们看一下echo_server占用的fd。使用 ls /proc/3354/fd -l 命令查看，其中 3354是echo_server的pid:

0 -> /dev/pts/6
1 -> /dev/pts/6
2 -> /dev/pts/6
3 -> anon_inode:[eventpoll]
4 -> socket:[674802865]
5 -> socket:[674804942]

0，1，2是三巨头(标准输入，输出，错误)自不必言。3是因为我使用了epoll，所以有一个epfd。

4其实就是我服务端监听端口打开的被动套接字；

5就是客户端建立连接到时候，分配给客户端的连接套接字。server程序只要给5这个fd写数据，就相当于返回数据给客户端。

服务端怎么会耗尽客户端的端口号的。这里消耗的其实是服务端的fd(也不是端口)！

2. 什么时候出现CLOSE_WAIT?

2.1 举个例子

回到我的MacBook终端，查看一下2605有关的连接(Mac上netstat不太好用，只能用lsof了)：

[guodong@MacBook test]lsof -iTCP:2605
COMMAND    PID    USER    FD    TYPE DEVICE             SIZE/OFF    NODE NAME
telnet     74131  guodong 3u    IPv4 0x199db390a76b3eb3 0t0         TCP  192.168.199.155:50307->yy.yy.yy.yy:nsc-posa(ESTABLISHED)

yy.yy.yy.yy表示的远程云主机的IP

nsc-posa其实就是端口2605，因为2605也是某个经典协议(NSC POSA)的默认端口，所以这种网络工具直接显示成了那个协议的名称。

客户端pid为74135。当然，我其实知道我是用telnet连接的，只是为了查pid的话，ps aux|grep telnet也可以。

注意：为了测试。我这里的echo_server是写的有问题的。就是没有处理客户端异常断开的事件。

下面我kill掉telnet(kill -9 74131)。再回到云主机查看一下：

[guodong@yun test]netstat -anp|grep 2605
tcp    0    0 0.0.0.0:2605    0.0.0.0:*            LISTEN      3354/./echo_server
tcp    1    172.12.0.2:2605   xx.xx.xx.xx:31559    CLOSE_WAIT  3354/./echo_server

由于echo_server内没对连接异常进行侦测和处理。所以可以看到原先ESTABLISHED的连接变成了CLOSE_WAIT。并且会持续下去。我们再看一下它打开的fd：

0 -> /dev/pts/6
1 -> /dev/pts/6
2 -> /dev/pts/6
3 -> anon_inode:[eventpoll]
4 -> socket:[674865719]
5 -> socket:[674865835]

5这个fd还存在，并且会一直存在。所以当有大量CLOSE_WAIT的时候会占用服务器的fd。而一个机器能打开的fd数量是有限的。超过了，因为无法分配fd，就无法建立新连接啦！

2.2 怎么避免客户端异常断开时的服务端CLOSE_WAIT？

有一个方法。比如我用了epoll，那么我监听客户端连接套接字(5)的EPOLLRDHUP这个事件。当客户端意外断开时，这个事件就会被触发，触发之后。我们针对性的对这个fd(5)执行close()操作就可以了。改下代码，重新模拟一下上述流程，blabla细节略过。现在我们新echo_server启动。MacBook的telnet连接成功。然后我kill掉了telnet。观察一下云主机上的状况：

[guodong@yun test]netstat -anp|grep 2605
tcp    0    0 0.0.0.0:2605    0.0.0.0:*            LISTEN      7678/./echo_server
tcp    1    172.12.0.2:2605   xx.xx.xx.xx:31559    LAST_ACK    -

出现了LAST_ACK。我们看下fd。命令：ls /proc/7678/fd -l

0 -> /dev/pts/6
1 -> /dev/pts/6
2 -> /dev/pts/6
3 -> anon_inode:[eventpoll]
4 -> socket:[674905737]

fd(5)其实已经关闭了。过一会我们重新netstat看下：

[guodong@yun test]netstat -anp|grep 2605
tcp    0    0 0.0.0.0:2605    0.0.0.0:*            LISTEN      7678/./echo_server

LAST_ACK也消失了。为什么出现LAST_ACK。翻到开头，看我那张图啊！

CLOSE_WAIT不会自动消失，而LAST_TACK会超时自动消失，时间很短，即使在其存续期内，fd其实也是关闭状态。实际我这个简单的程序，测试的时候不会每次都捕捉到LAST_WAIT。有时候用netstat 命令查看的时候，就是最终那副图了。

3. 什么时候出现TIME_WAIT?

看我开篇那个图就知道了。

现在我kill掉我的echo_server!

[guodong@yun test]netstat -anp|grep 2605
tcp    0    0 172.17.0.2:2605    xx.xx.xx.xx:51327    TIME_WAIT    -

云主机上原先ESTABLISHED的那条瞬间变成TIME_WAIT了。

这个TIME_WAIT也是超时自动消失的。时间是2MSL。MSL是多长？

cat /proc/sys/net/ipv4/tcp_fin_timeout

一般是60。2MSL也就2分钟。在2分钟之内，对服务端有啥副作用吗？有，但问题不大。那就是这期间重新启动Server会报端口占用。这个等待，一方面是担心对方收不到自己的确认，等对方重发FIN。另一方面2MSL是报文的最长生命周期，可以避免Server重启(或其他Server绑同样端口)接收到了上一次的数据。

当然这个2MLS的等待，也可以通过给socket添加选项(SO_REUSEADDR)的方式来避免。Server可以立即重启(这样Server的监控进程就可以放心的重新拉起Server啦)。

通常情况下TIME_WAIT对服务端影响有限，而大量CLOSE_WAIT风险较高，但正确编写代码基本可以避免。为什么只说通常情况呢？因为生产环境是复杂的，一个服务通常会和多个下游服务用各种各样的协议进行通信。TIME_WAIT和CLOSE_WAIT在一些异常条件下，还是会触发的。

并不是说TIME_WAIT就真的无风险，其实无论是TIME_WAIT还是CLOSE_WAIT，永远记住当你的服务出现这两种现象的时候，它们只是某个问题导致的结果，而不是问题本身。有些网络教程教你怎么调大这个或那个的OS系统设置，个人感觉只是治标不治本。找到本质原因，避免TIME_WAIT和CLOSE_WAIT的产生，才是问题解决之道！

把这些了解清楚时候，是不是可以轻松应对什么4次挥手之类的面试题了？

173096707cbf5da4388bb6807f9ae93d.png

扫码关注

更多精彩

d245607591a5b357325bd1f57594a66e.png
weixin_39684960
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TCP的状态兼谈Close_Wait和Time_Wait的状态
05-07
详细描述TCP的各个状态，初学者可以快速理解掌握tcp状态图
Linux中进程和连接状态查看
爱琴孩的博客
09-04 4158
前言 在linux日常使用，我们经常会需要查看具体某个进程是否存在，服务是否启动成功，抑或是需要根据端口号来查询这个端口号是否被占用。有时候我们还要查看目前系统中某个进程的连接数，还有各个TCP连接分别处于什么状态。这里来和大家一起总结下这些实用命令。 查看端口号是否被占用 比如在Linux系统中，我需要查看系统8096端口是否被占用，我们该怎么查看呢。我们可以输入下面的命令 lsof ...
linux tcp关闭时间戳,【Shell】30分钟关闭Tcpdump，开启Tcpdump、检测目录大小终止任务...
weixin_39620001的博客
05-04 964
场景按照一定时间规律运行Tcpdump思路编程思路细化思考查看文件个数file_count_results=`ls -al "C:\\Users\\Windows32\\Desktop\\test" | grep ^- | wc -l`显示文件大小$ du -h --max-depth=02.1G .$ du -bs2177623726 .这样的话，在SHELL里把文件夹大小做为命令输出赋值...
TCP的time_wait、close_wait状态
dz45693的专栏
01-13 2599
TCP终止连接一般是需要交换四个分节。具体来看：  1、 应用进程（active close）首先调用close，于是导致TCP发送一个FIN分节，表示数据已分送完毕，请求关闭套接字。  2、 另一端应用进程（passive close）接受收到FIN，并由该端的TCP确认（确认的过程是TCP发送ACK分节给对端套接字）。FIN的接受也作为文件结束符传递给上层应用进程。这里的文件结束符并非应用
说说TIME_WAIT和CLOSE_WAIT区别
学一次的博客
09-02 1476
根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。假设最终的ACK丢失，server将重发FIN，client必须维护TCP状态信息以便可以重发最终的ACK，否则会发送RST，结果server认为发生错误。
【计算机网络】通信中Time_wait和Close_wait
lixiaohulife的博客
01-18 2881
1.Socket的关闭的过程（四次挥手） 主动关闭连接的一方，调用close()；协议层发送FIN包 被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方 等待 被动关闭一方的应用程序，调用close操作。 被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态； 主动关闭
tcp连接出现close_wait状态？_tcp_close_
09-30
tcp连接出现close_wait状态？
CLOSE_WAIT网络连接无法释放问题解决
07-31
关于系统端口出现CLOSE_WAIT状态的解决方案，讲解明确清晰，值得参考
系统调优，你所不知道的TIME_WAIT和CLOSE_WAIT1
08-03
1. 主动关闭连接的 - 也就是主动调socket的close操作的，最终 2. 被动关闭连接的，有个中间状态，即CLOSE_WAIT，因为协议 4. 在个连接
TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题解决
02-18
对于服务器挂起中的CLOSE_WAIT & FIN_WAIT2 解决方案。
CLOSE_WAIT错误详解
07-19
CLOSE_WAIT 错误详解
close_wait
03-04
close_wait
close_wait_0306 close_wait_0306 close_wait_0306 close_wait_0306
03-06
close_wait_0306 close_wait_0306 close_wait_0306 close_wait_0306 close_wait_0306 close_wait_0306
Close_Wait问题相关资料
03-20
解决Close_Wait问题的相关资料。
epoll机制epoll_create、epoll_ctl、epoll_wait、close(在epoll的ET模式下，read和write或send和recv当返回值0且errno=EAGAIN - linking530的专栏 - CSDN博客.mht
01-03
epoll机制epoll_create、epoll_ctl、epoll_wait、close(在epoll的ET模式下，read和write或send和recv当返回值0且errno=EAGAIN - linking530的专栏 - CSDN博客.mht
服务器大量tcp close_wait
u014203449的博客
10-11 1368
线上碰到服务器 大量tcp连接处于close_wait状态，tomcat处于假死状态，即tomca在运行，但不能访问。因为tcp连接耗尽了。 查询tcp连接数和状态：netstat -an|awk '/^tcp/{++S[$NF]}END{for (a in S)print a,S[a]}' 查询端口监听的tcp连接 netstat -anp |grep 8080 按tcp协议来说，客户端发送关闭连接消息，服务端会进入close_wait状态，服务端处理完后会自动进入last_ack状态，...
TCP连接出现大量CLOSE_WAIT不回收的问题排查
最新发布
IT匠人的专栏
11-13 248
日常运维过程中，收到“应用A”突然挂起没有处理请求的告警，然后触发“存活检查”不通过，自动重启了。
CLOSE_WAIT状态的原因与解决方法
phla_han的专栏
05-07 728
CLOSE_WAIT状态的原因与解决方法
服务端处于time_wait ,无法启动
zhaoyangjian724的专栏
05-10 295
node1:/root/test#cat test.py # coding = utf-8 # -*- coding:utf-8 -*- import socket ip_port = ('192.168.137.2',8080) BUFSIZE = 10 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)#创建套接字 s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 0) s.bind(ip_port
time_wait和close_wait
03-16
time_wait和close_wait是TCP连接状态中的两种。 time_wait状态表示一个连接已经完成了关闭过程，并且在等待最后的确认报文。 close_wait状态表示对端已经发送了关闭连接的请求，等待本端应用程序关闭连接。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值