TimeWait
以前我写过探讨过TCP close_wait 状态过多的问题,现在遇到一个可能timewait过多的问题。
查询命令
查询服务器timewait数量命令
shell> ss -ant | awk '
NR>1 {++s[$1]} END {for(k in s) print k,s[k]}
'
或者
shell> cat /proc/net/sockstat
TimeWait处于的状态
tcp关闭的时候时候如下图
关闭的时候:
- 主动关闭方发送fin信号, 进入fin-wait-1状态
- 被动关闭方接受fin信号, 同时返回一个ack信号,进入close-wait状态
- 主动关闭方,接受ack信号,进入fin-wait-2状态
- 被动关闭方准备好关闭步骤后,发送一个fin信号。
- 主动关闭方接受fin信号,返回一个ack信号,进入time_wait状态。
- 被动关闭方接受ack信号,关闭连接
- 主动关闭方等待2倍的msl(maximun segment lifetime)时间然后再关闭连接
以下引用参考资料:
穿插一点MSL的知识:MSL指的是报文段的最大生存时间,
如果报文段在网络活动了MSL时间,还没有被接收,那么会被丢弃。
关于MSL的大小,RFC 793协议中给出的建议是两分钟,
不过实际上不同的操作系统可能有不同的设置,
以Linux为例,通常是半分钟,两倍的MSL就是一分钟,也就是60秒,
并且这个数值是硬编码在内核中的,也就是说除非你重新编译内核,
否则没法修改它
为什么不直接close
这是因为TCP是建立在不可靠网络上的可靠的协议。例子:主动关闭的一方收到被动关闭的一方发出的FIN包后,回应ACK包,同时进入TIME_WAIT状态,但是因为网络原因,主动关闭的一方发送的这个ACK包很可能延迟,从而触发被动连接一方重传FIN包。极端情况下,这一去一回,就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED,或者在TIME_WAIT停留的时长不足两倍的MSL,那么当被动关闭的一方早先发出的延迟包到达后,就可能出现类似下面的问题:
- 旧的TCP连接已经不存在了,系统此时只能返回RST包
- 新的TCP连接被建立起来了,延迟包可能干扰新的连接
不管是哪种情况都会让TCP不再可靠,所以TIME_WAIT状态有存在的必要性。