TCP四次分手中,主动关闭方最后为什么要等待2MSL之后才关闭连接?
10 个回答
和TCP三次同步握手不一样的是,TCP关闭连接用四次握手来实现,即A--->B Fin, B--->A ACK, B--->A Fin, A--->B ACK,为什么要这样?
A--->B Fin, B--->A ACK ,A属于主动关闭方,收到B的ACK后,A到B的方向连接关闭,即half shutown ,这时A不能再发送数据了。
这种状态下B还是可以单向发送数据的,B的数据发送完毕,也做关闭动作了:
B--->A Fin, A--->B ACK
B收到ACK,关闭连接。但是A无法知道ACK是否已经到达B,于是开始等待?等待什么呢?假如ACK没有到达B,B会为FIN这个消息超时重传 timeout retransmit ,那如果A等待时间足够,又收到FIN消息,说明ACK没有到达B,于是再发送ACK,直到在足够的时间内没有收到FIN,说明ACK成功到达。这个等待时间至少是:B的timeout + FIN的传输时间,为了保证可靠,采用更加保守的等待时间2MSL。
MSL,Maximum Segment Life,这是TCP 对TCP Segment 生存时间的限制。
TTL, Time To Live ,IP对IP Datagram 生存时间的限制,255 秒,所以 MSL一般 = TTL = 255秒
A发出ACK,等待ACK到达对方的超时时间 MSL,等待FIN的超时重传,也是MSL,所以如果2MSL时间内没有收到FIN,说明对方安全收到FIN。
需要 TIME-WAIT 状态,主要是两个原因:
- 防止具有相同「四元组」的「旧」数据包被收到;
- 保证「被动关闭连接」的一方能被正确的关闭,即保证最后的 ACK 能让被动关闭方接收,从而帮助其正常关闭;
原因一:防止旧连接的数据包
假设 TIME-WAIT 没有等待时间或时间过短,被延迟的数据包抵达后会发生什么呢?
- 如上图黄色框框服务端在关闭连接之前发送的
SEQ = 301
报文,被网络延迟了。 - 这时有相同端口的 TCP 连接被复用后,被延迟的
SEQ = 301
抵达了客户端,那么客户端是有可能正常接收这个过期的报文,这就会产生数据错乱等严重的问题。
所以,TCP 就设计出了这么一个机制,经过 2MSL
这个时间,足以让两个方向上的数据包都被丢弃,使得原来连接的数据包在网络中都自然消失,再出现的数据包一定都是新建立连接所产生的。
原因二:保证连接正确关闭
在 RFC 793 指出 TIME-WAIT 另一个重要的作用是:
TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.
也就是说,TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收,从而帮助其正常关闭。
假设 TIME-WAIT 没有等待时间或时间过短,断开连接会造成什么问题呢?
- 如上图红色框框客户端四次挥手的最后一个
ACK
报文如果在网络中被丢失了,此时如果客户端TIME-WAIT
过短或没有,则就直接进入了CLOSED
状态了,那么服务端则会一直处在LASE_ACK
状态。 - 当客户端发起建立连接的
SYN
请求报文后,服务端会发送RST
报文给客户端,连接建立的过程就会被终止。
如果 TIME-WAIT 等待足够长的情况就会遇到两种情况:
- 服务端正常收到四次挥手的最后一个
ACK
报文,则服务端正常关闭连接。 - 服务端没有收到四次挥手的最后一个
ACK
报文时,则会重发FIN
关闭连接报文并等待新的ACK
报文。
所以客户端在 TIME-WAIT
状态等待 2MSL
时间后,就可以保证双方的连接都可以正常的关闭。
絮叨
小林在知乎写了很多图解网络和操作系统的系列文章,很高兴收获到很多知乎朋友的认可和支持,正好最近图解网络和操作系统的文章连载的有 20+ 篇了,也算有个体系了。
所以为了方便知乎的朋友们阅读,小林把自己原创的图解网络和图解操作系统整理成了 PDF,一整理后,没想到每个图解都输出了 15 万字 + 500 张图,质量也是杠杠的,有很多朋友特地私信我,看了我的图解拿到了大厂的offer。
图解系统 PDF 开源下载:
图解网络 PDF 开源下载:
最后祝大家前程似锦,在编码的道路上一马平川。
如果文章对你帮助的话,可以给@小林coding
点个赞,点个收藏ya~