SYN-ACK

In short: The second packet in the TCP three-way handshake — the server acknowledges the client’s SYN and at the same time signals its own readiness for the connection.

In more detail: Combines two flags in one packet: the ACK flag (acknowledging the client’s SYN) and its own SYN flag (the server also wants to synchronise a sequence number). The client answers with a pure ACK, and the connection is established.

In Depth

The SYN-ACK packet fulfils two functions at once, which reduces the three-way handshake to only three messages instead of four: it acknowledges (ACK) the sequence number from the client’s SYN AND at the same time announces (SYN) its own initial sequence number chosen by the server. After exchanging SYN and SYN-ACK, both sides have already had the other’s sequence number acknowledged — only the server is still waiting for an explicit acknowledgement of its own sequence number, which comes in the third step (a pure ACK from the client).

A server in the “SYN-RECEIVED” state (SYN-ACK sent, but no final ACK received yet) keeps resources reserved for the half-finished connection — this is exactly the waiting phase exploited by the SYN flood attack: an attacker sends masses of SYN packets with forged sender addresses, the server dutifully answers with SYN-ACK to these (non-existent) addresses and waits in vain for the third ACK until its connection table is full and no real clients get through any more. Modern operating systems use “SYN cookies” as a countermeasure to avoid this resource consumption.

See also: SYN, ACK, Three-way handshake