排查应用层超时需结合tcpdump抓包分析TCP各阶段行为：连接建立失败、请求未发出、响应延迟或连接中断；通过过滤特定IP端口、标志位及时间戳定位卡点，并辅以ss、netstat等命令验证系统状态。
排查应用层超时错误，不能只看“超时”字面意思，而要从 TCP 连接行为反推——比如连接建立失败、请求发不出去、响应迟迟不来、连接被意外中断。tcpdump 的作用是把整个通信链路的原始数据包“摊开来看”，结合时间戳和标志位，定位卡点在哪一环。
抓关键流量：限定协议、IP 和端口
超时问题往往集中在特定服务，先缩小范围：
- 只抓目标服务的 TCP 流量（避免混杂干扰）：sudo tcpdump -i any 'tcp and host 192.168.1.100 and port 8080' -nn -tttt -c 100
- 若服务走 HTTPS，明确写 dst port：sudo tcpdump -i ens33 'tcp and dst host 10.0.2.15 and dst port 443' -nn -tttt -s 0
- -s 0 确保不截断 payload，方便后续查 HTTP 状态码或 gRPC 错误信息
识别典型超时模式对应的数据包特征
不是所有超时都一样，不同阶段的超时在包里表现完全不同：
- 连接建立超时（connect timeout）：客户端发 SYN 后长时间没收到 SYN-ACK → 抓包中看到重复 SYN（重传），且无对应 SYN-ACK；可用 tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0 and src host 客户端IP' 单独过滤 SYN
- 读超时（read timeout）：请求已发出，但迟迟没响应 → 抓包中看到客户端发了完整 HTTP 请求（含 GET/POST + \r\n\r\n），之后数秒内无来自服务端的 ACK 或 DATA 包；可配合 -A 查看明文内容是否发全
- 写超时或连接中断：客户端发完请求后，服务端立刻回 RST → 出现 tcp[tcpflags] & (tcp-rst) != 0，且源 IP 是服务端，同时前一个包是客户端 FIN 或异常数据
用时间线和状态交叉验证
单看包不够，要结合系统状态确认是否是资源瓶颈导致的伪超时：
- 抓包同时运行：ss -tn state established '( dport = :8080 )' | wc -l，确认服务端真有活跃连接，排除“监听了但不收包”
- 检查连接堆积：ss -tn state time-wait | wc -l，若远超 3w，可能因 TIME_WAIT 耗尽端口，新连接 SYN 被丢弃
- 查内核重置统计：netstat -s | grep -A 2 -B 1 "segments retransmited\|resets"，高频 RST 或重传说明底层不稳定
- 确认进程是否存活：lsof -i :8080 或 systemctl is-active your-app
导出分析：配合 -w 和 Wireshark 深挖
复杂场景下命令行难定位，建议保存为 pcap 文件：
- sudo tcpdump -i any 'tcp and host 192.168.1.100 and port 8080' -nn -tttt -s 0 -w timeout-debug.pcap
- 用 Wireshark 打开，使用显示过滤器如 tcp.analysis.retransmission（标红重传）、http.response.code == 0（无响应）、tcp.len > 0 and tcp.flags.push == 1（带数据的 PSH 包）快速聚焦
- 右键某条流 → “Follow → TCP Stream”，直接查看完整会话明文，一眼判断是请求没到、响应没发、还是半截中断
