IP can lose packets, deliver them out of order, duplicate them, or carry data that becomes corrupted in transit. TCP turns that unreliable packet service into an ordered byte stream.

It does so through a coordinated set of mechanisms:

Reliability does not mean that a connection can survive every failure. TCP can recover from ordinary packet loss, but a permanent path failure or dead endpoint eventually causes the connection to fail. The useful promise is that TCP does not silently omit a hole from the delivered stream.

TCP numbers bytes rather than packets.

Suppose a sender transmits:

The bracket notation [1000, 1500) means that sequence number 1000 is included and 1500 is the first number after the range. The segment therefore contains 500 bytes.

This byte-based design has an important consequence: TCP recovers sequence ranges, not immutable packet objects. A sender can repackage queued data into different segment boundaries during retransmission. A 1000-byte range originally sent as two 500-byte segments could later be sent using another valid segmentation.

Packet captures should therefore be compared by sequence ranges and payload lengths, not by assuming that a retransmitted packet must be byte-for-byte identical to an earlier frame.

SYN and FIN each consume one sequence position. Ordinary reliability analysis of established data usually focuses on payload bytes, but those control positions must be included when a trace crosses connection setup or shutdown.

Both TCP endpoints keep state for each direction.

At the sender:

Bytes from SND.UNA through SND.NXT - 1 have been sent but are not yet cumulatively acknowledged. The sender retains them in a retransmission queue.

At the receiver:

The receiver can hold later bytes that arrive beyond RCV.NXT, but it cannot advance the continuous stream past a missing range.

A local application send can return after the operating system accepts bytes into its buffer. Those bytes may still be untransmitted or unacknowledged. Local acceptance is not remote delivery.

The TCP acknowledgment number is the next sequence number the receiver expects.

If a segment contains bytes [1000, 1500) and all earlier bytes have arrived, the receiver can respond:

That one value cumulatively acknowledges every byte before 1500, not just the most recently received segment.

Suppose three contiguous segments arrive:

The receiver can send Ack=2500, which covers the complete continuous range [1000, 2500). The sender can remove those cumulatively acknowledged bytes from its retransmission queue.

Cumulative acknowledgment makes ACK loss inexpensive in many cases. If Ack=1500 is lost but a later Ack=2500 arrives, the later value also confirms the earlier bytes:

TCP does not retransmit a lost pure ACK as an independent operation. If no later ACK arrives, the sender can eventually retransmit unacknowledged data, which prompts the receiver to acknowledge its current state again.

An ACK reports state in the receiving TCP implementation. It does not prove that the remote application has:

The kernel may acknowledge bytes while they are still waiting in a receive buffer.

For a payment request, Ack=2500 cannot mean "payment completed." It means that the peer TCP stack has received the continuous stream through byte 2499.

Applications that require proof of processing need an application-level response. If the connection fails after the request bytes were acknowledged but before the response arrives, the client still faces an uncertain business outcome.

Sending one pure ACK for every data segment consumes processing and network capacity. TCP receivers can use delayed acknowledgments, briefly waiting so that one ACK covers more data or can travel with data in the reverse direction.

The standard behavior is conservative:

The 500-millisecond value is an upper bound, not a typical target. Real implementations commonly use much shorter delays and can use newer ACK strategies.

This means the absence of an ACK for one individual segment is not evidence of loss. Analyze which byte ranges a later cumulative ACK covers.

Delayed ACK is also different from an application delay. The receiver's TCP stack generates ACKs independently of whether the application immediately reads the data.

Assume the receiver expects byte 1500, but the network loses [1500, 2000) and delivers [2000, 2500) first.

The receiver cannot advance its cumulative acknowledgment:

When more data arrives above the same gap, the receiver continues reporting the next missing position. These repeated values are commonly called duplicate ACKs.

The final acknowledgment jumps to 3500 because the receiver had already buffered the later ranges. Once [1500, 2000) fills the gap, the entire range [1000, 3500) becomes continuous.

A duplicate ACK is evidence that something arrived while the cumulative boundary did not move. Loss is one explanation, but not the only one. Network reordering, duplicated packets, and duplicated ACKs can produce similar signals.

A cumulative ACK identifies the first missing byte but cannot describe all later ranges already present at the receiver.

Selective Acknowledgment, or SACK, adds that information in a TCP option. The capability is enabled during connection setup with the SACK Permitted option.

Consider four 500-byte segments:

The receiver reports:

The cumulative ACK still says that byte 1500 is next. The SACK block says that bytes 2000 through 2999 are already queued. The sender can focus recovery on [1500, 2000) rather than needlessly sending the later range again.

Each SACK block contains:

Several blocks can describe several gaps, subject to the limited TCP option space.

