关于 time wait

偏执的太偏执、 2022-05-20 09:38 138阅读 0赞

网上有很多关于 time wait 的问题和修改方案，究竟什么是 time wait？作用是什么？会造成什么问题？如何解决？我们接下来一点一点看一下。

# 一，time wait 是什么？ #

timewait 状态是 TCP 链接的主动关闭方会有的状态，在发出最后一个 ACK 包之后，主动关闭方进入 timewait 状态，以确保 ACK 包到达对端，以及等待网络中之前迷路的数据包完全消失，防止在端口被复用的时候收到迷路包从而出现收包错误。  
![这里写图片描述][70]

# 二，作用是什么？ #

上面在介绍 time wait 时已经说了，下面再详细说一下：

### 可靠地实现TCP全双工连接的终止 ###

TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME\_WAIT）允许它重发最终的ACK。如果A端不维持TIME\_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。  
因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME\_WAIT状态 。

### 允许老的重复分节在网络中消逝 ###

TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME\_WAIT状态的连接启动一个新的可用连接，因为TIME\_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

# 三，会造成什么问题？ #

time wait 的主要作用是保证关闭的TCP端口不立即被使用，来避免上面说的可能会发生的问题。也就是说，time wait 过多的话，可能造成端口无法使用。

TIME\_Wait的主要作用是保证关闭的TCP端口不立即被使用。因为当网络存在延迟时，可能当某个端口被关闭后，网络中还有一些重传的TCP片在发向这个端口，如果这个端口立即建立新的TCP连接，则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用。这个等待时间基本是从1981年的RFC793过来的，对于服务器实在太长了些。而且每个TCP连接都各自有个数据结构，叫TCP Control block，Time\_wait的时候这个数据结构没有被释放。所以当有太多的TCP连接时，内存可能会被占用很多。

如果有恶意程序大量的连接服务器，虽然很快断开，但产生大量的TIME\_WAIT，逐渐消耗内存。虽然可以通过setsockopt(nListenSocket, SOL\_SOCKET, SO\_REUSEADDR, &nRet, n);让TIME\_WAIT的本地地址和端口被新的进程使用，但系统给新进程分配的端口貌似只有一小部分落到了TIME\_WAIT端口，还是无法解决TIME\_WAIT带来的问题。

目前好像只能在TIME\_WAIT的时间限制上做点文章了，不少管理员同志设置成30秒,至少能缓解服务器在高连接情况下的很大压力

# 四，如何解决 time wait 过多问题 #

1，使用长连接  
使用长连接的话，会减少连接创建， 也就会减少 time wait 的产生。关于长连接，请参看：[关于 Nginx 和 Tomcat 的 http 长连接设置][Nginx _ Tomcat _ http]。

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

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

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

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

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

4，不要设置 tcp\_tw\_recycle  
顾名思义就是回收TIME\_WAIT连接。可以说这个内核参数已经变成了大众处理TIME\_WAIT的万金油，如果你在网络上搜索TIME\_WAIT的解决方案，十有八九会推荐设置它，不过这里隐藏着一个不易察觉的[陷阱][Link 2]

当多个客户端通过NAT方式联网并与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，可惜由于这些客户端的时间戳可能存在差异，于是乎从服务端的视角看，便可能出现时间戳错乱的现象，进而直接导致时间戳小的数据包被丢弃。参考：[tcp\_tw\_recycle和tcp\_timestamps导致connect失败问题][tcp_tw_recycle_tcp_timestamps_connect]。

有的地方说设置 tcp\_fin\_timeout。这个是在 fin\_wait\_2 状态的停留的时间，这个时间越短，到 time wait 状态的时间就越快。但这个是在`连接关闭接收方`半天不返回 Fin 的基础上的。如果很快就返回 Fin 那么这个值没什么作用。

还有的地方意思是修改 tcp\_fin\_timeout，就是修改 time wait 的 MSL 时间，但其实不是这样的。MSL指的是报文段的最大生存时间，如果报文段在网络活动了MSL时间，还没有被接收，那么会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是两分钟，不过实际上不同的操作系统可能有不同的设置，以Linux为例，通常是半分钟，两倍的MSL就是一分钟，也就是60秒，并且这个数值是硬编码在内核中的，也就是说除非你重新编译内核，否则没法修改它：

> # define TCP\_TIMEWAIT\_LEN (60\*HZ) #

# 五，总结 #

## 1，从客户端和服务器端总结 ##

