TCP 保持活动和空闲超时 PCAP 分析:防火墙、NAT、负载均衡器和长期连接

长期 TCP 连接可能会在几分钟或几小时不活动后失败。 SSH 会话冻结。数据库连接重置。 WebSocket 连接丢失。 RTSP TCP 交错流在空闲期后停止。 API 客户端看到管道损坏。用户搜索“TCP keepalive pcap”、“防火墙空闲超时”、“NAT 会话超时”、“负载均衡器重置空闲连接”和“长期 TCP 连接丢失”，因为应用程序错误通常在真正的超时决策很久之后才出现。

PCAP 手术很有用，因为空闲超时调查取决于时间。您需要最后一个真实数据包、任何 TCP keepalive 探测、ACK、FIN/RST 数据包以及确切的空闲持续时间。

TCP keepalive是什么

TCP keepalive 是一种可选机制，它在空闲连接上发送小型探测以检查对等方是否仍然可达。如果探测发生的频率高于中间盒超时，它还可以使 NAT 和防火墙状态保持活动状态。

但对于现代基础设施来说，违约往往太慢。防火墙可能会在 60 秒后终止空闲状态，而操作系统 TCP 保持连接可能会晚得多。

空闲超时症状

常见症状包括：

• 连接正常，然后在固定的空闲时间后失败。
• 空闲后的第一个请求被重置。
• WebSocket 在 60 秒后断开连接。
• 数据库池有过时的连接。
• SSH 通过 NAT 冻结。
• 负载均衡器在超时后发送 RST。
• 客户端空闲后发送数据，没有收到任何响应。

确切的时间就是线索。

FIN、RST、静默丢弃

中间件和端点可以通过不同的方式关闭空闲连接：

• FIN：优雅的关闭。
• RST：失败关闭。
• 静默丢包：无数据包；稍后的流量将被忽略。

如果防火墙默默地丢弃状态，则两个端点可能会认为连接仍然存在。下一个数据包会触发重传或重置行为。

保活证据

在跟踪中，查找空闲期间的小数据包。 TCP 保活探测通常在下一个预期字节之前使用序列号。分析器可能会将它们标记为保持活动。

问题：

• keepalive 是否已发送？
• 多常？
• 对等方是否确认了它们？
• 保活后中间件是否重置？
• 调查开始得太晚了吗？
• 连接是否在保持活动间隔之前断开？

负载均衡器和代理

负载均衡器通常强制执行空闲超时。如果客户端期望连接能够存活 30 分钟，但负载均衡器在 60 秒后关闭空闲连接，则应用程序必须发送心跳或重新连接。

数据包证据可以显示谁发送了关闭或重置以及上次数据发送后的时间。

Checklist

使用此工作流程：

1. 识别长期 TCP 连接。
2. 标记最后一个应用程序数据包。
3. 测量故障前的空闲时间。
4. 寻找 TCP keepalive 探测。
5. 检查探测是否已 ACK。
6. 识别 FIN 或 RST 发送方。
7. 如果没有出现关闭，请查找静默丢弃和重传。
8. 将超时与防火墙/负载平衡器设置进行比较。
9. 修剪时要注意时机。
10. 与应用程序心跳关联。

最终诊断

TCP 空闲故障是时序问题。数据包证据可以区分端点关闭、防火墙/NAT 状态到期、负载均衡器超时、丢失保活、保活过慢和静默丢弃。

PCAP 手术有助于保留空闲间隔和关闭/重置证据，因此可以准确解释长期连接故障。