Tcp 为什么确认号减少到1?

Tcp 为什么确认号减少到1?,tcp,tcpdump,Tcp,Tcpdump,我正在尝试获取TCP。从TCP RFC 793服务器和客户端选择一个随机序列号,然后在每次接收到新字节时增加该序列号(这是错误的,但仅举个例子)。为了转储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:3722545

我正在尝试获取TCP。从TCP RFC 793服务器和客户端选择一个随机序列号,然后在每次接收到新字节时增加该序列号(这是错误的,但仅举个例子)。为了转储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>
在eth0上侦听,链路类型为EN10MB(以太网),捕获大小为96字节
04:32:20.732914 IP 10.10.0.2.43168>10.50.0.2.9:S 372254521:372254521(0)
赢5840
04:32:20.766194 IP 10.50.0.2.9>10.10.0.2.43168:S 363863555:363863555(0)
阿克372254522胜5792
04:32:20.766416 IP 10.10.0.2.43168>10.50.0.2.9:。
阿克1胜2920
04:32:25.502532 IP 10.10.0.2.43168>10.50.0.2.9:P1:7(6)
阿克1胜2920
04:32:25.503272 IP 10.50.0.2.9>10.10.0.2.43168:。
ack 7胜2896
04:32:29.510131 IP 10.10.0.2.43168>10.50.0.2.9:F 7:7(0)
阿克1胜2920
04:32:29.513123 IP 10.50.0.2.9>10.10.0.2.43168:F 1:1(0)
ack 8胜2896
04:32:29.513356 IP 10.10.0.2.43168>10.50.0.2.9:。
阿克2胜2920

前两个包看起来正常,但从第三个包开始,以此类推,它使用了
ack1
而不是
363863556
,我无法了解为什么?它没有。您正在运行
tcpdump
,但没有告诉它您想要查看绝对序列号(
-S

tcpdump
的默认行为是将序列号转换为相对序列号,这样可以查看在任一方向上传输了多少字节的数据。在这个特定的例子中,您看到它变为1,因为根据RFC-793,SYN消耗流中的一个字节,所以正确的响应是SEQ+1。你会看到同样的事情发生在另一个方向。(您还会发现FIN消耗一个字节)。此后,ACK将增加发送的字节数

如果要查看绝对序列号,请再次尝试运行
tcpdump-n-i eth0-S tcp