扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长的最长时间,超过这个时间报文将被丢弃。我们都知道IP头部中有个TTL字段,TTL是time to live的缩写,可译为“生存时间”,这个生存时间是由源主机设置设置初始值但不是但不是存在的具体时间,而是一个IP数据报可以经过的最大路由数,每经过一个路由器,它的值就减1,当此值为0则数据报被丢弃,同时发送ICMP报文通知源主机。RFC793中规定MSL为2分钟,但这完全是从工程上来考虑,对于现在的网络,MSL=2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。TTL与MSL是有关系的但不是简单的相等关系,MSL要大于TTL。
创新互联建站专注于驻马店企业网站建设,响应式网站,商城开发。驻马店网站建设公司,为驻马店等地区提供建站服务。全流程定制网站开发,专业设计,全程项目跟踪,创新互联建站专业和态度为您提供的服务
下面我们来看一张TCP连接释放的图:
(此图摘自谢希任计算机网络第六版)
从上图我们注意到,在TCP连接释放的过程中,从TIME_WAIT状态到CLOSED状态有一个超时设置,这个超时设置是2MSL(RFC793定义MSL为2分钟),那么为什么在TIME_WAIT后必须等待2MSL时间呢?主要原因有两点(在我的上一篇博客中有讲,我们再来说下吧):
1.为了保证客户端(我们记为A端)发送的最后一个ACK报文段能够到达服务器端。这个ACK报文段有可能丢失,因而使处在LASK—ACK端的服务器端(我们记为B端)收不到对已发送的FIN+ACK报文段。B会超时重传这个FIN+ACK报文段,而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认,重新启动2MSL计时器。最后,A和B都正常进入到CLOSED状态。如果A在TIME_WAIT状态不等待一段时间,而是在发送完ACK确认后立即释放连接,那么就无法收到B重传的FIN+ACK报文段,因而也不会再发送一次确认报文段,这样,B就无法正常进入CLOSED状态。
2.我们都知道,假如A发送的第一个请求连接报文段丢失而未收到确认,A就会重传一次连接请求,后来B收到了确认,建立了连接。数据传输完毕后,就释放了连接。A共发送了两个连接请求报文段,其中第一个丢失,第二个到达了B。假如现在A发送的第一个连接请求报文段没有丢失,而是在某些网络节点长时间都留了,以至于延误到连接释放后的某个时间才到达B,这本来是已失效的报文段,但B并不知道,就会又建立一次连接。而等待的这2MSL就是为了解决这个问题的,A在发送完最后一个确认报后,在经过时间2MSL,就可以使本链接持续时间内所产生的所有报文段都从网络中消失,这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
我们回到MSL,在2MSL时间内,该地址上的连接(客户端地址,端口和服务器的端口地址)不能被使用,比如我们在建立一个连接后关闭连接然后迅速重启连接,那么就会出现端口不可用的情况。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流