TCP四次挥手客户端关闭链接为什么要等待2倍MSL
最长报文寿命
在TCP协议中，当发送方发送释放连接报文收到确认报文后，只是在一个方向上断开了TCP连接，然后，接收方发送释放连接的报文，发送方回复确认。此时，连接还没有释放，发送方要等待2MSL（maximum segment lifetime——最大的生命周期）后关闭连接。
问题
主动发起关闭连接的操作的一方将达到TIME_WAIT状态，而且这个状态要保持Maximum Segment Lifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态？
原因：
保证TCP协议的全双工连接能够可靠关闭
保证这次连接的重复数据段从网络中消失
解释：
如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。
最新文章
- 1000行代码实现MVVM (类似Angular1.x.x , Vue)
- 小谈Jquery框架
- HTML 样式属性
- 浅析C语言指针问题
- JAVA环境配置-Eclipse新建项目
- 百度浏览器+hao123评价
- nginx 负载均衡策略
- 菜鸟学Windows Phone 8开发(1)——创建第一个应用程序
- 字符串转化为json方法
- iOS开发那些事-iOS应用本地化-资源文件本地化
- 《高性能JavaScript》的新征程
- LigerUI权限系统之用户管理
- Spring Security 入门（1-3-1）Spring Security - http元素 - 默认登录和登录定制
- istio-mix介绍
- 用git如何把单个文件回退到某一版本
- 【Java】 剑指offer(29) 顺时针打印矩阵
- sencha touch 入门学习资料大全(2015-12-30)
- JSON语言规范与Java中两种解析工具基本使用
- [APIO2018] Duathlon 铁人两项 圆方树，DP
- Cordova 打包签名