1

我正在发送一些TCP SYN数据包以获取TCP RST的返回。为了识别每个探针，我在 TCP 序列字段中包含一个计数器。我注意到以下内容：

  • 当 SYN 探测中的序列号为 0, 1, 2, 3... 时，RST 消息有 ack=1, 2, 3, 4...，即ack=syn_seq+1：

12:17:27.181993 IP XXXX10104 > YYY10114: 标志 [S], seq 0 , win 8192, 长度 0 12:17:27.182008 IP YYYY10114 > XXXX10104: 标志 [R.], seq 0, ack 1 , win 0, 长度 0 12:17:27.683148 IP XXXX10104 > YYYY10114: 标志 [S], seq 1, win 8192, 长度 0 12:17:27.683156 IP YYYY10114 > XXXX10104: 标志 [R.], seq 0, ack 2 , win 0, 长度 0 12:17:28.184140 IP XXXX10104 > YYYY10114：标志 [S]，seq 2，win 8192，长度 0 12:17:28.184147 IP YYYY10114 > XXXX10104：标志 [R.]，seq 0，ack 3，win 0，长度 0 12:17:28.684993 IP XXXX10104 > YYYY10114：标志 [S]，seq 3, win 8192, length 0 12:17:28.685000 IP YYYY10114 > XXXX10104: Flags [R.], seq 0, ack 4 , win 0, length 0

  • 另一方面，当我的探针以seq > 1开始时，第一个rst 将像往常一样具有ack=syn_seq+1，但随后的 rst 将具有ack=2,3,4 ...无论序列值如何探头：

12:11:25.274636 IP XXXX59150 > YYYY59160: 标志 [S], seq 299 , win 8192, 长度 0 12:11:25.274649 IP YYYY59160 > XXXX59150: 标志 [R.], seq 0, ack 300 , win 0, 长度 0 12:11:25.775218 IP XXXX59150 > YYYY59160: 标志 [S], seq 300 , win 8192, 长度 0 12:11:25.775226 IP YYYY59160 > XXXX59150: 标志 [R.], seq 0, ack 2 , win 0, 长度 0 12:11:26.276324 IP XXXX59150 > YYYY59160: 标志 [S], seq 301 , win 8192, 长度 0 12:11:26.276332 IP YYYY59160 > XXXX59150: 标志 [R.], seq 0, ack 3 , win 0, 长度 0 12:11:26.776940 IP XXXX59150 > YYYY59160：标志 [S]，seq 302, win 8192, length 0 12:11:26.776948 IP YYYY59160 > XXXX59150: Flags [R.], seq 0, ack 4 , win 0, length 0

这是预期的行为吗？

4

2 回答 2

1

TCP 会话的每一端都以（相对）零序号开始。

同样，确认号也为零，因为还没有对话的补充方要确认。

服务器以序列号 0 响应客户端，因为这是它在此 TCP 会话中的第一个数据包，并且相对确认号为 1。

确认号设置为 1 表示在数据包中收到客户端的 SYN 标志。

现在到你的情况：

序列号有双重作用：

如果 SYN 标志设置为 (1)，则这是初始序列号。实际第一个数据字节的序列号和相应 ACK 中的确认号就是这个序列号加 1。

如果 SYN 标志清零 (0)，则这是当前会话的该段的第一个数据字节的累积序列号。

从维基百科复制的块引用部分。

所以，你的 SYN 标志可能是 0。

如果是这样，那是默认行为。

于 2013-11-06T11:55:09.930 回答
0

好的，实际上没有真正的问题。当我使用 Wireshark 检查数据包并查看数据包中的真实位时，每个 RST 数据包的 ack 值都设置为seq_of_syn + 1，像往常一样。

tcpdump只是在输出中使用了一个相对的确认号。就这样。

于 2013-11-06T17:13:34.383 回答