SACK does not replace the cumulative acknowledgment field or change its meaning. SACK information is advisory: the sender retains the data until the cumulative ACK advances past it. This protects against the rare case in which a receiver discards previously SACKed out-of-order data under memory pressure.

Duplicate SACK, or DSACK, uses a SACK block to report data received more than once. It can help a sender recognize packet duplication or a retransmission that turned out to be unnecessary.

TCP cannot directly observe a packet disappearing inside the network. It infers loss from missing acknowledgment progress.

Three broad signals are useful:

The sender must balance speed against uncertainty. Retransmitting too slowly extends stalls. Retransmitting too quickly mistakes ordinary delay or reordering for loss and adds unnecessary traffic.

The Retransmission Timeout, or RTO, is the fallback that works even when no useful feedback returns.

Before an RTT sample exists, the standard initial RTO is one second. Once measurements are available, TCP maintains:

The basic calculation is:

RTT variation matters because a path with a 100-millisecond average and highly variable delay needs a safer timeout than a stable 100-millisecond path.

For the first RTT measurement R:

For a later measurement R', the estimator gives more weight to history:

The standard calculation rounds an RTO below one second up to one second as a conservative lower bound. Deployed stacks can use implementation-specific timer behavior, so an observed timeout should be measured rather than inferred solely from the formula.

When the timer expires, TCP retransmits the earliest unacknowledged data. It then doubles the RTO:

This exponential backoff prevents a persistently failing path from being flooded with retries at a fixed short interval.

If repeated attempts do not restore progress, TCP eventually reports a connection failure. Retry limits and user-timeout policies are implementation and configuration details rather than fixed universal counts.

To update its timer, a sender measures the interval between transmitting data and receiving an acknowledgment for it.

Retransmission creates ambiguity:

Did the ACK result from the original transmission or the retransmission? Without additional information, the sender cannot know which send time produced the measured RTT.

Karn's algorithm avoids taking RTT samples from retransmitted segments. The TCP Timestamp option can remove the ambiguity by echoing a value associated with a particular transmission.

Avoiding ambiguous samples keeps a late original packet from corrupting the path's RTT estimate.

Waiting for the RTO can be unnecessarily slow when ACK feedback already reveals a gap.

Traditional fast retransmit treats three duplicate ACKs, with no intervening cumulative progress, as evidence that the segment beginning at the acknowledgment number was probably lost.

The sender retransmits without waiting for the RTO.

Three duplicates are a trade-off. One out-of-order segment is not enough to declare loss because modest reordering is normal. Several later arrivals make a persistent gap more convincing.

Fast retransmit works best when enough data follows the loss to generate duplicate ACKs. If the last segment in a short request is lost, no later segment may arrive at the receiver, so there are no duplicate ACKs. The sender then needs a timer or a more modern probe-based mechanism.

Loss recovery also affects how much new data TCP may send. That rate adjustment is congestion-control behavior; it is separate from identifying and retransmitting the missing byte range.

Duplicate-ACK counting reasons mostly about packet order. Modern TCP implementations can use RACK-TLP, a time-based loss-detection design.

Recent Acknowledgment, or RACK, tracks transmission times and uses cumulative or selective acknowledgment of more recently sent data as evidence about older unacknowledged data. If an older range has remained unacknowledged beyond an allowance for reordering, RACK marks it lost.

This approach handles cases that simple duplicate-ACK counting handles poorly, including:

Tail Loss Probe, or TLP, addresses loss near the end of a flight, where no later data exists to trigger duplicate ACKs. It sends a probe—new data if available, otherwise a retransmission of the highest-sequence outstanding data—to solicit acknowledgment feedback before the full RTO expires.

RTO remains the last-resort fallback if probes and fast recovery do not restore acknowledgment progress.

RACK-TLP uses per-segment transmission times and SACK feedback internally. A packet capture may show its probe or retransmission, but the algorithm's decision is sender state rather than a distinct TCP header flag.

A repeated sequence range means the sender transmitted those bytes again. It does not prove that the original copy was dropped.

Consider:

The receiver uses sequence numbers to deliver the bytes once and discards the duplicate portion. DSACK or timestamps can help the sender recognize the spurious retransmission.

Reordering, sudden RTT increases, ACK loss, and capture artifacts can all produce retransmission-like patterns.

TCP's duplicate suppression applies within the byte stream. It does not make two application requests identical or prevent a client from repeating a business operation on a new connection.

The receiver validates the TCP checksum before accepting a segment. A segment with a bad checksum is discarded rather than inserted into the stream.

TCP does not send a general negative acknowledgment saying "segment 1500 was corrupt." From the sender's perspective, a discarded corrupted segment behaves like a lost segment:

Lower layers can also detect and discard damaged frames before TCP sees them. In either case, TCP recovery operates from the missing byte range, not from a detailed report of where corruption occurred.

