重传问题定位方法论：重传定位四步法
做网络抓包分析这么多年，我见过太多人在重传问题上绕圈子。抓了一大堆包，看着满屏的「TCP Retransmission」发懵，不知道从哪下手。其实说白了，重传定位没那么玄乎，关键是要有一套系统的方法。
我个人习惯把这套方法总结成四个步骤——基线建立、异常识别、根因分析、验证闭环。你想想看，这跟医生看病其实是一个道理：先知道正常人什么样，再找出哪里不对劲，然后查病因，最后开药方看效果。
核心观点：重传定位不是靠直觉，而是靠方法论。四步法帮你把模糊的「网络卡顿」变成可量化的「哪个环节、什么原因、怎么解决」。
第一步：基线建立——先知道「正常」长什么样
很多新手一上来就盯着重传包看，这是个大坑。你连正常网络长什么样都不知道，怎么判断异常？
我在项目中遇到过好几次这样的情况：客户说网络卡，我一看抓包文件，确实有重传。但仔细一查，这个业务场景下 0.1% 的重传率本来就是正常的。白忙活一场。
基线建立要做三件事：
- 确定正常重传率范围——不同业务不一样。视频流允许 1-2%，数据库同步要求 <0.1%，VoIP 基本不能有重传。
- 记录正常 RTT 基线——同机房通常 <1ms，同城 <10ms，跨省 20-50ms，跨国 100-300ms。
- 了解业务流量特征——是突发流量还是持续流量？大包多还是小包多？
| 业务类型 | 正常重传率 | 正常 RTT | 典型包大小 |
|---|---|---|---|
| Web 浏览 | <0.5% | <50ms | 混合（小包为主） |
| 视频流媒体 | <2% | <100ms | 大包（MTU 附近） |
| 数据库同步 | <0.1% | <10ms | 中等包 |
| VoIP | <0.05% | <30ms | 小包（通常 <200B） |
我的小技巧：基线数据最好在业务低峰期采集，连续采集 7 天取平均值。别只抓 5 分钟就下结论，那叫碰运气。
第二步：异常识别——找到「不对劲」的地方
基线有了，接下来就是对比。异常识别不是让你看单个重传包，而是看整体趋势。
我一般用 Wireshark 的 IO Graph 和 TCP Stream Graph 来做初步筛查。重点关注三个指标：
- 重传率突然飙升——从 0.1% 跳到 5% 以上，肯定有问题。
- RTT 剧烈波动——正常 10ms 突然变成 200ms，说明路径上出了状况。
- 重传集中在特定时间窗口——比如每 30 秒来一波，可能是周期性拥塞。
举个例子。有一次我排查一个电商平台的支付超时问题。基线显示正常重传率 0.2%，RTT 8ms。但抓包一看，每天晚上 8 点到 10 点，重传率飙到 4.7%，RTT 涨到 120ms。异常窗口非常明显——就是晚高峰。
注意：别把「乱序包」当成「重传包」。Wireshark 有时候会把乱序标记为重传，你得看 Sequence Number 和 TCP 时间戳来确认。我曾经就被这个坑过，查了半天发现是交换机负载均衡导致的乱序。
第三步：根因分析——揪出「元凶」
异常找到了，接下来就是查原因。重传的根因无非就这几类，我列个清单：
| 根因类别 | 典型表现 | 抓包特征 |
|---|---|---|
| 网络拥塞 | 重传率持续偏高，RTT 增大 | 多个流同时重传，窗口缩小 |
| 链路丢包 | 重传集中在某一段路径 | ICMP 不可达或 TTL 超时 |
| 接收端瓶颈 | 接收窗口经常为 0 | TCP Window Full / Zero Window |
| 发送端问题 | 重传间隔异常 | RTO 计算异常，重传超时时间不对 |
| 中间设备干扰 | 特定设备后出现重传 | TTL 变化，IP ID 不连续 |
怎么快速定位？我个人习惯用 分层排除法：
- 先看应用层——是不是业务逻辑导致的重传？（比如客户端超时设置太短）
- 再看传输层——TCP 参数有没有问题？（窗口、MSS、SACK 是否开启）
- 然后看网络层——路由有没有变化？MTU 是否匹配？
- 最后看链路层——物理链路有没有误码？
我曾经遇到过一个案例，重传率一直 3% 左右，查了三天。最后发现是服务器网卡的 TCP 卸载功能有 bug，导致校验和计算错误。你想想看，这种问题从抓包上看就是正常的重传，但实际上是硬件问题。所以别只盯着抓包数据，也要看看系统日志和硬件状态。
第四步：验证闭环——确认「修好了」
找到根因、做了修复之后，千万别以为就完事了。验证闭环这步，很多人会忽略。
我要求团队必须做三件事：
- 再次抓包对比——同样的业务场景、同样的时间段，重传率降下来了吗？RTT 恢复了吗？
- 持续监控 24 小时——别只看修复后 10 分钟的数据。有些问题有周期性，比如凌晨的批量任务。
- 更新基线数据——修复后的正常指标可能变了，把新数据纳入基线库。
闭环检查清单：
- 重传率是否回到基线范围内？
- RTT 是否稳定？
- 业务侧是否有投诉或告警？
- 修复措施是否引入新的问题？（比如调整了 TCP 参数后，其他业务受影响了吗？）
如果验证不通过，别硬撑。回到第一步，重新建立基线，重新识别异常。我见过最惨的案例是一个团队修了三次都没修好，就是因为每次修完只看 5 分钟就宣布「搞定」了。
避坑指南：我曾经犯过一个错误——修复后只抓了客户端到服务器的包，没抓中间链路的。结果客户端看没问题，但核心交换机上还在丢包。所以验证的时候，最好在多个节点同时抓包，确保整条路径都正常了。
四步法说起来简单，但真正用好需要积累。你每做完一次重传定位，就把基线数据、异常特征、根因分析过程记录下来。时间长了，你脑子里会形成一个「重传模式库」，看一眼抓包就能猜个八九不离十。嗯，这就是所谓的经验吧。