为什么 SCTP 不需要 TIME_WAIT 状态？答案

【问题标题】：Why does SCTP not require a TIME_WAIT state?为什么 SCTP 不需要 TIME_WAIT 状态？
【发布时间】：2017-08-02 11:33:13
【问题描述】：

我正在阅读“UNIX 网络编程：套接字 API”，其中提到 SCTP 不需要 TIME_WAIT 状态，因为 TCP 使用了验证标签。为什么会这样？我理解为什么验证标签解决了重复数据包的问题，因为接收方可以确定数据包是否是当前 SCTP 关联的一部分，但最终的 SCTP SHUTDOWN-COMPLETE 数据包肯定会丢失，就像 TCP 中的最终 ACK 一样丢失，因此执行主动关闭的对等方仍然必须保持某种状态来处理此事件，就像使用 TCP 一样。

【问题讨论】：

TIME_WAIT 防御未来的数据包，而不是 ACK 丢失。
TIME_WAIT 两者都有；如果客户端执行主动关闭并且其最终的 TCP ACK 出于某种原因没有发送到服务器，则服务器将重新发送其 FIN（因为 TCP 是可靠的协议），因此客户端需要维护状态信息以允许它重新发送其最终的 ACK

标签： sockets tcp sctp time-wait

【解决方案1】：

在这种情况下不需要维护状态信息。 RFC 4960 定义了一种对未知（出乎意料）数据包的默认处理方式。

假设您的关联中有两个面：A 面和 B 面。v1/v2 是这些面使用的验证标签。 A 面启动关机。

`
A                      B
       Shutdown(v1)
  -------------------->
    Shutdown_ack(v2)
  <--------------------
  Shutdown_complete(v1)
  -------------------->
`

当 A 方发送 SHUTDOWN COMPLETE 时，它会释放此关联使用的所有资源。就 A 方而言，该协会已不复存在。

如果由于某些原因 SHUTDOWN COMPLETE 块丢失，则 B 端将在 t2 计时器（RFC 4960 术语）到期后重新传输 SHUTDOWN ACK 块。

当 A 方接收到这个重传的 SHUTDOWN ACK 块时，它将无法确定它属于哪个关联，因为该关联已经关闭。因此，A 方会将此数据包视为“出乎意料”。 RFC 4960 chapter 8.4 描述了如何处理意外的数据包，第 5 条描述了如何处理“意外”的 SHUTDOWN ACK。

在这种情况下，A 方将回复 SHUTDOWN COMPLETE。但是，携带 SHUTDOWN COMPLETE 块的数据包将与原始数据包略有不同。新数据包将 t 位设置为 1 并包含所谓的反射验证标签（它只是来自包含 SHUTDOWN ACK 的数据包的验证标签）。 A B Shutdown(v1) --------------------> Shutdown_ack(v2) <-------------------- Shutdown_complete(v1) -------LOST-------- Shutdown_ack(v2) <-------------------- Shutdown_complete(v2), t-bit=1 -------------------->

B端知道如何处理t位设置为1的数据包并处理SHUTDOWN COMPLETE。

就你所见，A 方一旦发送 SHUTDOWN COMPLETE 就不会保留任何状态信息。如果任何属于该关联的数据包在此之后到达，它们将被视为“意外”。

【讨论】：