Wireshark TCP: Retransmission vs Out-of-Order vs Loss

A capture full of red “TCP Retransmission” lines is the most over-interpreted artefact in network troubleshooting. Those labels are Wireshark’s interpretation of a single capture, written from one point in the path. Packet loss, reordering and capture drops look similar on screen and require completely different fixes. Here is how to tell them apart using sequence numbers, ACK progress and SACK blocks.

Sequence numbers are the source of truth

TCP is a byte stream. Every data byte has a sequence number, and every analysis question reduces to the relationship between sequence number, segment length, the ACK number coming back, SACK blocks and timestamps.

Sender -> Receiver: Seq 1000 Len 1000
Sender -> Receiver: Seq 3000 Len 1000
Sender -> Receiver: Seq 2000 Len 1000

If the segment starting at 2000 arrives soon after the one at 3000, this is reordering: TCP carries on without retransmission, and the fix is path-level (ECMP hashing, link aggregation, multi-path tunnels), not a server tuning issue. If the sender emits a second copy of 2000 after duplicate ACKs or an RTO, you observed a retransmission — and the original may still have been lost, delayed, or merely invisible to your capture point.

What the Wireshark flags actually mean

• tcp.analysis.retransmission — bytes were observed from the sender with a sequence range seen before. It does not prove loss.
• tcp.analysis.fast_retransmission — triggered by duplicate ACKs or a large jump, before the RTO expires. Normal recovery, not necessarily a problem.
• tcp.analysis.out_of_order — a later segment arrived before an earlier one, within the out-of-order RTT threshold.
• tcp.analysis.duplicate_ack — the receiver repeats the same ACK; strong evidence of a gap in what the receiver has.
• tcp.analysis.spurious_retransmission — the original data was already acknowledged; typically a delayed original segment.
• tcp.analysis.lost_segment / “previous segment not captured” — frequently means your capture missed a packet, not the network.

tcp.analysis.flags
tcp.analysis.retransmission || tcp.analysis.fast_retransmission
tcp.flags.syn == 1 && tcp.analysis.retransmission

The analysis order that produces defensible conclusions

1. Isolate the TCP conversation and confirm where the capture was taken.
2. Check capture health: dropped-packet counters, ring buffer overruns, CPU pressure, and whether offload (TSO/GSO/LRO) reshaped segment sizes.
3. Start at the first unexpected ACK, not the first red frame. Write down the receiver’s next-expected byte.
4. Read the SACK blocks: they prove the receiver got later data while missing a lower range.
5. Decide whether the missing range arrived late (reordering) or only as a sender copy (retransmission, or a capture artefact).
6. If loss location matters, capture at a second point and compare — the difference between two observers bounds where the packet disappeared.

Backlog and buffer problems present differently: look for zero-window events and a flat time-sequence graph rather than retransmissions. A good report reads “segment range X arrived 40 ms after later range Z and before any sender copy” or “sender retransmitted X after three duplicate ACKs; original X was not observed at this sensor”. Both are reviewable; “lots of retransmits” is not.

Related reading: capture filters versus display filters, tcpdump command examples and diagnosing packet loss with mtr.

原文链接：https://hannes-software.com/pcap-surgery/blogs/tcp-out-of-order-vs-retransmission-pcap/