• TCP time_wait为什么持续2MSL


    time_wait

    timewait先发起close的一端的第二阶段:
    a fin b,b ack a,b fin a 此时a收到b的fin之后,a处于time_wait,a无法确定自己接下来的ack of fin是否被b收到,所以time_wait还是会持续一段时间。接着可能发生两件事情:

    • 收到b的fin重传(因为b没有收到ack)
    • 相当长一段时间——2MSL,都没有收到b的fin重传

    第一种,那么a可以确定第一次的ack没有及时到达b,继续发送ack,直到发生第二种。此时a可以关闭连接,因为在第一个MSL内,a收到的最后一次fin包发送之前的数据包都已经从网络消失,因为这些数据包到此时已经超过了MSL;又继续等待第二个MSL,确保a发送的ack消失之前重发的fin都没有到达a,而且在ack消失的同时对方重发的fin也已经消失——那么说明网络状态要么足够差,重发这么多fin都没有被a收到,要么a的ack已经被b接收。

    理解为什么是2MSL的原因:假设网络状态极好,fin的ack立即被对方b接收到,对方立即close,那么此时a应该等待1MSL,因为只有等待这么久才能确保对方close之前的包都已经在网络中超时消失。但是如果ack有延迟T才到达b,那么a应该等待T+MSL;ack实际上最大的延迟是MSL,所以TIME_WAI应该等待2MSL再变成close。

    保持2MSL并不是为了解决所有问题,只是为了防止一个问题,那就是防止对方真的close后,还有包在网络中传递,并不是为了确保对方连重传的fin包都消失,实际上应该假设对方重传的fin包一定会被a收到。

    再看b的close,应用层在socketclose之后,可能已经进程退出了,只不过内核还有socket的状态在维护,当然进程可能没有退出。

  • 相关阅读:
    [转]Ant入门教程
    [转]如何用CruiseControl.Net来进行持续化集成
    [书目20130216]深入浅出WPF
    [转]WF事件驱动(4) 持久化
    [转]WF4.0 基础篇 (一)开始使用WF
    [转]VS2010&.Net 4.0 之并行运算(Parallel)(For、Foreach)
    [转]SVN + CruiseControl.NET + NANT 自动编译提交的项目最小DEMO
    [转]WF4.0 基础篇 (六) 数据的传递 Arguments 参数
    [转]WF事件驱动(1)
    [转]WCF开发简简单单的六个步骤
  • 原文地址:https://www.cnblogs.com/linlei2099/p/10689792.html
Copyright © 2020-2023  润新知