TCP SYN 和 TCP RST 的 TCP 序列和确认值

Posted 2023-03-23

【中文标题】TCP SYN 和 TCP RST 的 TCP 序列和确认值

【英文标题】：TCP sequence and ack values for TCP SYN and TCP RST

【发布时间】：2013-11-17 15:08:10

【问题描述】：

我正在发送几个 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 X.X.X.X.10104 > Y.Y.Y.10114：标志 [S]，seq 0，获胜 8192，长度 0 12:17:27.182008 IP Y.Y.Y.Y.10114 > X.X.X.X.10104：标志 [R.], seq 0, ack 1, win 0, length 0 12:17:27.683148 IP X.X.X.X.10104 > Y.Y.Y.Y.10114: Flags [S], seq 1, win 8192, length 0 12:17:27.683156 IP Y.Y.Y.Y.10114 > X.X.X.X.10104：标志 [R.]，seq 0，ack 2，win 0，长度 0 12:17:28.184140 IP X.X.X.X.10104 > Y.Y.Y.Y.10114：标志 [S]，seq 2， win 8192，长度 0 12:17:28.184147 IP Y.Y.Y.Y.10114 > X.X.X.X.10104: Flags [R.], seq 0, ack 3, win 0, length 0 12:17:28.684993 IP X.X.X.X.10104 > Y.Y.Y.Y.10114: Flags [S], seq 3, win 8192, length 0 12:17:28.685000 IP Y.Y.Y.Y.10114 > X.X.X.X.10104：标志 [R.]，seq 0， ack 4，赢0，长度0

另一方面，当我的

probes 以 seq > 1 开始

时，

first

rst 将具有

ack=syn_seq像往常一样 +1

， 但是接下来的 rst 将有

ack=2,3,4

... 而不管探针的序列值如何：

12:11:25.274636 IP X.X.X.X.59150 > Y.Y.Y.Y.59160：标志 [S]，seq 299，赢8192，长度0 12:11:25.274649 IP Y.Y.Y.Y.59160 > X.X.X.X.59150：标志 [R.]，seq 0，ack 300，win 0，长度 0 12:11:25.775218 IP X.X.X.X.59150 > Y.Y.Y.Y.59160：标志 [S]，seq 300，赢8192，长度0 12:11:25.775226 IP Y.Y.Y.Y.59160 > X.X.X.X.59150：标志 [R.]，seq 0，ack 2，win 0，长度 0 12:11:26.276324 IP X.X.X.X.59150 > Y.Y.Y.Y.59160：标志 [S]，seq 301，赢8192，长度0 12:11:26.276332 IP Y.Y.Y.Y.59160 > X.X.X.X.59150：标志 [R.]，seq 0，ack 3，win 0，长度 0 12:11:26.776940 IP X.X.X.X.59150 > Y.Y.Y.Y.59160：标志 [S]，seq 302，赢8192，长度0 12:11:26.776948 IP Y.Y.Y.Y.59160 > X.X.X.X.59150：标志 [R.]，seq 0，ack 4，win 0，长度 0

这是预期的行为吗？

【参考方案1】：

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

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

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

确认号设置为1，表示收到了客户端的SYN标志包。

现在谈谈你的情况：

序列号有双重作用：

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

如果 SYN 标志清零（0），那么这是累加序列 当前会话的此段的第一个数据字节的编号。

从Wikipedia复制的块引用部分。

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

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

【讨论】：

感谢您的回复。不过，您并没有让我相信 SYN 标志。您可以从我从tcpdump 复制和粘贴的摘录中看到，我的探测都是 SYN 数据包。例如：12:11:26.776940 IP X.X.X.X.59150 > Y.Y.Y.Y.59160: Flags [S], seq 302, win 8192, length 0

【参考方案2】：

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

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