**对于客户端**  
1. 作为客户端因为有端口65535问题，TIME\_OUT过多直接影响处理能力，打开tw\_reuse 即可解决，不建议同时打开tw\_recycle，帮助不大。  
2. tw\_reuse 帮助客户端1s完成连接回收，基本可实现单机6w/s请求，需要再高就增加IP数量吧。  
3. 如果内网压测场景，且客户端不需要接收连接，同时tw\_recycle 会有一点点好处。  
4. 业务上也可以设计由服务端主动关闭连接

**对于服务端**  
1. 打开tw\_reuse无效  
2. 线上环境 tw\_recycle 不要打开  
服务器处于NAT 负载后，或者客户端处于NAT后（这是一定的事情，基本公司家庭网络都走NAT）；公网服务打开就可能造成部分连接失败，内网的话到时可以视情况打开；像我所在公司对外服务都放在负载后面，负载会把timestamp 都给清空，好吧，就算你打开也不起作用。

1.  服务器TIME\_WAIT 高怎么办  
    不像客户端有端口限制，处理大量TIME\_WAIT Linux已经优化很好了，每个处于TIME\_WAIT 状态下连接内存消耗很少，而且也能通过tcp\_max\_tw\_buckets = 262144 配置最大上限，现代机器一般也不缺这点内存。

## 2，名词总结 ##

1.  MSL 由来  
    发起连接关闭方回复最后一个fin 的ack，为避免对方ack 收不到、重发的或还在中间路由上的fin 把新连接给干掉了，等个2MSL，4min。也就是连接有谁关闭的那一方有time\_wait问题，被关那方无此问题。
2.  reuse、recycle  
    通过timestamp的递增性来区分是否新连接，新连接的timestamp更大，那么小的timestamp的fin 就不会fin掉新连接。
3.  reuse  
    通过timestamp 递增性，客户端、服务器能够处理outofbind fin包
4.  recycle  
    对于服务端，同一个src ip，可能会是NAT后很多机器，这些机器timestamp递增性无可保证，服务器会拒绝非递增请求连接。

## 3，查看 time wait 的命令 ##

*  ss -s
 *  netstat -n | awk ’/^tcp/ \{++S\[$NF\]\} END \{for(a in S) print a, S\[a\]\}’

# 参考： #

## 关于 time wait: ##

[TIME\_WAIT状态详解][TIME_WAIT]：关于 time wait 的存在的作用，也是它要解决的问题。  
[TIME\_WAIT状态在tcp连接中的含义与作用][TIME_WAIT_tcp]：也是关于 time wait 的存在的作用。这个讲的更多，挺仔细的，虽然有的地方讲的重复了。  
[理解TIME\_WAIT][TIME_WAIT 1]：讲的非常好，讲了 time wait 原理，还有一些 time wait 多过的解决方法。  
[再叙TIME\_WAIT][TIME_WAIT 2]：解决 time wait 方法总结的非常好，还有一些案例。  
[tcp\_tw\_reuse、tcp\_tw\_recycle 使用场景及注意事项][tcp_tw_reuse_tcp_tw_recycle]：非常好的总结，从客户端和服务器端进行了总结。

## 关于 4 次挥手： ##

[TCP协议中的三次握手和四次挥手(图解)][TCP]：里面关于 4 次挥手的解释非常好。  
[TCP的三次握手、四次挥手–非常详细讲解][TCP 1]：里面讲的状态迁移非常好。还讲解了每次挥手是关闭读还是写。  
[TCP/IP状态图的TIME\_WAIT作用][TCP_IP_TIME_WAIT]：4 次挥手的文字流程讲的很好

[70]: /images/20220520/7bdf7bbac1c24aad84769892f9a93189.png
[Nginx _ Tomcat _ http]: https://blog.csdn.net/hotdust/article/details/81057141
[Link 1]: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
[Link 2]: http://www.litrin.net/2013/03/01/android%E4%B9%8B%E7%BD%91%E7%BB%9C%E4%B8%A2%E5%8C%85%E4%BA%8B%E4%BB%B6/
[tcp_tw_recycle_tcp_timestamps_connect]: http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
[TIME_WAIT]: https://michaelyou.github.io/2015/03/03/TIME-WAIT%E7%8A%B6%E6%80%81%E8%AF%A6%E8%A7%A3/
[TIME_WAIT_tcp]: https://lzw.me/a/tcp-time-wait.html
[TIME_WAIT 1]: http://www.firefoxbug.com/index.php/archives/2795/
[TIME_WAIT 2]: https://huoding.com/2013/12/31/316
[tcp_tw_reuse_tcp_tw_recycle]: http://www.cnblogs.com/lulu/p/4149312.html
[TCP]: https://blog.csdn.net/whuslei/article/details/6667471
[TCP 1]: https://blog.csdn.net/smileiam/article/details/78226816
[TCP_IP_TIME_WAIT]: https://www.iteblog.com/archives/169.html