FIN 重传是什么
FIN 标志同样占用一个序号，属于需要被对端确认的报文段；一旦对端不回应，本端就会按重传超时（RTO）反复重发。抓包判据是：同一方向上出现两个及以上携带 FIN 标志、且序号相同的报文段。常见成因有三种：对端进程已崩溃或被强制结束，不再回应任何报文；路径丢包，确认报文没能回来；NAT 或防火墙提前清掉了会话表项，导致 FIN 被丢弃。它不影响已传输数据的完整性，但会显著拖长连接释放时间并让端口状态长时间无法回收。
基本信息
| 协议依据 | RFC 9293（TCP 连接释放） |
|---|---|
| 判据 | 同一方向、相同序号的 FIN 报文重复出现 |
| 过滤条件 | tcp.flags.fin == 1 && tcp.analysis.retransmission |
| 重传间隔 | 通常呈 RTO 退避，逐次翻倍 |
| 影响面 | 关闭变慢、端口与文件描述符回收滞后 |
典型使用场景
- 排查连接释放慢：业务观察到连接数迟迟不下降时，先看 FIN 是否在重传
- 推断对端异常：对端进程崩溃或被强杀之后不会确认 FIN，属半开连接的典型形态
- 与 TIME_WAIT 区分：TIME_WAIT 是本端主动关闭后的正常状态，FIN 重传则说明对端没回应对
- 验证中间设备：NAT 或防火墙提前清理会话时，会出现单向 FIN 无人应答
- 质量统计：把 FIN 重传纳入连接释放阶段的健康指标
过滤与观察
过滤与观察
tcp.flags.fin == 1 && tcp.analysis.retransmission # 关闭阶段重传
tcp.stream == N && tcp.flags.fin == 1 # 指定流的所有 FIN
tcp.analysis.retransmission && tcp.len == 0 # 只看重传且无数据的分段
# 核对重传间隔是否按超时退避逐次翻倍成因对照
| 成因 | 抓包表现 | 进一步验证 |
|---|---|---|
| 对端进程消失 | 单向 FIN 反复重发，全程无对端报文 | 核对对端进程与系统日志 |
| 路径丢包 | FIN 重传同时伴有数据重传与重复确认 | 看同流其他方向是否也在丢 |
| NAT 会话提前老化 | FIN 发出后无响应，随后新建连接正常 | 对比设备会话老化时间 |
重传间隔接近 RTO 且逐次翻倍，是超时重传的特征；如果同样的 FIN 帧以极短间隔出现两次，先确认抓包点位是否单一，多抓包点镜像同一会话会产生重复帧。