3. 识别重传包：Wireshark中的标记与时间间隔
抓包文件拿到手，第一件事是什么？我个人习惯先看有没有重传。重传是TCP最直接的“求救信号”——它告诉你网络出问题了。但Wireshark怎么帮你找到这些信号？这一节我们把它说透。
3.1 Wireshark如何标记重传包
Wireshark对重传的识别，说白了就是靠一套启发式规则。它不只看序列号，还会结合时间、负载、窗口变化来判断。你打开一个抓包文件，在Packet List面板里，重传包会被标上黑色背景、白色文字——嗯，一眼就能认出来。
核心标记字段：
- [TCP Retransmission] — 显式标记在Info列，告诉你这是重传
- [TCP Fast Retransmission] — 快速重传，收到3个重复ACK后触发
- [TCP Spurious Retransmission] — 虚假重传，实际上对方已经收到了
- [TCP Retransmission (RTO)] — 超时重传，RTO计时器到期触发
我记得有一次排查一个数据库同步延迟问题，抓了半小时的包，愣是没找到重传。后来才发现——Wireshark默认只显示可见包的重传标记，如果重传发生在“已丢失”的包之后，标记可能不准确。所以我的习惯是：先看Expert Info，再回查原始包。
3.2 Expert Info分析：重传的“诊断报告”
Wireshark的Expert Info（分析 → Expert Info）就像一份自动生成的诊断报告。它会按严重程度把事件分类：Errors、Warnings、Notes、Chats。重传通常出现在Warnings或Notes里。
打开Expert Info窗口，你会看到类似这样的条目：
+ TCP Retransmission (3)
- 192.168.1.10 → 10.0.0.1 Seq=1001 Len=1460 [RTO]
- 192.168.1.10 → 10.0.0.1 Seq=1001 Len=1460 [Fast Retransmission]
- 192.168.1.10 → 10.0.0.1 Seq=2461 Len=1460 [RTO]这里有个坑——我曾经遇到过Expert Info里报了20多次重传，但实际只有3个原始包被重传。为什么？因为同一个包可能被重传多次，每次都会生成一条记录。所以看Expert Info时，要关注的是“哪些序列号被重传”，而不是“重传事件总数”。
我的小技巧：
在Expert Info里右键点击一条重传记录，选择“Prepare as Filter → Selected”，然后应用过滤。这样你就能只看这个序列号相关的所有包——包括原始发送、重传、ACK——完整还原一次重传的“故事”。
3.3 重传时间间隔的观察
重传的时间间隔，是判断网络问题类型的关键线索。TCP的重传间隔不是固定的——它遵循指数退避（Exponential Backoff）。第一次重传等RTO（比如200ms），第二次等400ms，第三次800ms……直到达到上限。
怎么在Wireshark里看这个间隔？我教你一个方法：
- 找到原始发送包和它的第一次重传包
- 在Packet List里添加“Time since previous frame in this TCP stream”列（或者直接用“Delta time”列）
- 计算两个包的时间差
举个例子，下面是我从一个真实案例中提取的数据：
| 包序号 | 时间戳 | Delta时间 | 事件 |
|---|---|---|---|
| #101 | 0.000 | — | 原始发送 (Seq=5001) |
| #102 | 0.210 | 210ms | 第一次重传 (RTO≈200ms) |
| #103 | 0.625 | 415ms | 第二次重传 (RTO≈400ms) |
| #104 | 1.430 | 805ms | 第三次重传 (RTO≈800ms) |
看到规律了吗？间隔几乎翻倍。这就是典型的超时重传。如果间隔很短（比如3ms、5ms），那很可能是快速重传——收到重复ACK后立即触发，不等RTO。
注意：有些情况下，重传间隔看起来是“随机”的，不遵循指数退避。这通常意味着：
- 中间设备（如负载均衡器）在干预TCP流
- 发送端使用了非标准TCP栈（比如某些嵌入式设备）
- 存在多路径传输，不同路径的延迟差异导致重传时间混乱
遇到这种情况，别急着下结论——先确认抓包点是否在发送端附近。
3.4 重传类型速查表
为了方便你快速判断，我整理了一张表：
| 重传类型 | 触发条件 | 时间间隔特征 | Wireshark标记 |
|---|---|---|---|
| 超时重传 (RTO) | RTO计时器到期，未收到ACK | 指数退避（翻倍增长） | [TCP Retransmission] |
| 快速重传 | 收到3个重复ACK | 极短（通常<10ms） | [TCP Fast Retransmission] |
| 虚假重传 | 发送端误判丢包 | 与RTO或快速重传类似 | [TCP Spurious Retransmission] |
| 选择性重传 (SACK) | 收到SACK选项，只重传丢失段 | 取决于触发机制 | 无独立标记，需看SACK选项 |
3.5 一张图看懂重传识别流程
下面这张SVG图，把整个识别过程串起来了——从抓包到定位问题类型，每一步该看什么，一目了然。
3.6 实战：一个重传包的完整分析
最后，我带你走一遍实际分析过程。假设你看到这样一个包：
Frame 123: 1514 bytes on wire (12112 bits)
Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: 00:1a:2b:3c:4d:5f
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 10.0.0.1
Transmission Control Protocol, Src Port: 443, Dst Port: 50001, Seq: 1001, Ack: 1, Len: 1460
[TCP Retransmission] [Expert Info (Warning/Retransmission)]
[TCP Analysis Flags]
[Retransmission: True]
[Time since first frame in this TCP stream: 0.210000 seconds]
[Time since previous frame in this TCP stream: 0.210000 seconds]我的分析步骤：
- 看标记：Info列显示[TCP Retransmission]，没有“Fast”字样——说明是超时重传
- 看时间：距离上一个包210ms，符合初始RTO（通常200ms左右）
- 看序列号：Seq=1001，Len=1460，说明重传的是原始数据段
- 看上下文：过滤这个TCP流，检查原始包是否在之前发送过，以及对方是否回复了ACK
我曾经遇到过一个案例，重传间隔只有1ms——明显不是正常的RTO。后来发现是客户端的TCP卸载引擎（TOE）有bug，把正常包当成了重传。所以记住：Wireshark的标记是参考，不是真理。最终判断还是要靠你对整个流的理解。