3、重传特征分析：快速重传与超时重传、重复ACK识别、重传模式判断

重传是TCP保证可靠性的最后一道防线。但重传本身也分好几种，每种背后反映的问题都不一样。我见过不少运维同事，一看到抓包里有重传就慌了，其实没必要——你得先分清楚是哪种重传，才能对症下药。

这一节，我们就来拆解重传的几种特征。说白了，就是教你怎么从抓包文件里一眼看出：这是快速重传？还是超时重传？重复ACK长什么样？以及当前属于哪种重传模式。

先讲最核心的概念。TCP重传分两大类：快速重传（Fast Retransmit）和超时重传（Timeout Retransmit）。它们触发的条件完全不同。

核心判断原则：快速重传说明网络还能“对话”，只是丢了包；超时重传说明网络可能已经“断联”了。严重程度完全不是一个级别。

我在项目里遇到过一种情况：某业务频繁出现超时重传，但链路监控显示带宽利用率只有30%。后来发现是中间防火墙的会话超时时间设得太短，导致长连接被静默切断。嗯，这种问题光看带宽是看不出来的。

重复ACK是快速重传的前兆信号。你想想看，接收端收到乱序包时，不会立刻确认新数据，而是重复发送上一个已确认的序号。这就是重复ACK。

在Wireshark里识别重复ACK很简单：

我的经验：别看到重复ACK就喊丢包。如果重复ACK只有1-2个，而且后续很快收到了正确的ACK，那大概率是乱序。我曾经在一个跨国链路上看到大量重复ACK，结果发现是两条路径延迟差异太大导致的——根本不是丢包。

重复ACK的个数很关键。我习惯这样判断：

实际抓包中，重传不会孤立出现。它们会形成特定的模式。我总结了三种最常见的重传模式，你可以对照判断。

特征：连续重复ACK → 快速重传 → 恢复。整个过程通常在几十毫秒内完成。

典型场景：网络轻微丢包，但延迟正常。比如无线网络偶尔的干扰。

特征：长时间无响应 → RTO到期 → 重传 → 继续无响应 → RTO翻倍 → 再次重传。RTO会指数退避（1s、2s、4s、8s...）。

典型场景：链路中断、对端宕机、防火墙拦截。

特征：先出现快速重传，但未能恢复，最终演变为超时重传。或者超时重传后，又出现快速重传。

典型场景：网络严重拥塞，丢包率持续升高。

避坑指南：我曾经遇到一个案例，抓包显示大量快速重传，但业务方坚持说网络没问题。后来发现是发送端的发送缓冲区太小，导致数据包在本地就被丢弃了——根本不是网络丢包。所以，重传不一定等于网络丢包，也可能是端侧问题。

下面这张图把重传特征分析的核心逻辑串起来了。你可以把它当作排查时的路线图。

光讲理论不够，我们来点实际的。假设你拿到一个pcap文件，怎么快速判断重传模式？

第一步：过滤重传包

tcp.analysis.retransmission || tcp.analysis.fast_retransmit

第二步：看时间间隔
- 如果重传包之间的间隔很短（几毫秒到几十毫秒），且前面有重复ACK → 快速重传
- 如果重传包之间的间隔很长（几百毫秒到几秒），且呈指数增长 → 超时重传
第三步：看重复ACK数量
```
tcp.analysis.duplicate_ack
```
统计每个重复ACK出现的次数。3个以上且紧跟着重传，就是快速重传。
第四步：综合判断模式
- 只有快速重传 → 模式一
- 只有超时重传 → 模式二
- 两者都有 → 模式三

我的习惯：我一般会先用Wireshark的“Expert Info”功能扫一遍。它会自动标记重传类型。但别完全依赖它——有时候Expert Info会把乱序误判为重传。我建议还是手动确认一下重复ACK的上下文。

最后，把我这些年踩过的坑总结一下：