ACK

In short: An acknowledgement flag in TCP that signals that a packet (or a specific sequence number) was received successfully.

In more detail: ACK packets are the foundation of TCP’s reliability: if an expected acknowledgement doesn’t arrive, the sender assumes the packet was lost and sends it again. The third packet in the three-way handshake is a pure ACK that completes the connection setup.

In Depth

Cumulative acknowledgement instead of per-packet receipts

Technically, ACK isn’t a standalone packet but a single flag bit in the TCP header, which is sent together with a 32-bit acknowledgement number. This number tells the sender exactly which byte is expected next — not “packet 5 arrived”, but “I’ve received everything up to and including byte 4000, send me byte 4001”. This allows cumulative acknowledgements: if the segments with bytes 1000–2000, 2000–3000 and 3000–4000 arrive at the receiver, a single ACK with the number 4001 is enough to acknowledge all three at once — a separate reply doesn’t have to be sent for every single segment. This saves considerable overhead on stable connections, but has a drawback: if a segment in the middle is missing (e.g. bytes 2000–3000 are lost), the receiver can only acknowledge up to the last gap-free position (2001), even if the later segments have already arrived. Modern TCP implementations solve this with the “Selective Acknowledgment” (SACK) extension, which additionally reports which later blocks are already present, so that the sender only has to resend the actual gap instead of all the remaining data.

Timeout, fast retransmit and duplicate ACKs

If an expected acknowledgement doesn’t arrive within the retransmission timeout (RTO), TCP assumes a lost packet and sends it again — the RTO is adjusted dynamically to the measured round-trip time (RTT), usually as a moving average plus a multiple of the observed variation, so that the system reacts sensibly both in fast local networks (RTT in the millisecond range) and over high-latency routes (satellite links, intercontinental lines), resending neither too early nor too late. A special case is “duplicate ACKs”: if a segment arrives at the receiver out of order (e.g. segment 3 is missing but segment 4 arrives), the receiver keeps acknowledging the last gap-free position — repeatedly with the same number. If the sender receives the same acknowledgement number three times in a row, it interprets this as a strong signal of a specific packet loss (not of general congestion) and starts retransmitting immediately (fast retransmit), instead of waiting for the full timeout — which speeds up error correction considerably in practice.

Role in the connection lifecycle

In the three-way handshake, ACK appears twice: once combined with SYN-ACK in the second packet, and once as a pure ACK in the third packet, which officially puts the connection into the “ESTABLISHED” state. Connection teardown also runs via ACKs (as part of the FIN/ACK sequence, in which both sides close their end of the connection independently of each other) — so ACK accompanies practically the entire lifecycle of a TCP connection, not just the setup. Interestingly, almost every TCP segment sent after the handshake has the ACK flag set AND carries payload at the same time (“piggybacking”) — pure ACK packets without data mainly occur when one side only receives but has nothing of its own to send.

Debugging in practice

In packet captures (e.g. with Wireshark), a conspicuously large number of duplicate ACKs or repeated retransmissions is a direct signal of packet loss along the route — often caused by overloaded routers, faulty cables or unstable Wi-Fi. A so-called “ACK storm” (masses of ACKs in a short time, often without associated payload) can also indicate a misconfiguration or even a denial-of-service attempt in which forged packets trigger mutual acknowledgement loops between two systems. By contrast, UDP doesn’t know the ACK concept at all — anyone who needs reliability on top of UDP (e.g. in some video streaming or gaming protocols) has to implement their own, often leaner acknowledgement logic at the application level.

See also: SYN, SYN-ACK, Three-way handshake