为什么#seq 和 #ack 在 3 次握手的最后一个 ACK 数据包中都设置为 1？

Question

我想知道为什么第三个数据包在三次握手中设置了seq=1和ack=1。

 IP (tos 0x10, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    172.17.150.X.63996 > 172.17.150.Y.1234: Flags [S], cksum 0x9b6f (correct), seq 2029035340, win 65535, options [mss 1194,nop,wscale 6,nop,nop,TS val 3650496220 ecr 0,sackOK,eol], length 0
 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.17.150.Y.1234 > 172.17.150.X.63996: Flags [S.], cksum 0x8546 (incorrect -> 0xec39), seq 1295300764, ack 2029035341, win 65160, options [mss 1460,sackOK,TS val 2906721667 ecr 3650496220,nop,wscale 7], length 0
 IP (tos 0x10, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    172.17.150.X.63996 > 172.17.150.Y.1234: Flags [.], cksum 0x1184 (correct), seq 1, ack 1, win 2050, options [nop,nop,TS val 3650496229 ecr 2906721667], length 0

Answer 1

我发现 tcpdump 计算 TCP 数据包中的序列号和确认号是相对的。通过将 -S 选项与 tcpdump 一起使用，我可以看到流量中的数字是绝对的。

为什么#seq 和 #ack 在 3 次握手的最后一个 ACK​​ 数据包中都设置为 1？

Why are both #seq & #ack setting 1 in the last ACK packet in 3-way-handshake?

tcp

为什么#seq 和 #ack 在 3 次握手的最后一个 ACK 数据包中都设置为 1？