TCP 终止连接的 TIME_WAIT 状态的存在性分析

TCP 的终止过程也就是常说的四次挥手，以下假设基于 A 主动断连：

• Fin1 ：A————> B， A 发送 Fin1 包告诉 B 我要关闭连接了，没有数据要来了。
• Ack1：B————> A，B 收到 Fin1 包后发送 Ack1，告诉 A，我知道了。
  若此时 B 端的发送缓冲区还有数据，则继续发送直到为空。接着，
• Fin2：B————> A， B 告诉 A 我数据也发完了，可以安全关闭了。
• Ack2：A————> B， A 收到 B 的 Fin2 包，需要告诉 B 自己已经直到你准备好关闭了，关键就出在这儿，下面分析。

前三次挥手过程中如果包丢失了，重传就是了，重传的前提是双方都知道对方还在线（只要一直发消息对方必回复），最后一次可不好说了，因为一方有可能不在线了（崩溃、重启等），因为 Ack2 发送出去不可能再有对它的确认包了，因此只能换一种方式来得知 B 已经获得 Ack2 了，这个方式就是等，下面分析为什么等可以解决：

• Ack2 丢失了：依据是这种情况会触发 B 超时重传，于是 A 在等的过程中会再次收到 Fin1 包；
• Ack2 没丢失：依据是这种情况不触发 B 重传 ，A 在等的过程中不会收到来自 B 的任何 Fin 包。

Ack2 的两种结果都会在 A 继续等待的过程中得到区分，因此 A 能做的就是多等等，以便确认没丢失的情况，从而可以安心清理现场下线。

以上是 TIME_WAIT 状态存在的理由之一，另一个理由如下：
如果没有 TIME_WAIT 阶段，假设有一条 TCP 连接，其两端分别为 IP1: 4290 和 IP2: 2285，这条连接有通信，即该连接相关分组还在网络中运输，
此时我们关闭它，然后立刻重新在这两端建立新的连接，于是当旧连接的分组到达时，新连接无法区分它们属于旧连接还是新连接，于是原本属于旧连接的分组会被新连接接收并处理，这是很恐怖的事。
因而必须有 TIME_WAIT 状态，保证旧连接的所有分组在网络上消失。