TIME_WAIT存在的原因

在日常维护中,经常使用netstat -antp 查看服务器端口连接情况.有时发现好多TIME_WAIT,

1. 在TCP关闭连接的4次握手中,主动关闭的一方在发送最后一个ack后,发起关闭的一方就会进入TIME_WAIT状态,在这点要注意一点,不仅客户端能发起关闭,服务器端也能发起关闭请求.当服务器上出现TIME_WAIT的话,就说明是服务器端先发起了关闭连接的请求

存在的原因是:  如果当主动发起关闭请求的一方在发送完最后的ack后给被动关闭一方后,但不能保证这个ack能够被被动一方接收,所以如果在ack发送失败的情况下,被动一方将在重新发一次fin给主动一方,所以如果进入主动一方直接进入CLOSED状态的话,就不能接收这个重发的fin包了,导致连接不能正常关闭.就会有一个飘着的没有关闭的数据连接,而等待了2msl后,这些没有正常关闭的数据连接都会丢弃掉

TIME_WAIT的时间是2MSL,缺省为240秒(4分钟)

 查看端口状态命令:

tcp状态解释:

LISTEN：监听端口并接收新连接,例如监听80端口

SYN-SENT：再发送连接请求后等待匹配的连接请求,例如客户端发送了一个syn-sent给服务器端,等待服务端响应

SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认,例如服务端收到了客户端的syn-sent数据包,同时自己发送了一个syn包给客户端,等待客户端的响应
ESTABLISHED：代表一个打开的连接,例如客户端已经和服务端连接成功且已经开始传输数据
FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认,例如发起主动关闭的一方在发送完fin数据包后,会进入FIN-WAIT-1状态

FIN- WAIT-2：从远程TCP等待连接中断请求
CLOSE-WAIT：等待从本地用户发来的连接中断请求

CLOSING：等待远程TCP对 连接中断的确认
LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认
TIME-WAIT：等待足够的时间以确保远程TCP接 收到连接中断请求的确认
CLOSED：没有任何连接状态

转载请注明：爱开源 » TIME_WAIT存在的原因