tcpdump 解析 TCP 三次握手阶段的标志位包

tcpdump抓包分析TCP三次握手的关键是验证标志位组合与seq/ack数值逻辑：第一次Flags[S]、seq=x、ack=0；第二次Flags[S.]、seq=y、ack=x+1；第三次Flags[.]、seq=x+1、ack=y+1，全部吻合即确认握手成功。

用 tcpdump 抓包观察 TCP 三次握手，关键不是看“有没有三个包”，而是看每个包里 TCP 标志位 和 seq/ack 数值 的变化逻辑。只要标志位组合和序号递进符合规范，就能确认握手是否正常完成。

如何用 tcpdump 捕获三次握手包

执行以下命令可捕获目标主机的 TCP 连接建立过程（以访问 80 端口为例）：

• tcpdump -i any -nn -vv -S 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 80' —— 只抓带 SYN 或 ACK 标志的包，-S 显示绝对序列号，避免 Wireshark 那种相对值干扰判断
• 若已知目标 IP（如 192.168.1.100），可加过滤：host 192.168.1.100 and port 80
• 为防止丢包影响分析，建议同时加 -s 0（全包捕获）和 -w handshake.pcap（保存文件供后续 inspect）

三次握手各阶段的标志位与 seq/ack 规律

每轮握手对应一个 TCP 数据段，其标志位和序号必须满足如下组合：

• 第一次握手（SYN）：客户端发包 → Flags [S]（即 SYN=1, ACK=0），seq = x（随机初始序号），ack = 0（未确认任何数据）
• 第二次握手（SYN+ACK）：服务端回包 → Flags [S.]（SYN=1, ACK=1），seq = y（服务端随机选），ack = x+1（确认收到客户端的 SYN）
• 第三次握手（ACK）：客户端再回 → Flags [.]（SYN=0, ACK=1），seq = x+1（延续上一个 SYN 的序号+1），ack = y+1（确认收到服务端的 SYN）

注意：实际 tcpdump 输出中，“Flags [S]”、“Flags [S.]”、“Flags [.]”就是上述三种状态的简写；点号（.）代表 ACK=1，S 代表 SYN=1，F 代表 FIN=1，R 代表 RST=1。

从 tcpdump 输出识别握手是否成功

典型成功握手的三行输出类似如下（已简化）：

• 10.0.0.5.54321 > 10.0.0.10.80: Flags [S], seq 123456789, win 64240
• 10.0.0.10.80 > 10.0.0.5.54321: Flags [S.], seq 987654321, ack 123456790, win 65535
• 10.0.0.5.54321 > 10.0.0.10.80: Flags [.], seq 123456790, ack 987654322, win 64239

验证要点：
– 第二包 ack 值 = 第一包 seq + 1
– 第三包 seq 值 = 第一包 seq + 1（因 SYN 占 1 字节序号）
– 第三包 ack 值 = 第二包 seq + 1
全部吻合，说明三次握手完整且无重传或乱序。

常见异常情况及 tcpdump 表现

并非所有带 SYN 的包都构成有效握手，需警惕以下情形：

• SYN 重传：同一客户端连续发出多个 Flags [S]，seq 不同（如 123456789、123456790…），说明第一包未被响应，网络可能丢包或服务端未监听
• RST 中断：客户端发 SYN 后，服务端直接回 Flags [R.]（RST+ACK），常见于端口未开放或防火墙拦截
• 半开连接：只有前两个包（SYN → SYN+ACK），无第三包 ACK，可能是客户端崩溃、中间设备丢包，或存在 SYN Flood 攻击痕迹
• ACK 被拒：第三包发出后，服务端回 RST，说明服务端已超时关闭半连接（如 net.ipv4.tcp_synack_retries 耗尽）