Loading full navigation.

Autonomous IT is here. The alert loop ends now. LEARN MORE

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.

LOGICMONITOR BLOG

How SACK Transmissions Improve Web Performance

See how TCP Selective Acknowledgment cuts wasteful retransmissions on lossy, high-latency links and speeds recovery to deliver faster web performance.

3–4 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download:

TCP Selective Acknowledgment (SACK) speeds web performance by retransmitting only the data that was actually lost.

  • Cumulative acknowledgment confirms only a contiguous run of bytes, so one lost segment can force the sender to resend data the receiver already holds.

  • SACK lets the receiver report the exact non-contiguous blocks it has received, so the sender resends just the missing segments.

  • On lossy, high-latency paths, this cuts wasted bandwidth, shortens recovery, and delivers faster throughput.

  • Pair SACK with outside-in Internet path monitoring to see where packet loss and retransmissions actually occur and act on them.

TCP carries most web traffic, and it protects that traffic by retransmitting segments that are lost or damaged. Its original recovery mechanism, cumulative acknowledgment, comes with a cost.

Cumulative acknowledgment confirms only a contiguous run of bytes, so a single lost segment can push the sender to resend data the receiver already holds. Selective Acknowledgment (SACK) removes much of that waste and improves web performance on lossy, high-latency paths.

Why cumulative acknowledgment slows recovery from packet loss

With standard cumulative acknowledgment, the receiver confirms the highest in-order byte it has received.

If a segment in the middle of a stream is lost, later segments can still arrive and be buffered, but the cumulative acknowledgment cannot advance past the missing data. The receiver therefore sends duplicate ACKs for the next byte it expects. Without SACK, the sender has limited information about which later segments have already arrived, making recovery from multiple losses slower and potentially causing unnecessary retransmissions.

On high-latency or lossy links, resending data that already arrived wastes bandwidth and adds delay.

How SACK reports received data

SACK, defined in RFC 2018, lets the receiver report exactly which non-contiguous blocks of data it has already received. The sender then retransmits only the missing segments, rather than resending everything after the missing segment. SACK uses two distinct TCP options.

The SACK-Permitted option

SACK support is negotiated during the TCP handshake. Each side advertises it by including the SACK-Permitted option in its SYN segment. In a Wireshark capture, this option appears as Kind 4, Length 2, and it carries no payload of its own.

The SACK option and block format

Once both sides agree to use SACK, the receiver sends the SACK option inside its ACK segments. Each SACK block is defined by two 32-bit values.

The left edge marks the first byte of the received block, and the right edge marks the first byte just past it. A single ACK can carry several blocks to report multiple non-contiguous ranges at once.

The five-step SACK process

A typical SACK recovery follows five steps when a segment is lost in transit.

  1. The sender transmits a series of TCP segments to the receiver.
  2. One segment is lost in transit, so the receiver buffers the segments that arrive after it.
  3. The receiver returns an ACK with a SACK block reporting the data it holds, such as left edge 1400 and right edge 1500.
  4. The sender reads the SACK block, identifies the single missing segment, and retransmits only that segment.
  5. The receiver fills the missing range and advances its cumulative acknowledgment to confirm the complete, in-order stream.

How D-SACK reports duplicate segments

D-SACK, or duplicate SACK, extends the mechanism in RFC 2883. It lets the receiver report a segment it received more than once, not only the data it is still missing. When a duplicate arrives, the first SACK block reports the duplicated sequence range.

This extra signal helps the sender distinguish genuine loss from an unnecessary retransmission, so it can tune its sending behavior more accurately.

Reading SACK options in a Wireshark capture

A packet capture makes the SACK options concrete. During connection setup, Wireshark shows the SACK-Permitted option as Kind 4, Length 2, confirming that both ends will use SACK.

Later in the connection, an ACK carries a SACK block with a left edge of 18225 and a right edge of 18620. That block reports to the sender that the receiver already holds bytes 18225 through 18619, while an earlier segment is still outstanding.

Where SACK fits in network and Internet path monitoring

SACK cuts wasted retransmissions, but it can’t remove packet loss, and loss still degrades throughput and the experience users see. Acting on it means knowing where packet loss and retransmissions happen across both the internal network and the wider Internet path.

LM Internet Performance Monitoring gives outside-in visibility into packet loss, latency, and path degradation beyond the firewall. Paired with infrastructure monitoring for the systems teams control, it shows where loss and latency originate along the path from user to code.

Pinpoint packet loss and retransmissions across your network and the entire Internet path.

SACK only helps once you know where loss happens. LogicMonitor delivers outside-in visibility from the user to your code, so you can fix the paths that slow web performance.

FAQs

What is the difference between cumulative acknowledgment and Selective Acknowledgment (SACK)?

Cumulative acknowledgment confirms only the highest contiguous byte received, so a single mid-stream loss can force the sender to resend data the receiver already has. SACK lets the receiver report the exact non-contiguous blocks it received, so the sender retransmits only the missing segments. This reduces wasted bandwidth and speeds recovery.

How do the two TCP options for SACK work?

SACK uses the SACK-Permitted option and the SACK option. During the handshake, each side advertises support with the SACK-Permitted option in its SYN segment, which appears as Kind 4, Length 2 in a capture. Once agreed, the receiver includes SACK blocks in its ACKs, each defined by a left edge and a right edge that mark the received range.

What is D-SACK and why does it matter?

D-SACK, or duplicate SACK, is defined in RFC 2883 and lets the receiver report a segment it received more than once. This helps the sender tell genuine loss apart from an unnecessary retransmission. With that signal, the sender can tune its sending behavior more accurately.

By Denton Chikura

Technical Writer

Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

How to Monitor Enterprise WAN Performance Across MPLS, SD-WAN, and Internet Paths
Blog Network

How to Monitor Enterprise WAN Performance Across MPLS, SD-WAN, and Internet Paths

Correlate internal infrastructure health with Internet-path data to localize WAN slowdowns fast across MPLS, SD-WAN, and direct Internet access at the branch.
October 27, 2026
Learn more
How SACK Transmissions Improve Web Performance
Blog Network

How SACK Transmissions Improve Web Performance

See how TCP Selective Acknowledgment cuts wasteful retransmissions on lossy, high-latency links and speeds recovery to deliver faster web performance.
October 27, 2026
Learn more
How to Build an Alert Strategy for Hybrid and Internet-Dependent Services
Blog AIOps & Automation

How to Build an Alert Strategy for Hybrid and Internet-Dependent Services

Cut alert fatigue and resolve incidents faster. Learn how to design tests, route alerts to the right owning team, and connect internal and Internet signals.
October 27, 2026
Learn more