博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
聊聊tcp四次挥手中的TIME_WAIT状态存在的理由
阅读量:4142 次
发布时间:2019-05-25

本文共 853 字,大约阅读时间需要 2 分钟。

        记得在2012年的时候, 我开始找实习, 某公司笔试题目中提到了TIME_WAIT这些东西, 我简直是一脸懵逼, 第一次见, 这东西讨论来讨论去, 有用么? 呵呵哒。

        下面叙述中, 用A表示tcp连接的主动关闭端, 用B表示被动关闭端。

        我们知道, 在tcp四次挥手中, B发FIN包(第三次挥手)后, A马上回应最后的ACK,  此时, A的socket让然不能立即进入CLOSED的状态, 为什么呢? 其实这就是在问TIME_WAIT状态存在的理由。

        理由之一:

        A不能保证最后的ACK能达到B, 所以, 还应该观望一段时间, 护送一段时间。 如果最后的ACK丢失, 那么B显然收不到,  B于是发起了重传FIN的操作, 此时如果A处于CLOSED的状态, 就没办法给对端发ACK了(实际是发RST), 呜呼哀哉。 所以A应该等一段时间, 这段时间就是所谓的TIME_WAIT, 比如, 等待一个RTT的时间(实际上, 考虑到如下的理由之二就知道, RTT可能不够, 用2MSL更靠谱)。

       所以, TIME_WAIT存在的理由之一是尽可能护送最后的ACK达到对端。

        理由之二:

        假设tcp连接是: A(1.2.3.4:8888)------B(6.7.8.9:9999), 这就是一个tcp四元组。 当tcp连接关闭后, 四元组释放。 后面的新连接可能会重用到这个四元组(有这个可能性), 那么问题就来了: 新四元组和旧四元组完全一致, 他们的网络包会混乱吗?   所以, 可以考虑这样一个机制: 让旧四元组对应的所有网络包都消失后(等一段时间), 才允许新四元组建立, 颇有点锁的味道。 那么这个等一段时间究竟是多久呢? 多久才合适呢? 在前面的文章中, 我们讨论过, 采用2MSL比较合适, 我个人认为, 把TIME_WAIT定义为2MSL只是一个通用的经验方法而已, 无法从理论上百分之百论证。

        所以, TIME_WAIT存在的理由之二是新旧四元组互不干扰。

        关于TIME_WAIT,  我们以后会说更多。

转载地址:http://anwti.baihongyu.com/

你可能感兴趣的文章
【css 一些小问题】 规范 使用占坑,持续更新
查看>>
element-ui el-input / el-select输入框的非空校验
查看>>
在 element ui 自定义的道路上越走越远
查看>>
【经过高人指点的疑难bug】js逻辑 和一些小的注意
查看>>
【vue项目 刷新一下之后 内容消失?】+ 用 route 传递数据
查看>>
垂直居中~
查看>>
【翻页时候 高大上的header栏 挡住渲染效果】和保留p格式。
查看>>
nth-child 麻蛋 不要被它的 child 锁迷惑 要同类元素才行 v-for也没有关系的!
查看>>
transition效果
查看>>
css效果记录
查看>>
垃圾element-ui实在太难用了
查看>>
文件下载, 存一下. 少玩手机少玩手机少玩手机!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
查看>>
不错的网站~ 收藏了qwq
查看>>
最近这周用到的注意事项 + 上周的.
查看>>
乱七八糟的注意点们
查看>>
【转载】css实现三角形。]
查看>>
c# 数组定义 新增 填充 数据
查看>>
js实现 一些数学公式(待补充)
查看>>
JavaScript不要直接console.log打印数组 、 求线段交点
查看>>
有关webpack、 prototype 属性
查看>>