tcpdump抓MySQL/PostgreSQL三次握手和RST需用-i eth0 -nn -S -w mysql.pcap 'tcp port 3306 and (tcp[12] & 0xf0 > 0x20 or tcp[tcpflags] & (tcp-syn|tcp-rst))'，并配合host过滤或显式捕获RST，结合时间戳与pcap中SYN超时、ACK后立即RST、空闲超时RST等模式判断是否网络抖动所致。
tcpdump 怎么抓到 MySQL/PostgreSQL 的 TCP 三次握手和 RST 报文
要定位 Broken Pipe 是否由网络抖动引发，关键不是抓应用层 SQL，而是确认连接是否在建立或空闲时被中间设备（如 LB、防火墙、NAT 网关）异常中断。这需要捕获完整的 TCP 生命周期：SYN → SYN-ACK → ACK → （可选数据）→ FIN/RST。
直接用 tcpdump -i any port 3306 很可能漏掉关键帧——比如 SYN 包被丢弃、SYN-ACK 没回来、或者服务端发了 RST 但没被过滤出来。
- 必须加
-S（显示绝对序列号），否则无法判断重传或乱序 - 必须加
-nn（禁用域名和端口解析），避免 DNS 查询阻塞或延迟影响抓包实时性 - 推荐加
-w capture.pcap保存原始包，而不是仅靠-v实时打印——RST 和重传往往一闪而过 - 若目标是复现“连接刚建好就 Broken Pipe”，需在客户端执行前立刻启停抓包：
tcpdump -i eth0 -nn -S -w mysql-handshake.pcap 'tcp port 3306 and (tcp[12] & 0xf0 > 0x20 or tcp[tcpflags] & (tcp-syn|tcp-rst))'
为什么只过滤 port 3306 还会漏掉 RST？
很多情况下，Broken Pipe 不是数据库主动断开，而是连接中途被中间设备 reset。这类 RST 报文源端口往往不是 3306（比如来自负载均衡器的 1024–65535 随机端口），目的端口才是你的客户端本地端口。
单纯写 port 3306 会过滤掉这些“反向 RST”。正确做法是绑定五元组或使用更宽松的匹配：
- 用
host 192.168.1.100 and port 3306（替换为 DB IP）比port 3306更可靠 - 若客户端 IP 动态变化，改用
tcp[tcpflags] & (tcp-rst) != 0显式抓所有 RST，再用 Wireshark 筛选流向 DB 的流 - 注意：Linux 内核可能对 loopback 流量走不同路径，
-i lo和-i eth0抓到的包可能不一致；本地直连 DB 时务必指定-i lo
怎么从 pcap 判断是网络抖动而非数据库拒绝
打开 capture.pcap 后，重点看三类模式：
-
Syn发出后超过 1s 没收到Syn+Ack→ 可能 SYN 丢包或防火墙拦截（非抖动，是连通性问题） - 完成三次握手后，
Ack之后立刻出现Rst（且 Seq = Ack of previous packet）→ 中间设备强制中断，典型抖动表现 - 长时间空闲连接（比如 30s+ 无任何数据包），突然收到
Rst→ 很可能是 NAT 超时或云厂商 SLB 的 idle timeout（默认常为 60s），不是瞬时抖动，但也会触发Broken Pipe - 对比客户端日志里的报错时间戳与 pcap 中最后一个有效包时间差 —— 若差值在 100ms 内，基本可排除应用层超时，指向网络层丢包
抓包时容易忽略的两个硬限制
tcpdump 本身不丢包，但系统内核缓冲区和网卡 ring buffer 会。高并发建连场景下，Broken Pipe 可能发生在你还没来得及启动 tcpdump 的瞬间。
- 不要依赖
systemctl start tcpdump或手动敲命令——提前用nohup tcpdump -i eth0 -G 300 -w /tmp/cap_%Y-%m-%d_%H:%M:%S.pcap -W 10 ... &循环写入，保留最近 50 分钟历史 - 确认
/proc/sys/net/core/rmem_max≥ 4MB；太小会导致内核丢包，即使 tcpdump 进程在跑也看不到真实 RST
真正难的是把一次 Broken Pipe 对应到某次 SYN 失败或某条 RST，而不是看到一堆包就下结论。时间戳对齐、接口选择、缓冲区大小，这三个点没调好，抓出来的 pcap 就是废片。
