为什么确认号减少到 1?
Why was the ack number decreased to 1?
我正在尝试获取 TCP。来自 TCP RFC 793 服务器和客户端 select 一个随机序列号,并且在每次收到新字节时增加它(这是错误的,但仅作为示例)。要转储 TCP 包,我使用 tcpdump -n -i eth0 tcp
:
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
04:32:20.732914 IP 10.10.0.2.43168 > 10.50.0.2.9: S 372254521:372254521(0)
win 5840 <mss 1460,sackOK,timestamp 3644068 0,nop,wscale 1>
04:32:20.766194 IP 10.50.0.2.9 > 10.10.0.2.43168: S 363863555:363863555(0)
ack 372254522 win 5792 <mss 536,sackOK,timestamp 3644074 3644068,nop,wscale 1>
04:32:20.766416 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 1 win 2920 <nop,nop,timestamp 3644073 3644074>
04:32:25.502532 IP 10.10.0.2.43168 > 10.50.0.2.9: P 1:7(6)
ack 1 win 2920 <nop,nop,timestamp 3644548 3644074>
04:32:25.503272 IP 10.50.0.2.9 > 10.10.0.2.43168: .
ack 7 win 2896 <nop,nop,timestamp 3644548 3644548>
04:32:29.510131 IP 10.10.0.2.43168 > 10.50.0.2.9: F 7:7(0)
ack 1 win 2920 <nop,nop,timestamp 3644949 3644548>
04:32:29.513123 IP 10.50.0.2.9 > 10.10.0.2.43168: F 1:1(0)
ack 8 win 2896 <nop,nop,timestamp 3644949 3644949>
04:32:29.513356 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 2 win 2920 <nop,nop,timestamp 3644949 3644949>
前两个包看起来正常,但从第三个开始,依此类推,它使用 ack 1
而不是 363863556
,我无法理解 为什么?
还没有。你是运行tcpdump
却没有告诉它你想看绝对序号(-S
).
tcpdump
的默认行为是将序列号转换为相对 序列号,这样您就可以看到在任一方向上传输了多少字节的数据。在这种特定情况下,您会看到它变为 1,因为根据 RFC-793,SYN 在流中消耗一个字节,因此正确的响应是 SEQ+1。你会看到同样的事情发生在另一个方向。 (您还会发现 FIN 占用一个字节)。在此之后,ACK 将增加发送的字节数。
如果想看绝对序号,再试一次运行tcpdump -n -i eth0 -S tcp
我正在尝试获取 TCP。来自 TCP RFC 793 服务器和客户端 select 一个随机序列号,并且在每次收到新字节时增加它(这是错误的,但仅作为示例)。要转储 TCP 包,我使用 tcpdump -n -i eth0 tcp
:
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
04:32:20.732914 IP 10.10.0.2.43168 > 10.50.0.2.9: S 372254521:372254521(0)
win 5840 <mss 1460,sackOK,timestamp 3644068 0,nop,wscale 1>
04:32:20.766194 IP 10.50.0.2.9 > 10.10.0.2.43168: S 363863555:363863555(0)
ack 372254522 win 5792 <mss 536,sackOK,timestamp 3644074 3644068,nop,wscale 1>
04:32:20.766416 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 1 win 2920 <nop,nop,timestamp 3644073 3644074>
04:32:25.502532 IP 10.10.0.2.43168 > 10.50.0.2.9: P 1:7(6)
ack 1 win 2920 <nop,nop,timestamp 3644548 3644074>
04:32:25.503272 IP 10.50.0.2.9 > 10.10.0.2.43168: .
ack 7 win 2896 <nop,nop,timestamp 3644548 3644548>
04:32:29.510131 IP 10.10.0.2.43168 > 10.50.0.2.9: F 7:7(0)
ack 1 win 2920 <nop,nop,timestamp 3644949 3644548>
04:32:29.513123 IP 10.50.0.2.9 > 10.10.0.2.43168: F 1:1(0)
ack 8 win 2896 <nop,nop,timestamp 3644949 3644949>
04:32:29.513356 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 2 win 2920 <nop,nop,timestamp 3644949 3644949>
前两个包看起来正常,但从第三个开始,依此类推,它使用 ack 1
而不是 363863556
,我无法理解 为什么?
还没有。你是运行tcpdump
却没有告诉它你想看绝对序号(-S
).
tcpdump
的默认行为是将序列号转换为相对 序列号,这样您就可以看到在任一方向上传输了多少字节的数据。在这种特定情况下,您会看到它变为 1,因为根据 RFC-793,SYN 在流中消耗一个字节,因此正确的响应是 SEQ+1。你会看到同样的事情发生在另一个方向。 (您还会发现 FIN 占用一个字节)。在此之后,ACK 将增加发送的字节数。
如果想看绝对序号,再试一次运行tcpdump -n -i eth0 -S tcp