TIME_WAIT产生的原因
假设主动关闭连接的一方为A,被动关闭连接的一方为B
A调用close();协议层发送FIN包,进入FIN_WAIT_1状态
B收到FIN包后,回复ACK,进入CLOSE_WAIT状态,A等待对方关闭,进入FIN_WAIT_2状态,此时,A会等待B的应用程序调用close操作
B在完成所有数据发送后,调用close()操作;此时,协议层会发送FIN包给A,然后等待对方的ACK,进入LAST_ACK状态;
A收到FIN包,回复ACK,进入TIME_WAIT状态;B收到ACK后,进入CLOSED状态; 如果B没有受到ACK,那么将再次发送FIN包给A,确保连接关闭的可靠性
等待2MSL时间,主动关闭的一方,结束TIME_WAIT,进入CLOSED状态;如果在此期间收到了新的FIN,那么会在回复ACK之后,重新等待2MSL
TIME_WAIT有什么用呢?
如果没有TIME_WAIT这个状态,主动方直接关闭连接
的时候。 两种情况下,处理会出问题。
- 如果A和B又
重新建立链接
,而这个时候B上次连接没有收到A
的ack,导致重传的fin过来了
,这将影响新的连接。 - AB之间没有新连接,B没有收到A的ack,
导致重传的fin过来了
,A会给B发一个RST包,可能会影响B其它的服务连接。
TIME_WAIT造成的危害
消耗资源
未释放的socket会占用内存、CPU、文件描述符数量
等等
解决办法
修改内核参数
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_tw_reuse启用时,当主动关闭连接的一方,再次向对方发起连接请求的时候,可以复用TIME_WAIT状态的连接。 系统根据时间戳判断是否是延迟的数据,如果是,则丢弃。
net.ipv4.tcp_tw_recycle启用时,回收时间不再是2msl而是一个RTO(retransmission timeout,数据包重传的timeout时间),远小于2msl,约0.7s。
客户端:短链接改长连接
HTTP 请求的头部, connection 设置为 keep-alive, 保持存活一段时间;
长连接从根本上减少了关闭连接的次数
,减少了TIME_WAIT状态的产生数量
,在高并发的系统中非常有效,现在的浏览器, 一般都这么进行了 。
服务器端
a. 允许 time_wait 状态的 socket 被重用
b. 缩减 time_wait 时间, 设置为 1 MSL(即, 2 mins)
不主动关闭socket
不主动关闭socket,就不会产生TIME_WAIT状态