为什么 SCTP 不需要 TIME_WAIT 状态？

Question

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

Answer 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 chunk时，将无法确定它属于哪个协会，因为那个协会已经关闭了。因此，A 方会将此数据包视为“突然”。 RFC 4960 chapter 8.4 描述了如何处理突然出现的数据包，项目符号 #5 描述了如何处理“突然出现”的 SHUTDOWN ACK。

在这种情况下，A 方将回复 SHUTDOWN COMPLETE。但是携带SHUTDOWN COMPLETE chunk的包会和原来的略有不同。新数据包会将 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后并没有保留任何状态信息。如果任何属于该关联的数据包在此之后到达，它们将被视为“突然出现”。

为什么 SCTP 不需要 TIME_WAIT 状态？

Why does SCTP not require a TIME_WAIT state?

sockets

tcp

sctp

time-wait