Acknowledgment
TCP ACK (Acknowledgment, bit 3) indicates the Acknowledgment Number field is valid. When set, the ACK number tells the sender how much data has been received. Almost all TCP segments after the initial SYN have ACK set. The SYN is the only segment in a normal connection that does not have ACK set.
Abbreviation
ACK
Bit Position
3
tcpdump
[.]
Standard
RFC 9293
Description
ACK is the most common TCP flag – it is set in every segment except the initial SYN. The Acknowledgment Number field (32 bits) contains the sequence number of the next byte the receiver expects to receive, which implicitly acknowledges all bytes up to that point.
TCP's reliability mechanism is built on ACKs: the sender keeps unacknowledged data in a retransmission buffer. If an ACK is not received within the retransmission timeout (RTO), the sender retransmits. Cumulative ACKs allow a single ACK to acknowledge a large burst of data.
Delayed ACKs (RFC 1122): receivers may delay ACKs up to 500ms hoping to piggyback the ACK on outgoing data. This reduces ACK traffic but adds latency for small request-response protocols. Disabling Nagle's algorithm (TCP_NODELAY) on the sender side is the common fix for latency-sensitive applications.
Key Flag Combinations
| Flags | Meaning |
|---|---|
| SYN+ACK | Server's response to client SYN – second step of three-way handshake |
| FIN+ACK | Graceful connection close with acknowledgment |
| RST+ACK | Reset acknowledging data – peer is aborting a connection |
| PSH+ACK | Data segment that should be pushed to application – most common data segment |
When You See This Flag
- –Acknowledging received data in every segment after connection establishment
- –Responding to SYN with SYN+ACK in three-way handshake
- –Delayed ACK timer firing after 40-500ms of waiting for piggyback opportunity