Question

我正在尝试获取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>

前两个程序包看起来正常，但是从第三个程序包开始，依此类推，它使用ack 1而不是363863556，我无法理解为什么？

Answer 1

还没有。您正在运行cinterop，而没有告诉您要查看绝对序列号（tcpdump）。

-S的默认行为是将序列号转换为相对序列号，这使您可以查看在任一方向上传输了多少字节的数据。在这种特定情况下，您会看到它变为1，因为根据RFC-793，SYN会在流中消耗一个字节，因此正确的响应为SEQ + 1。您将看到同一件事发生在另一个方向。（您还将发现FIN消耗了一个字节）。之后，ACK将增加发送的字节数。

如果要查看绝对序列号，请再次尝试运行tcpdump

为什么ack数量减少到1？

1 个答案: