time_wait

Time_wait 问题描述

image.png

在高并发的场景下，TIME_WAIT 连接存在，属于正常现象

线上场景中，持续的高并发场景

一部分 TIME_WAIT 连接被回收，但新的 TIME_WAIT 连接产生；
一些极端情况下，会出现大量的 TIME_WAIT 连接。

Nginx 作为反向代理时，大量的短链接，可能导致 Nginx 上的 TCP 连接处于 time_wait 状态：

每一个 time_wait 状态，都会占用一个「本地端口」，上限为 65535(16 bit，2 Byte)；
当大量的连接处于 time_wait 时，新建立 TCP 连接会出错，address already in use : connect 异常
统计 TCP 连接的状态：


1.  `// 统计：各种连接的数量`
2.  `$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'`
3.  `ESTABLISHED 1154`
4.  `TIME_WAIT 1645`

问题分析

大量的 TIME_WAIT 状态 TCP 连接存在，其本质原因是什么？

大量的短连接存在
特别是 HTTP 请求中，如果 connection 头部取值被设置为 close 时，基本都由「服务端」发起主动关闭连接
而，TCP 四次挥手关闭连接机制中，为了保证 ACK 重发和丢弃延迟数据，设置 time_wait 为 2 倍的 MSL（报文最大存活时间）
TIME_WAIT 状态：
TCP 连接中，主动关闭连接的一方出现的状态；（收到 FIN 命令，进入 TIME_WAIT 状态，并返回 ACK 命令）
保持 2 个 MSL 时间，即，4 分钟；（MSL 为 2 分钟）

解决办法

解决上述 time_wait 状态大量存在，导致新连接创建失败的问题，一般解决办法

客户端：HTTP请求的头部，connection设置为keep-alive，保持存活一段时间，现在的浏览器，一般都这样
服务端：

允许 time_wait状态的socket被重用
缩减time_wait时间，设置为1MSL(即，2min)

结论

TCP连接中，“主动发起关闭连接”的一端，会进入time_wait的状态
time_wait状态，默认会持续2MSL（报文的最大生存时间），一般是2 * 2min
time_wait状态下，TCP连接占用的端口，无法被再次使用，上线是65536
4.大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect 异常

time_wait 状态产生的原因

为实现TCP全双工连接的可靠释放（A->B: 为了保证主动关闭方发送的最后一个ACK能到到对方）这个ACK报文段可能丢失，因而处于Last-ACK状态的B收不到对已经发送的FIN+ACK报文段的确认。 B会超时重传这个FIN+ACK.。如果A不在time-wait状态等一段时间，而是发送完ACK后立即释放连接，那么就无法收到B重传的FIN+ACK报文段。B无法正常closed
为使旧的数据包在网络因过期而消失
A发送完最后一个ACK报文段后，再经过2MSL后，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样下一个新的连接不会出现旧的数据包。 B结束TCP连接的时间比A早一些。

大量TIME_WAIT造成的影响

为什么我们要关注这个高并发短连接呢？有两个方面需要注意

高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围限制，并不是很多，刨除系统和其他服务要用的，剩下的就更少了
在这个场景中，短连接表示“业务处理+传输数据的时间远远小于 TIMEWAIT超时的时间”的连接。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费

综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户端服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题

关于time_wait的反思：

存在即是合理的，既然TCP协议能盛行四十多年，就证明他的设计合理性。所以我们尽可能的使用其原本功能。
依靠TIME_WAIT状态来保证我的服务器程序健壮，服务功能正常。
那是不是就不要性能了呢？并不是。如果服务器上跑的短连接业务量到了我真的必须处理这个TIMEWAIT状态过多的问题的时候，我的原则是尽量处理，而不是跟TIMEWAIT干上，非先除之而后快。
如果尽量处理了，还是解决不了问题，仍然拒绝服务部分请求，那我会采取负载均衡来抗这些高并发的短请求。持续十万并发的短连接请求，两台机器，每台5万个，应该够用了吧。一般的业务量以及国内大部分网站其实并不需要关注这个问题，一句话，达不到时才需要关注这个问题的访问量。

附录： TCP 三次握手和四次握手

1.三次握手，建立连接过程
2.四次挥手，释放连接过程

image.png

几个核心疑问：

1、 time_wait 是「服务器端」的状态？or 「客户端」的状态？

RE：time_wait 是「主动关闭 TCP 连接」一方的状态，可能是「客服端」的，也可能是「服务器端」的
一般情况下，都是「客户端」所处的状态；「服务器端」一般设置「不主动关闭连接」
2、服务器在对外服务时，是「客户端」发起的断开连接？还是「服务器」发起的断开连接？

正常情况下，都是「客户端」发起的断开连接
「服务器」一般设置为「不主动关闭连接」，服务器通常执行「被动关闭」
但 HTTP 请求中，http 头部 connection 参数，可能设置为 close，则，服务端处理完请求会主动关闭 TCP 连接
关于 Apache httpd 服务器的关联配置，参考：https://elf8848.iteye.com/blog/1739571

关于 HTTP 请求中，设置的主动关闭 TCP 连接的机制：TIME_WAIT的是主动断开方才会出现的，所以主动断开方是服务端？

答案是是的。在HTTP1.1协议中，有个 Connection 头，Connection有两个值，close和keep-alive，这个头就相当于客户端告诉服务端，服务端你执行完成请求之后，是关闭连接还是保持连接，保持连接就意味着在保持连接期间，只能由客户端主动断开连接。还有一个keep-alive的头，设置的值就代表了服务端保持连接保持多久。
HTTP默认的Connection值为close，那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。
虽然HTTP默认Connection值为close，但是，现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以，也有人说，现在没有必要通过调整参数来使TIME_WAIT降低了。
关于 time_wait ：

1、TCP 连接建立后，「主动关闭连接」的一端，收到对方的 FIN 请求后，发送 ACK 响应，会处于 time_wait 状态；

2、 time_wait 状态，存在的必要性：

可靠的实现 TCP 全双工连接的终止：四次挥手关闭 TCP 连接过程中，最后的 ACK 是由「主动关闭连接」的一端发出的，如果这个 ACK 丢失，则，对方会重发 FIN 请求，因此，在「主动关闭连接」的一段，需要维护一个 time_wait 状态，处理对方重发的 FIN 请求；
处理延迟到达的报文：由于路由器可能抖动，TCP 报文会延迟到达，为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据，则，需要在允许新创建 TCP 连接之前，保持一个不可用的状态，等待所有延迟报文的消失，一般设置为 2 倍的 MSL（报文的最大生存时间），解决「延迟达到的 TCP 报文」问题