ACK is an abbreviation for
Acknowledgement. On
unreliable networks such as the
Internet where
packets are not guaranteed to arrive at their destination, it is neccesary for the
host receiving data to send an "
ACK" packet back to the sender notifying that the data was received. If the sender does not receive an ACK, a
timeout will eventually occur and the packet will be resent.
In Sliding Window, as used by TCP, data is sent in a stream. ACKs here take the form of the last point in the stream which has been fully reached (all data up to this point has been received).
TCP usually uses delayed ACKs. That is, when data is received, an ACK is not immediately sent. RFC 1122 specifies that ACKs should not be delayed by more than 0.5 seconds. There are multiple reasons for delaying acks:
- The main reason is for the application to send a reply to the data it receives. For example, when you type a character into a telnet connection, the character is usually echoed back to you. Delaying ACKs allows the response and the ACK to be sent in the same packet.
- If another packet is received, multiple packets can be ACKed with a single packet.
- As well as sending a response, delayed acks allow the received data to be read out of the receive buffer, allowing a bigger window advertisement to the sender and (presumably) increasing throughput.
In TCP, ACK itself is a
flag in the TCP
header which indicates that acknowledgement data is present in the packet. It is reused for the
connection and
disconnection three way handshake:
client server
---------- SYN -------->
<------- SYN ACK -------
---------- ACK -------->
And for disconnect:
host 1 host 2
---------- FIN -------->
<------- FIN ACK -------
---------- ACK -------->