TCP 断开连接四次挥手过程中,主动断开连接的一方,在第四次挥手(回复 ACK 报文)后,会进入 TIME_WAIT 状态,等待 2*MSL 后才进入 CLOSE 状态。
RFC793 定义 MSL 为 2 分钟,但实际应用中常用的是30秒,1分钟和2分钟等。Linux 内核通常硬编码为 30 秒。
这么做有两个原因:
如果 ACK 报文丢失,被动断开连接的一方会超时重传 FIN 报文,所以需要等待 2MSL 时间处理重传的 FIN 报文,确保对方接收到确认,正常关闭连接。
让旧连接报文从网络中消失,避免新连接收到旧连接的报文。如果不等,释放的端口可能会重新与服务器建立连接,这样依然存活在网络里的旧连接 TCP 报文可能与新连接 TCP 报文冲突,造成数据冲突。
如果客户端(主动发起关闭连接)存在大量 TIME_WAIT 状态连接,会占用端口资源,导致新建 TCP 连接出错,报address already in use : connect
异常。
如果服务端(主动发起关闭连接)存在大量 TIME_WAIT 状态连接,并不会导致端口资源受限,因为服务端只监听一个端口,而且由于一个四元组唯一确定一个 TCP 连接,因此理论上服务端可以建立很多连接。但是 TCP 连接过多,会占用系统资源,比如文件描述符、内存资源、CPU 资源、线程资源等。
比如 HTTP/1.0 请求与回包中,在 Header 中添加Connection: keep-alive
。
从 HTTP/1.1 开始, 就默认是开启了 keep-alive,现在大多数浏览器都默认使用 HTTP/1.1,所以 keep-alive 都是默认打开的。
如果要关闭 HTTP Keep-Alive,需要在 HTTP 请求或者响应的 header 里添加 Connection:close 信息,也就是说,只要客户端和服务端任意一方的 HTTP header 中有Connection:close
信息,那就无法使用 HTTP 长连接机制。
修改 /etc/sysctl.conf 文件中的相关配置,然后执行sysctl -p
命令使配置生效。
开启后,可以复用处于 TIME_WAIT 的 socket 为新的连接所用。
有一点需要注意的是,tcp_tw_reuse 功能只能用客户端(连接发起方),因为开启了该功能,在调用 connect() 函数时,内核会随机找一个 TIME_WAIT 状态超过 1 秒的连接给新的连接复用。
使用这个选项,还有一个前提,需要打开对 TCP 时间戳的支持,即
net.ipv4.tcp_timestamps=1(默认即为 1)
这个时间戳字段在 TCP 头部的「选项」里,占用 8 个字节。其中第一个 4 字节保存发送该数据包的时间,第二个 4 字节保存最近一次接收到对方数据的时间。
由于引入了时间戳,前面提到的旧连接延迟报文问题就不复存在了,因为重复的报文会因为时间戳过期被自然丢弃。
这个值默认为 18000,当系统中处于 TIME_WAIT 的连接一旦超过这个值时,新的 TIME_WAIT 连接会被立即销毁,并打印警告,这个方法比较暴力。
我们可以通过设置 socket 选项,来设置调用 close 关闭连接行为。
struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));
如果 l_onoff 为非 0, 且 l_linger 值为 0,那么调用 close 后,会立该发送一个RST标志给对端,该 TCP 连接将跳过四次挥手,也就跳过了 TIME_WAIT 状态,直接关闭。
这为跨越 TIME_WAIT 状态提供了一个可能,不过是一个非常危险的行为,不值得提倡。
TIME_WAIT 是我们的朋友,不要试图避免这个状态,而是应该弄清楚它。
TIME_WAIT 不是 Bug,而是被设计出来的有着非常重要作用的特性,它是保证 TCP 协议可靠性不可缺失的设计。
如果过多的 TIME_WAIT 影响了系统的运行,能通过加机器解决的话就尽量加机器,如果不能解决,我们就需要理解其背后的设计原理并尽可能避免修改默认的配置。
如果服务端要避免过多的 TIME_WAIT 状态的连接,就永远不要主动断开连接,让客户端去断开,由分布在各处的客户端去承受 TIME_WAIT。
4.1 TCP 三次握手与四次挥手面试题 - 小林coding
为什么TCP 协议有TIME_WAIT 状态 - 面向信仰编程