TCP TIME_WAIT状态解析及问题解决

迈不过友情╰ 2022-05-23 05:49 147阅读 0赞

# 一、TCP四次挥手过程 #

TCP在建立连接时需要握手，同理，在关闭连接的时候也需要握手。

具体如下所示：

![tcp_close_img.png][]

由于TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭，后发送FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME\_WAIT状态，并且在此状态停留2MSL时长。

对于MSL，其指的是报文段的最大生存时间。如果报文段在网络中活动了MSL时间，还没有被接收，那么就会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是2分钟，不过Linux中，通常是半分钟。

对于TIME\_WAIT状态，有下图：

![tcp_close_timewait.png][]

我们关注几个概念：

*  **TIME\_WAIT的产生条件**：主动关闭方在发送四次挥手的最后一个ACK后会变为TIME\_WAIT状态，持续时间为2MSL（Linux中一个MSL是30秒，是不可配置的）。
 *  **TIME\_WAIT持续两个MSL的作用**：首先，可靠安全地关闭TCP连接。比如网络拥塞，如果主动关闭方最后一个ACK没有被被动关闭方接收到，这时被动关闭方会对FIN进行超时重传，在这时尚未关闭的TIME\_WAIT就会把这些尾巴问题处理掉，不至于对新连接及其他服务产生影响。其次，防止由于没有持续TIME\_WAIT时间导致的新的TCP连接建立起来，延迟的FIN重传包会干扰新的连接。
 *  **TIME\_WAIT占用的资源**：少量内存（大概4K）和一个文件描述符fd。
 *  **TIME\_WAIT关闭的危害**：首先，当网络情况不好时，如果主动方无TIME\_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包到达后会直接影响新的TCP连接；其次，当网络情况不好时，同时没有TIME\_WAIT等待时，关闭连接后无新连接，那么当接收到被动方重传或延迟的FIN包后，会给被动方回送一个RST包，可能会影响被动方其他的服务连接。
 *  **`TCP: time wait bucket table overflow`产生原因及影响**：原因是当TIME\_WAIT数超过了Linux系统的TW数量的阈值。危害是超过阈值后，系统会把多余的TIME\_WAIT Socket删除掉，并且显示警告信息。如果是NAT网络且又存在大量访问时，会产生各种连接不稳定断开的情况。

# 二、相关参数优化调整 #

## 1. tcp\_tw\_recycle ##

顾名思义就是**回收TIME\_WAIT连接**。可以说这个内核参数已经变成了处理TIME\_WAIT的万金油，如果你在网络上搜索TIME\_WAIT的解决方案，十有八九会推荐设置它，不过这里隐藏着一个不易察觉的陷阱：当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，由于这些客户端的时间戳可能存在差异，所以从服务端的视角看，便可能出现时间戳错乱的现象，进而直接导致时间戳小的数据包被丢弃。参考：tcp\_tw\_recycle和tcp\_timestamps导致connect失败问题。

tcp_tw_recycle = 0

备注：**建议不要开启该选项，现在互联网NAT使用很多，可能导致无法进行三次握手**。

> 开启后在3.5\*RTO（RTO时间是根据RTT时间计算而来）内回收TIME\_WAIT，并60s内同一源ip主机的socket connect请求中的timestamp必须是递增的，对于服务端，同一个源ip可能会是NAT后很多机器，这些机器timestamp递增性无可保证，服务器会拒绝非递增请求连接，直接导致不能三次握手。

## 2. tcp\_tw\_reuse ##

顾名思义就是**复用TIME\_WAIT连接**。当创建新连接的时候，如果可能的话会考虑复用相应的TIME\_WAIT连接。通常认为`tcp_tw_reuse`比`tcp_tw_recycle`安全一些，这是因为一来TIME\_WAIT创建时间必须超过一秒才可能会被复用；二来只有连接的时间戳是递增的时候才会被复用。官方文档里是这样说的：如果从协议视角看它是安全的，那么就可以使用。这简直就是外交辞令啊！按我的看法，如果网络比较稳定，比如都是内网连接，那么就可以尝试使用。

