时间戳

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

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

问题描述

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

解决方案

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

推荐阅读