为什么 tcpdump 的输出与三次握手的定义不同答案

【问题标题】：why the outputs of tcpdump behaves defferent from three times handshake's definition为什么 tcpdump 的输出与三次握手的定义不同
【发布时间】：2017-01-23 07:56:42
【问题描述】：

我使用 tcpdump 和 telnet 在 mac os 上运行了 tcp 的连接测试。这是我的命令：

telnet localhost 3000
tcpdump -i lo0 port 3000

结果如下：

16:44:23.751241 IP6 localhost.59405 > localhost.hbci: Flags [S], seq 396289691, win 65535, options [mss 16324,nop,wscale 5,nop,nop,TS val 896927289 ecr 0,sackOK,eol], length 0
16:44:23.751315 IP6 localhost.hbci > localhost.59405: Flags [S.], seq 588037038, ack 396289692, win 65535, options [mss 16324,nop,wscale 5,nop,nop,TS val 896927289 ecr 896927289,sackOK,eol], length 0
16:44:23.751331 IP6 localhost.59405 > localhost.hbci: Flags [.], ack 1, win 12743, options [nop,nop,TS val 896927289 ecr 896927289], length 0
16:44:23.751345 IP6 localhost.hbci > localhost.59405: Flags [.], ack 1, win 12743, options [nop,nop,TS val 896927289 ecr 896927289], length 0
16:44:53.758011 IP6 localhost.hbci > localhost.59405: Flags [F.], seq 1, ack 1, win 12743, options [nop,nop,TS val 896957275 ecr 896927289], length 0
16:44:53.758085 IP6 localhost.59405 > localhost.hbci: Flags [.], ack 2, win 12743, options [nop,nop,TS val 896957275 ecr 896957275], length 0
16:44:53.758101 IP6 localhost.hbci > localhost.59405: Flags [.], ack 1, win 12743, options [nop,nop,TS val 896957275 ecr 896957275], length 0
16:44:53.758188 IP6 localhost.59405 > localhost.hbci: Flags [F.], seq 1, ack 2, win 12743, options [nop,nop,TS val 896957275 ecr 896957275], length 0
16:44:53.758260 IP6 localhost.hbci > localhost.59405: Flags [.], ack 2, win 12743, options [nop,nop,TS val 896957275 ecr 896957275], length 0

第三行的ack值是1而不是588037039，为什么？

【问题讨论】：

标签： linux macos tcp tcpdump

【解决方案1】：

来自

http://linux.die.net/man/8/tcpdump

ack 序列号是一个小整数 (1)。第一次 tcpdump 看到一个 tcp 'conversation'，它打印从数据包。在对话的后续数据包中，差异在当前数据包的序列号和这个初始序列之间号码被打印出来。这意味着第一个之后的序列号可以解释为对话中的相对字节位置数据流（每个方向的第一个数据字节为“1”）。 '-S' 将覆盖此功能，导致原始序列号输出。

【讨论】：