不过需要注意的是在哪里使用，既然我们要复用连接，那么当然应该在连接的发起方使用，而不能在被连接方使用。举例来说：客户端向服务端发起HTTP请求，服务端响应后主动关闭连接，于是TIME\_WAIT便留在了服务端，此类情况使用`tcp_tw_reuse`是无效的，因为服务端是被连接方，所以不存在复用连接一说。让我们延伸一点来看，比如说服务端是PHP，它查询另一个MySQL服务端，然后主动断开连接，于是TIME\_WAIT就落在了PHP一侧，此类情况下使用`tcp_tw_reuse`是有效的，因为此时PHP相对于MySQL而言是客户端，它是连接的发起方，所以可以复用连接。

说明：**如果使用tcp\_tw\_reuse，请激活tcp\_timestamps，否则无效**。

tcp_timestamps = 1
    tcp_tw_reuse = 1

## 3. tcp\_max\_tw\_buckets ##

顾名思义就是**控制TIME\_WAIT总数**。官网文档说这个选项只是为了阻止一些简单的DoS攻击，平常不要人为的降低它。如果缩小了它，那么系统会将多余的TIME\_WAIT删除掉，日志里会显示：`TCP: time wait bucket table overflow`。

需要提醒大家的是物极必反，曾经看到有人把「tcp\_max\_tw\_buckets」设置成0，也就是说完全抛弃TIME\_WAIT，这就有些冒险了，用一句围棋谚语来说：入界宜缓。

当出现`TCP: time wait bucket table overflow`时，尽量调大下面参数：

tcp_max_tw_buckets = 256000

# 三、总结 #

有时候，如果我们换个角度去看问题，往往能得到四两拨千斤的效果。前面提到的例子：客户端向服务端发起HTTP请求，服务端响应后主动关闭连接，于是TIME\_WAIT便留在了服务端。这里的关键在于主动关闭连接的是服务端！**在关闭TCP连接的时候，先出手的一方注定逃不开TIME\_WAIT的宿命**，套用一句歌词：把我的悲伤留给自己，你的美丽让你带走。如果客户端可控的话，那么在服务端打开KeepAlive，尽可能不让服务端主动关闭连接，而让客户端主动关闭连接，如此一来问题便迎刃而解了。

# 四、补充 #

**RST简介**：

在TCP协议中，RST表示复位，用来关闭异常连接。**发送RST包关闭连接时，不必等到缓冲区的数据包都发送出去，直接丢弃缓存区的数据包而发送RST包。接收端在接收到RST包后，不必发送ACK包来确认**。

出现RST的几种情况：

*  **端口未打开**：客户端连接服务器程序未打开的端口。当客户端向服务器的某个端口发送SYN请求后，但是服务器上并没有打开该端口，因此其会向客户端发送RST。但是，并不是所有的操作系统都会发送RST给客户端，win7就会直接忽略该SYN报文。
 *  **在一个已关闭的socket上收到数据**：如果某个socket已经关闭，但是依然接收数据，那么也会产生RST。
 *  **接收缓冲区还存在数据时，关闭连接**：在请求方请求数据，未处理完缓冲区中的所有数据，就请求关闭连接时，请求方不会如预期的发送FIN包，进入4路关闭逻辑，而是可能会直接发送一个RST包强制完成连接的关闭。

参考：[https://my.oschina.net/costaxu/blog/127394][https_my.oschina.net_costaxu_blog_127394]

# 参考文献 #

*  [http://blog.csdn.net/dog250/article/details/13760985][http_blog.csdn.net_dog250_article_details_13760985]
 *  [http://blog.sina.com.cn/s/blog\_781b0c850100znjd.html][http_blog.sina.com.cn_s_blog_781b0c850100znjd.html]
 *  [https://huoding.com/2013/12/31/316][https_huoding.com_2013_12_31_316]
 *  [http://benpaozhe.blog.51cto.com/10239098/1767612][http_benpaozhe.blog.51cto.com_10239098_1767612]

[tcp_close_img.png]: http://img.kiterunner.top/tcp_close_img.png
[tcp_close_timewait.png]: http://img.kiterunner.top/tcp_close_timewait.png
[https_my.oschina.net_costaxu_blog_127394]: https://my.oschina.net/costaxu/blog/127394
[http_blog.csdn.net_dog250_article_details_13760985]: http://blog.csdn.net/dog250/article/details/13760985
[http_blog.sina.com.cn_s_blog_781b0c850100znjd.html]: http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
[https_huoding.com_2013_12_31_316]: https://huoding.com/2013/12/31/316
[http_benpaozhe.blog.51cto.com_10239098_1767612]: http://benpaozhe.blog.51cto.com/10239098/1767612