通过实践带你揭开TCP中CLOSE_WAIT和TIME_WAIT的神秘面纱

Posted 2022-11-23 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看一下:

[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（也不是端口）！

相关视频推荐

linux多线程之epoll原理剖析与reactor原理及应用

支撑亿级io的底层基石 epoll实战揭秘

10道经典面试题的剖析， 技术方向如何决定职业方向

学习地址：c/c++ linux服务器开发/后台架构师

【文章福利】需要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了）：

[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次挥手之类的面试题了？