Socket中的TIME_WAIT状态

最新推荐文章于 2025-01-02 03:10:02 发布

原创最新推荐文章于 2025-01-02 03:10:02 发布 · 6.7k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#TIME_WAIT

Linux 专栏收录该内容

7 篇文章

订阅专栏

本文深入解析了TCP/IP协议中TIME_WAIT状态的原理及其对服务器的影响，指出长时间维持该状态可能导致的资源消耗问题，并提出通过调整内核参数来优化TIME_WAIT状态的回收机制，从而减轻服务器负担，提升整体性能。

从上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，在客户端完成数据传输之后，它就会发起主动关闭连接close()，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：

1）防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2）可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。

HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个 request/response，一个主要原因就是发现了这个问题。

HTTP的交互中关闭连接的不是客户端，而是服务器，所以WEB服务器会出现大量的TIME_WAIT的情况。
解决思路是让服务器能够快速回收和重用那些TIME_WAIT的资源。

主要修改/etc/sysctl.conf的以下参数：
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_*一系列参数，是用来设置服务器检测连接存活的相关配置。

参考：

再谈应用环境下的TIME_WAIT和CLOSE_WAIT：http://shootyou.iteye.com/blog/1129507