通过实践带你揭开 TCP 中 CLOSE_WAIT 和 TIME_WAIT 的神秘面纱
linux 服务器开发相关视频解析:
linux多线程之epoll原理剖析与reactor原理及应用
c/c++ linux 服务器开发免费学习地址:c/c++ linux后台服务器高级架构师
CLOSE_WAIT 和 TIME_WAIT 是如何产生的?大量的 CLOSE_WAIT 和 TIME_WAIT 又有何隐患?本文将通过实践角度来带你揭开 CLOSE_WAIT 和 TIME_WAIT 的神秘面纱!遇事不决先祭此图:
稍微补充一点:TIME_WAIT 到 CLOSED,这一步是超时自动迁移。
两条竖线分别是表示:
主动关闭(active close)的一方
被动关闭(passive close)的一方
网络上类似的图有很多,但是有的细节不够,有的存在误导。有的会把两条线分别标记成 Client 和 Server。给读者造成困惑。对于断开连接这件事,客户端和服务端都能作为主动方发起,也就是「主动关闭」可以是客户端,可以是服务端。而对端相应的就是「被动关闭」。不管谁发起,状态迁移如上图。
1. 耗尽的是谁的端口?
首先解答初学者对 socket 的认识存在一个常见的误区。作为服务端,不管哪个 WAIT 都不会耗尽客户端的端口!
举个例子,我在某云的云主机上有个 Server 程序:echo_server。我启动它,监听 2605 端口。然后我在自己的 MacBook 上用 telnet 去连接它。连上之后,在云主机上用 netstat -anp 看一下:
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,1,2 是三巨头(标准输入,输出,错误)自不必言。3 是因为我使用了 epoll,所以有一个 epfd。
4 其实就是我服务端监听端口打开的被动套接字;
5 就是客户端建立连接到时候,分配给客户端的连接套接字。server 程序只要给 5 这个 fd 写数据,就相当于返回数据给客户端。
服务端怎么会耗尽客户端的端口号的。这里消耗的其实是服务端的 fd(也不是端口)!
【文章福利】需要 C/C++ Linux 服务器架构师学习资料加群 812855908(资料包括 C/C++,Linux,golang 技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg 等)
2. 什么时候出现 CLOSE_WAIT?
2.1 举个例子
回到我的 MacBook 终端,查看一下 2605 有关的连接(Mac 上 netstat 不太好用,只能用 lsof 了):
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)。再回到云主机查看一下:
由于 echo_server 内没对连接异常进行侦测和处理。所以可以看到原先 ESTABLISHED 的连接变成了 CLOSE_WAIT。并且会持续下去。我们再看一下它打开的 fd:
5 这个 fd 还存在,并且会一直存在。所以当有大量 CLOSE_WAIT 的时候会占用服务器的 fd。而一个机器能打开的 fd 数量是有限的。超过了,因为无法分配 fd,就无法建立新连接啦!
2.2 怎么避免客户端异常断开时的服务端 CLOSE_WAIT?
有一个方法。比如我用了 epoll,那么我监听客户端连接套接字(5)的 EPOLLRDHUP 这个事件。当客户端意外断开时,这个事件就会被触发,触发之后。我们针对性的对这个 fd(5)执行 close()操作就可以了。改下代码,重新模拟一下上述流程,blabla 细节略过。现在我们新 echo_server 启动。MacBook 的 telnet 连接成功。然后我 kill 掉了 telnet。观察一下云主机上的状况:
出现了 LAST_ACK。我们看下 fd。命令:ls /proc/7678/fd -l
fd(5)其实已经关闭了。过一会我们重新 netstat 看下:
LAST_ACK 也消失了。为什么出现 LAST_ACK。翻到开头,看我那张图啊!
CLOSE_WAIT 不会自动消失,而 LAST_TACK 会超时自动消失,时间很短,即使在其存续期内,fd 其实也是关闭状态。实际我这个简单的程序,测试的时候不会每次都捕捉到 LAST_WAIT。有时候用 netstat 命令查看的时候,就是最终那副图了。
3. 什么时候出现 TIME_WAIT?
看我开篇那个图就知道了。
现在我 kill 掉我的 echo_server!
云主机上原先 ESTABLISHED 的那条瞬间变成 TIME_WAIT 了。
这个 TIME_WAIT 也是超时自动消失的。时间是 2MSL。MSL 是多长?
一般是 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 次挥手之类的面试题了?
评论