tcp - 在 TCP 中，发送纯 ACK 时 SEQ 编号/SND.NXT 是否递增

Question

因此，在很大程度上，我理解了 SEQ 和 ACK 编号是如何确定的(SEQ = SND.NXT = ISN + 发送的字节数，ACK = RCV.NXT = 下一个接收到的数据包预期的 SEQ)。我想知道的是在发送纯 ACK 数据包时 SEQ(连同 SND.NXT 和 SND.UNA)是如何递增的。

例如:(我给客户端 A 的 ISN = 1，服务器 B 的 ISN = 100)

A -> (SEQ = 1, ACK = 100, LEN = 412 bytes)
(A) RCV.NXT = 100, SND.NXT = 413, SND.UNA = 1
(B) RCV.NXT = 413, SND.NXT = 100, SND.UNA = 100

A <- (SEQ = 100, ACK = 413, LEN = 0)
(A) RCV.NXT = 101, SND.NXT = 413, SND.UNA = 413
(B) RCV.NXT = 413, SND.NXT = 101, SND.UNA = 101 **(or 101?)**

A <- (SEQ = 101, ACK = 413, LEN = 1448)
(A) RCV.NXT = 101, SND.NXT = 413, SND.UNA = 413
(B) RCV.NXT = 413, SND.NXT = 1549, SND.UNA = 101

A -> (SEQ = 413, ACK = 1549, LEN = 0)
(A) RCV.NXT = 1549, SND.NXT = 414, SND.UNA = 414 **(or 413?)**
(B) RCV.NXT = 414, SND.NXT = 1549, SND.UNA = 1549

每次发送数据包时递增 SND.NXT 似乎是有意义的(即使 payload len = 0)，但是您是否也递增 SND.UNA？这看起来相当武断，而且是 SND.UNA = ACK 分配的一个奇怪异常(exception)。但是，在我看来，如果您不这样做，那么您的 SND.UNA 将在交换结束时关闭一个。

有什么我想念的吗？

Answer 1

让我们用初始 SYN 重写您的示例以保持清晰:

A- ISN 1000
B- ISN 2000

A -> ([SYN] SEQ = 1000, ACK = ----, LEN = 0 bytes)
(A) RCV.NXT = ----, SND.NXT = 1001, SND.UNA = 1000
(B) RCV.NXT = 1001, SND.NXT = 2000, SND.UNA = ----

A <- ([SYN,ACK] SEQ = 2000, ACK = 1001, LEN = 0)
(A) RCV.NXT = 2001, SND.NXT = 1001, SND.UNA = 1001
(B) RCV.NXT = 1001, SND.NXT = 2001, SND.UNA = 2000

A -> ([ACK] SEQ = 1001, ACK = 2001, LEN = 0 bytes)
(A) RCV.NXT = 2001, SND.NXT = 1001, SND.UNA = 1001
(B) RCV.NXT = 1001, SND.NXT = 2001, SND.UNA = 2001

这样就完成了TCP连接的建立。该序列中的最后一个数据包是“纯 ACK”，即具有 ACK 信号和 0 数据长度的 TCP 数据包。它不推进发件人序列号，因此不推进 snd.nxt 或 snd.una。