ACK (acknowledgement)

What is ACK (acknowledgement)?

In some digital communication protocols, ACK -- short for acknowledgement -- refers to a signal that a device sends to indicate that data has been received successfully. The signal is sent by a receiving station (destination) to the sending station (source) after the receipt of a recognizable block of data of specific and expected size.

The ACK signal is important in computing (buses), telecommunications networks and data networks. As part of a communication protocol, ACK is a way for destination processes or devices to acknowledge that they have received a message from source processes or devices.

The ACK communications code is usually an American Standard Code for Information Interchange character (0000110 or 6) that is reserved and designated for the purpose of signaling communication between the destination station and the sending station. It is also known as the acknowledgement code or acknowledgement character. The code indicates how various senders and receivers handle blocks of data in a particular communication protocol.

To be recognizable, the data block being sent from the source to the destination must conform to the protocol in use. When the source receives the ACK signal from the destination, it transmits the next block of data. If the source fails to receive the signal, it either repeats the block of data or ceases transmission, depending on the protocol. This iterative and continuous process ensures that the right type and amount of data are effectively delivered from a sender to a receiver. In some protocols, there are various ACK signals that indicate the successful reception and recognition of specific commands, such as power-down or standby, for example.


Whereas ACK indicates the receipt of a message, NAK -- or NACK -- is sent to indicate the opposite. NAK specifically means negative acknowledgment or not acknowledged. It can be transmitted by a destination device or process to indicate that it is unable or has failed to receive a message from a source device or process.

NAK may also be sent to indicate that the data transmitted over the network was received with error(s). It could report that the source must resend a specific, expected signal to the destination. Like ACK, NAK is also an ASCII character: 0010101 or 15.

ACK-based communication protocols

TCP is one of the communications protocols that relies on ACK signals to ensure successful data transmissions. When TCP packets are sent over a network, each packet contains an ACK number or flag, which is set to 1 in the packet header. This number indicates the sequence number of the next packet in the data stream that the destination station (device or process) should expect to receive.

So, in TCP, the destination acknowledges the received packets by sending back a packet containing the ACK bit set. A feature of TCP enables ACK to acknowledge that a series of TCP packets has been received instead of one packet. This enables many bytes of data to remain in flight, while minimizing delays. Like TCP, the ZMODEM protocol is also acknowledgement-based, meaning that it involves destinations positively acknowledging the receipt of messages sent by sources by sending ACK codes.

Other protocols are NAK-based, meaning they don't acknowledge the receipt of messages and only respond if there is a problem, such as an error. Most multicast protocols are NAK-based and send NAK signals when the receiver detects missing packets. Still other protocols, such as Binary Synchronous Communications (Bisync), use both ACK and NAK signals. In Bisync, the receiving station sends a NAK to indicate that it has detected a transmission error in the previously received block and is ready to accept its retransmission by the sender.

Finally, some protocols, such as User Datagram Protocol and RC-5, use neither ACK nor NAK. Instead, they perform blind transmission and may transmit the same message multiple times hoping that at least one copy is transmitted correctly and without error to the receiving station.

Three-way handshake in TCP with ACK

Many types of messages are sent over networks based on TCP. For example, SYN (synchronization) is used to initiate and establish a connection and to synchronize sequence numbers between devices in the network. The receiving station sends ACK to confirm to the sender that it has received SYN. Similarly, SYN-ACK is a SYN message from the local device and ACK of the previous packet.

complete TCP handshake vs. half-open connection
Diagram illustrating complete TCP handshake vs. a half-open connection

In TCP, traffic begins with a three-way handshake, a process where the network establishes a connection between the server and client to enable data transfer. In this process, both the server and client exchange SYN and ACK packets before data communication can start.

To start the handshake process and initiate the conversation, the client requests a communication session with the server. It establishes the connection with a SYN signal. Next, the server responds to the client request with a SYN-ACK signal. In step three, the client acknowledges the server's response, and a stable connection is established between the client and server to begin the data transfer process. Once the transfer is complete, TCP automatically terminates the connection between the server and client.

ACK flood DDoS attacks

An ACK flood is a Layer 4 (transport layer) distributed denial-of-service (DDoS) attack. In this scenario, an attacker, or threat actor, tries to overload a server with TCP ACK packets or junk data to crash the server and deny service to legitimate users. The target server must process each ACK packet, which requires a lot of computing power, slowing down service for users.

ACK flood DDoS attacks usually target devices that are required to process every received packet, such as network firewalls and servers. Devices that don't process each packet, such as load balancers, routers and switches are not susceptible to these attacks.

OSI model transport layer
ACK flood is a transport layer -- Layer 4 in the OSI (Open Systems Interconnection) reference model for how applications communicate over a network -- distributed denial-of-service (DDoS) attack.

ACK flood attacks become problematic because both legitimate and illegitimate ACK packets look similar -- although they do not contain the main part of a data packet, or payload. However, they can be stopped using a content delivery network that filters out unnecessary ACK packets and sends additional traffic to other servers to prevent a server -- or website -- from becoming completely unavailable.

Some attackers also use SYN-ACK DDoS attacks to deny service to users. The basic idea is similar to ACK DDoS attacks: to overwhelm a target server with too many packets and make it unavailable. A SYN-ACK DDoS attack involves flooding the target with SYN-ACK packets, which are usually sent by a server in response to a SYN packet from a client device as part of the TCP three-way handshake process. The flood of SYN-ACK packets is not part of the legitimate handshake. Its only purpose is to disrupt the target's normal operations.

In addition to ACK and SYN-ACK, some attackers also SYN packets to author and execute SYN flood DDoS attacks.

Learn about seven TCP/IP vulnerabilities and how to prevent them.

This was last updated in April 2023

Continue Reading About ACK (acknowledgement)

Dig Deeper on Cloud and data center networking

Unified Communications
Mobile Computing
Data Center