tcpdump中部分TCP报文未显示序列号的原因及配置方法

这是tcpdump的默认显示逻辑，不是抓包漏了字段，也不需要额外抓包参数，只要调整显示参数就能看到你要的原始序列号。
tcpdump默认会对已完成三次握手的TCP流启用相对序列号显示：把报文里的32位绝对序列号，减去对应方向TCP连接的初始序列号（ISN）之后再打印，目的是降低阅读成本，不用手动计算报文携带的数据偏移量。
你看到的显示差异是切换显示规则的正常表现：

• 三次握手阶段的SYN、SYN+ACK包，因为还没完成连接建立、没确定双方初始序列号，tcpdump会直接打印报文里携带的原始绝对序列号，就是你看到的1870296365、3099403233这类大数字
• 握手完成后的纯ACK报文（也就是你说的Flags [.]类型）本身不携带应用层载荷、长度为0，相对初始序列号的偏移是1，所以显示seq 1完全符合逻辑；后续带载荷的PUSH报文显示seq 1:18、seq 1:35，对应17字节、34字节的载荷长度，和抓包里的length字段完全匹配，后续ACK报文的seq值随对端接收的数据长度涨到18、35，都是相对序列号的正常计算结果。

Wireshark默认也使用相对序列号显示，你觉得它显示“正常”，一般是手动开启了绝对序列号显示选项，才和tcpdump的默认输出有差异。

如果需要查看所有TCP报文首部自带的原始32位绝对序列号，启动tcpdump时加上大写的-S参数（对应长参数--absolute-tcp-sequence-numbers）即可，修改后的抓包命令为：

sudo tcpdump -vvvnS -i lo0 port 6378

加上该参数后，无论报文是什么Flags类型，tcpdump都会直接打印报文头中存储的原始Sequence Number值，不会再做相对偏移转换。

内容的提问来源于stack exchange，提问作者Willis