1、释放流程图

释放流程图

2、TCP 使用 “四报文挥手” 释放连接的具体过程

TCP 通过 “四报文挥手” 来释放连接

数据传输结束后，TCP 通信双方都可以释放连接

现在 TCP 客户进程和 TCP 服务器进程都处于$连接已建立状态$。

---

假设 TCP 客户进程的应用进程通知其主动关闭 TCP 连接

TCP 客户进程会发送 TCP 连接释放报文段

• 并进入$终止等待1状态$

该报文段首部中终止位 FIN 和确认位 ACK 的值被设置位 $1$

• 表明这是一个 TCP 连接释放报文段

同时也对收到的报文段进行确认。

假定序号 seq 字段的值设置为 $u$

• 其等于 TCP 客户进程之前已传送的、数据的最后一个字节的序号 + $1$

注意：TCP 规定终止位 FIN 等于 $1$ 的报文段即使不携带数据，也要消耗掉一个序号

确认字段 ack 值设置为 $v$

• 它等于 TCP 客户端进程之前已收到的、数据的最后一个字节的序号 + $1$

---

TCP 服务器进程收到一个 TCP 连接释放报文段后，会发送一个普通的 TCP 确认报文段

• 并进入$关闭等待状态$

该报文段首部中确认位 ACK 的值被设置位 $1$

• 表明这是一个普通的 TCP 确认报文段

序号 seq 字段的值设置为 $v$

• 其等于 TCP 服务器按进程之前已传送的数据的最后一个字节的序号 + $1$
• 这也与之前收到的 TCP 连接释放报文段中的确认号匹配

确认号 ack 的值设置为 $u+1$

• 这是对 TCP 连接释放报文段的确认

---

TCP 服务器进程这时应通知高层应用进程：

• TCP 客户进程要断开于自己的 TCP 连接

此时从 TCP 客户进程到 TCP 服务器进程这个方向的连接就释放了

这时的 TCP 连接属于$半关闭状态$

• 也即是 TCP 客户进程已经没有数据要发送了

但 TCP 服务进程如果还有数据要发送，TCP 客户进程仍要接收

• 也就是说从 TCP 服务器进程到 TCP 客户进程这个方向的连接并没有关闭

这个状态可能会持续一段时间

---

TCP 客户进程在收到 TCP 确认报文段后就进入$终止等待2状态$

• 等待 TCP 服务器进程发出的 TCP 连接释放报文段

若使用 TCP 服务器进程的应用进程已经没有数据要发送了

• 应用进程就通知其 TCP 服务器进程释放连接

由于 TCP 连接释放是由 TCP 客户进程主动发起的

• 因此 TCP 服务器进程对 TCP 连接的释放称为被动关闭连接

---

TCP 服务器进程发送 TCP 连接释放报文段

• 并进入$最后确认状态$

该报文段首部中终止位 FIN 和确认位 ACK 的值被设置位 $1$

• 表明这是一个 TCP 连接释放报文段

同时也对收到的报文段进行确认。

假定序号 seq 字段的值设置为 $w$

• 因为这是半关闭状态下，TCP 服务器进程可能又发送了一些数据

确认号 ack 字段的值为 $u+1$

• 这是对之前收到的 TCP 连接释放报文段的重复确认

---

TCP 客户进程必须针对该报文段发送普通的 TCP 确认报文段

• 之后进入时间$等待状态$

该报文段首部中的确认位 ACK 的值被设置为 $1$

• 表明这是一个普通的 TCP 确认报文段

序号 seq 字段的值设置为 $u+1$

• 这是因为 TCP 客户进程之前发送的 TCP 连接释放报文段虽然不携带数据，弹药消耗掉一个序号

确认号 ack 字段的值为 $w+1$

• 这是对之前收到的 TCP 连接释放报文段的确认

---

TCP 服务器进程收到该报文段后就进入$关闭状态$

而 TCP 客户进程还要经过 $2MSL$ 后才能进入$关闭状态$

MSL（Maximum Segment Lifetime）意思是$最长报文段寿命$，RFC793 建议为 $2$ 分钟。

• 就是说 TCP 客户进程进入时间等待状态后，还要经过 $4$ 分钟才能进入关闭状态
• 这完全是从工程上考虑

对于现在的网络 MSL 取为 $2$ 分钟可能太长了，因此 TCP 允许不同的实现可根据具体情况使用更小的 MSL 值

---

3、TCP 客户进程进入时间等待状态 2MSL后才进入关闭状态

那么，TCP 客户进程在发送完最后一个确认报文段后，为什么不直接进入关闭状态，而是要进入时间等待状态 $2MSL$ 后才进入关闭状态

• 是否要必要呢？

---

TCP 服务器进程发送 TCP 连接释放报文段后进入最后确认状态

TCP 客户进程收到该报文段后，发送普通的 TCP 确认报文段

• 并进入关闭状态而不是时间等待状态

然而，该 TCP 确认报文段丢失了

• 这必然会造成 TCP 服务器进程对之前所发送的 TCP 连接释放报文段的超时重传
• 并仍处于最后确认状态

重传的 TCP 连接释放报文段到达 TCP 客户进程

由于 TCP 客户进程属于关闭状态，因此不理睬该报文段

• 这必然会造成 TCP 服务器进程反复重传 TCP 连接释放报文段
• 并一致处于最后确认状态而无法进入关闭状态

因此，时间等待状态以及处于该状态 $2MSL$ 时长可以确保 TCP 服务进程可以收到最后一个 TCP 确认报文段而进入关闭状态

---

另外，TCP 客户进程在发送完最后一个 TCP 确认报文段后，在经过 $2MSL$ 时长

• 就可以使本次连接持续时间内所产生的所有报文段都从网络中消失

这样就可以使下一个新的 TCP 连接中，不会出现旧连接中的报文段

---

4、TCP中保活计时器的作用

如下所示，TCP 双方已经建立了 TCP 连接

突然 TCP 客户进程所在的主机突然出现了故障

• 显然，TCP 服务器进程就不能再收到 TCP 客户进程发来的数据

因此，应当有措施使 TCP 服务器进程不能再白白等待下去

• 即：TCP 服务器进程应该如何发现这种情况呢？

---

方法就是使用$保活计时器$

TCP 服务器进程每收到一次 TCP 客户进程的数据，就重新设置并启动保活计时器（$2$ 小时定时）。

若保活计时器定时周期内未收到 TCP 客户进程发来的数据

• 则当保活计时器到时后，TCP 服务器进程就向 TCP 客户进程发送一个探测报文段，以后则每隔 $75$ 秒钟发送一次。

  若一连发送 $10$ 个探测报文段后仍无 TCP 客户进程的响应，TCP 服务器进程就认为 TCP 客户进程所在主机出了故障，接着就关闭这个连接。

---

5、小结