TCP的TIME_WAIT状态怎么产生的

我们都知道 TCP 协议是可靠的、面向连接的，且连接为一对一模式，因此不适用于广播和多播场景。TCP 支持全双工通信，类似我们日常打电话 —— 通话前需知道对方手机号来建立连接，这对应 TCP 的三次握手过程；挂断电话时，需双方确认断开后再释放资源。但实际中可能出现一方突然终止连接的情况，另一方未收到通知会持续等待，直至超时后释放占用资源，这个等待阶段就是 TIME_WAIT 状态。

TCP报文的头部结构

需要关注的两个字段

序列号（Sequence Number）

• 标识发送方当前发送数据段的第一个字节的序号。
• 建立连接时会生成初始序列号（ISN），后续数据段的序列号依次递增。

确认号（Acknowledgment Number）

• 标识接收方期望下一次接收的数据段的第一个字节的序号。
• 只有当 ACK 标记位为 1 时，确认号字段才有效，用于确认已成功接收的数据

6种标记位的作用

1. URG（紧急指针有效位）：标记紧急指针字段是否有效，用于发送紧急数据，接收方需优先处理。
2. ACK（确认位）：标记确认号字段有效，表明报文是确认报文，用于对收到的 TCP 报文进行确认。
3. PSH（推送位）：要求接收方立即将数据交给应用层，而非等待缓冲区填满，提升数据传输实时性。
4. RST（复位位）：用于重置 TCP 连接，当连接出现异常时，一方会发送带 RST 位的报文，强制关闭连接并重新建立。
5. SYN（同步位）：用于建立 TCP 连接，在三次握手的前两次报文中设置，用于同步双方的序列号。
6. FIN（终止位）：用于关闭 TCP 连接，表明发送方已无数据要发送，触发四次挥手过程。

TCP的状态图分析

TCP三次握手的状态转移过程

1. 客户端发送 SYN 报文，设置 SYN=1，初始序列号（ISN）为 x，请求建立连接。
2. 服务器回应 SYN+ACK 报文，设置 SYN=1、ACK=1，确认号为 x+1，自身初始序列号（ISN）为 y。
3. 客户端发送 ACK 报文，设置 ACK=1，确认号为 y+1，序列号为 x+1，连接正式建立。

TCP四次挥手状态转移的过程

1. 主动关闭方发送 FIN 报文，设置 FIN=1，序列号为 u，表明无数据要发送，请求关闭连接。
2. 被动关闭方回应 ACK 报文，设置 ACK=1，确认号为 u+1，序列号为 v，确认接收关闭请求。
3. 被动关闭方数据发送完毕后，发送 FIN 报文，设置 FIN=1、ACK=1，序列号为 w，确认号仍为 u+1。
4. 主动关闭方回应 ACK 报文，设置 ACK=1，确认号为 w+1，序列号为 u+1，连接正式关闭。

TIME_WAIT状态存在的原因

TIME_WAIT 状态存在的原因有两点：

• 可靠地终止 TCP 连接。
• 保证让迟来的 TCP 报文段有足够的时间被识别并丢弃。

第一个原因很好理解。假设图 3中用于确认服务器结束报文段 6 的 TCP 报文段 7 丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段（即向服务器发送确认报文段）。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像 TCP 报文段 7 那样的确认报文段