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

【问题标题】：Why are both #seq & #ack setting 1 in the last ACK packet in 3-way-handshake?为什么在 3 次握手的最后一个 ACK 数据包中 #seq 和 #ack 都设置为 1？
【发布时间】：2021-12-12 23:02:18
【问题描述】：

我想知道为什么第三个数据包在 3-way-handshake 中设置为 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

【问题讨论】：

标签： tcp

【解决方案1】：

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

【讨论】：