Assume SACK is enabled and the sender transmits:

Segment B is lost.

The receiver's state evolves:

At the sender:

The receiving application sees one ordered stream. It does not need to know that B was recovered after C and D arrived.

TCP can retry data, but it cannot create a functioning network path.

If acknowledgments never return, the RTO backs off and recovery attempts become farther apart. Eventually, the operating system reports an error or a configured user timeout expires.

The application then knows the connection failed, but it may not know how much remote processing occurred:

This uncertainty is why application retries need idempotency keys, transaction identifiers, or other duplicate-safe semantics. TCP reliability prevents missing or duplicate bytes inside one delivered stream; it does not provide exactly-once business execution.

Capture absolute sequence values and enough packets to see both directions:

Replace en0 with the relevant interface.

For every apparent loss, record:

Wireshark provides analysis filters such as:

These labels are analyzer inferences, not TCP header fields. They can be wrong when the capture starts mid-connection, drops packets, sees only one direction, records packets out of order, or observes host offload artifacts.

On Linux, ss -ti can expose live TCP estimates and counters such as RTT, RTO, reordering, and retransmitted bytes. Exact output depends on the kernel and connection state.

One capture rarely proves where a packet was lost.

Suppose the sender-side capture shows the original data and a later retransmission:

Possible explanations include:

A capture near the receiver can separate these cases:

Host captures also interact with segmentation, receive aggregation, and checksum offloads. Use byte ranges and timestamps from consistent observation points.

Duplicate ACKs followed by a quick retransmission: A gap was inferred from later arrivals. Check whether SACK isolates the missing range and whether reordering could explain the pattern.

Long silence followed by a retransmission: The RTO or another timer-based mechanism probably fired because useful ACK feedback was absent. Compare the delay with the sender's measured RTO.

Retransmission intervals grow exponentially: Repeated RTO backoff suggests continued lack of acknowledgment progress, severe loss, a broken return path, or an unreachable endpoint.

SACK blocks advance while the cumulative ACK is fixed: Later bytes are arriving, but one earlier gap still prevents continuous progress.

The same retransmitted range is lost repeatedly: Investigate traffic policing, persistent path loss, receiver overload, checksum errors, and whether a particular packet size triggers filtering or an MTU problem.

Many DSACKs or spurious-retransmission labels: Reordering, sudden delay changes, duplicated packets, or overly aggressive loss inference may be present.

Only one direction shows recovery problems: TCP's directions can traverse asymmetric paths. Analyze data and ACK paths separately.

Application latency rises with few retransmissions: Network loss may not be the dominant delay. Separate transport recovery time from server processing and dependency latency.

TCP sequence numbers count bytes, not packets. Recovery can use different segment boundaries from the original transmission.

An ACK is cumulative. Ack=3000 confirms the continuous stream before 3000, not one particular packet.

A lost ACK does not always require retransmission. A later cumulative ACK can cover the same data.

An ACK does not mean the application processed the bytes. It reports receiving TCP state.

Duplicate ACKs do not prove loss. Reordering and duplication can produce them.

SACK does not replace the acknowledgment number. It reports additional received ranges beyond the cumulative boundary.

TCP has no general negative acknowledgment for corrupted data. Missing progress causes the sender to infer loss.

A retransmission does not prove the first copy was dropped. It records the sender's decision under uncertainty.

Pure ACKs are not made reliable by ACKing the ACK. Cumulative feedback and data retransmission recover from lost ACKs.

RTO is not an application request timeout. Transport recovery and application deadlines are independent policies.

TCP reliability is not exactly-once execution. Application retries can repeat operations even though TCP suppresses duplicate stream bytes.

TCP reliability is a feedback loop over byte sequence space. The sender retains unacknowledged bytes, while the receiver tracks the next byte needed for a continuous stream and suppresses duplicates. A cumulative ACK confirms all earlier bytes; delayed ACKs reduce overhead, and out-of-order arrivals leave the ACK at the gap. SACK reports later blocks so only missing ranges need retransmission.

The retransmission timeout uses smoothed RTT and variation, then backs off after a timeout. Karn's algorithm avoids ambiguous RTT samples unless timestamps disambiguate them. Traditional fast retransmit reacts to three duplicate ACKs, RACK uses timing and acknowledgment evidence, and TLP probes tail losses that may not produce duplicate ACKs.

Corrupt data discarded after checksum validation is recovered like loss. Retransmissions may also be spurious, and analyzer labels depend on capture quality. TCP eventually reports unrecoverable failure, leaving safe retry semantics to the application.

Analyze reliability by following byte ranges, locating the gap, interpreting ACK and SACK feedback, and identifying what finally restored continuity.