共计 1717 个字符，预计需要花费 5 分钟才能阅读完成。
还是用一下上一篇文章画的图
TCP 的 11 个状态，每一个状态都缺一不可，天然 TIME_WAIT 状态被赋予的意义也是相当重要，咱们间接论断后行
上文咱们提到 tcp 中，被动敞开的一边会进入 TIME_WAIT 状态，
另外 Tcp 中的有 TIME_WAIT 状态，次要是有如下 2 个起因：
- 为了避免被动敞开一方的提早数据被其余连贯窃取
<!—->
- 为了避免被动敞开的一方，没有收到最初的一个 ACK 包
如何了解呢？
为了避免被动敞开一方的提早数据被其余连贯窃取
对于第一个
咱们一个一个的来具体解释一下，还是下面这个图，咱们人为的加一点异样的状况
咱们在 tcp 连贯中，客户端先发动敞开，那么 TIME_WAIT 状态就在客户端这边，如下：
这是一个失常的客户端和服务端通信的根本过程，那么，如果在 client 和 server 建设连贯后，server 端向 client 端发发送的数据，在网络环境中有提早，短时间，没有顺利的达到 client 端的时候，就会呈现如下 状况
如上图
- 咱们人为的画了一个会呈现在事实工作中的问题，当 client 和 server 失常连贯，server 给 client 发的 seq=100 的包，因为网络拥挤等起因，留在了网络环境中
<!—->
- client 首先发动敞开连贯，如果这个时候，没有 TIME_WAIT 状态，或者咱们人为的将 TIME_WAIT 的值设小，就会呈现 seq=100 这个包不能失常的被 client 收到，因为 client 曾经是 CLOSED 状态了
<!—->
- 这个时候，和 client 占用同一端口的程序 client 路人 启动程序并和 server 胜利建设连贯之后，方才的 seq=100 的包才到目标地址，这个时候 client 路人并不冀望收到这个 seq=100 的音讯，那么这对 client 路人来说，这就是一个异样问题了
如果咱们的 TIME_WAIT 状态存在，或者是失常放弃 2MSL 的工夫，就不会呈现这个状况 ，1 个 MSL 是报文在网络环境中的最大存活工夫，对于下面这个例子，client 当初那就还是 TIME_WAIT 状态，client 路人应用 client 的端口，是无奈启动的，且 2MSL 的工夫 seq=100 是齐全能够达到 client 的
那是否会有人问，为什么 client 程序还在的时候，就不能启动 client 路人程序呢？
对于这个，咱们就须要晓得 TCP 的一条连贯，是由四元组组成的
- 源地址
<!—->
- 源端⼝
<!—->
- ⽬的地址
<!—->
- ⽬的端⼝
此处咱们晓得，client 和 client 路人，源地址，目标地址，目标端口，都是一样的，那么此时如果源端口还是一样的话，那么是没有方法 2 个 client 都能失常启动的，其中一个失常启动了，那么另外一个就会报地址曾经被应用
为了避免被动敞开的一方，没有收到最初的一个 ACK 包
再来看第二点
其实下面咱们隐约曾经说到了这一点，只不过不是 ack 包，再应用一下下面的图，咱们人为的弄一个异常情况
如上图，当咱们的 TIME_WAIT 状态不存在，或者设置的工夫较小的时候，就可能会产生被动敞开的一方，收不到最初的一个 ack 包的状况
- 一条 tcp 连贯的四元组当初咱们晓得是啥意思了，那么，当上述 server 对应的连贯还未是 CLOSED 状态的时候，server 是认为以后连贯还是存在的
<!—->
- 然而 client 本身曾经是 CLOSED 状态了，所以对于 client 路人来说，我以后的连贯是无效的，因而我去给 server 发握手包
<!—->
- 可是万万没有想到，server 回绝我的连贯，client 路人就很蒙圈
此时，如果 TIME_WAIT 状态存在，并且期待的工夫是 2MSL，那么哪怕最初一个 ack 包失落了，server 端也能够从新发送一个 FIN 包给到 client，再期待一个新的 ack 包
这样，2 MSL 之后，client 和 server 端，对于这一条连贯，都是失常敞开的
所以，为什么须要 TIME_WAIT 状态，心里有点数了不
感激浏览，欢送交换，点个赞，关注一波 再走吧
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~