SYN-ACK is a type of network packet that a server sends back to a client during the process of establishing a TCP connection. It’s the second step in a three-step sequence called the “three-way handshake,” which is how two computers agree to start communicating over the internet. The name combines two flags: SYN (synchronize) and ACK (acknowledge), because the packet does both jobs at once.
How the Three-Way Handshake Works
Every time you load a webpage, send an email, or stream a video, your device and the remote server perform a quick handshake before any real data flows. This handshake ensures both sides are ready and agree on how to track the data they’ll exchange. It happens in three steps, each involving a small packet with specific flags turned on in its header.
Step 1: SYN. Your device (the client) sends a packet with the SYN flag set to 1. This is a request to synchronize. The packet includes a randomly chosen starting number called an initial sequence number (ISN), which will be used to keep track of every byte sent during the connection.
Step 2: SYN-ACK. The server responds with a packet that has both the SYN and ACK flags set to 1. This single packet does two things simultaneously: it acknowledges the client’s SYN by incrementing the client’s sequence number by one and sending that back, and it also sends its own randomly chosen sequence number so the client can track the server’s data in return.
Step 3: ACK. Your device sends one final packet with just the ACK flag set, confirming it received the server’s sequence number. At this point, the connection is fully open and both sides can start sending real data.
The entire handshake typically completes in milliseconds. It’s invisible to you as a user, but it happens before every TCP-based interaction on the internet.
What the SYN and ACK Flags Actually Are
Every TCP packet carries a header, and inside that header are several single-bit flags that can be turned on (set to 1) or off (set to 0). The SYN flag signals a request to synchronize sequence numbers. The ACK flag signals that the packet’s acknowledgment number field contains a valid value. When a server sends a SYN-ACK, it’s flipping both of those bits to 1 in the same packet header.
The acknowledgment number itself is simple: it’s the sequence number the receiver expects to see next. So if your device sent a SYN with sequence number 8221821, the server’s SYN-ACK would include an acknowledgment number of 8221822, proving it received your specific request and is ready for the next byte.
What Gets Negotiated During the Handshake
The SYN and SYN-ACK packets don’t just exchange sequence numbers. They also carry options that let both sides agree on performance settings for the connection. These options are only negotiated during the handshake, never during normal data transfer.
- Maximum Segment Size (MSS): The largest chunk of data each side is willing to receive in a single TCP segment. This prevents either side from sending packets too large for the other to handle.
- Window Scale: A multiplier that allows the connection to use receive windows larger than 64 kilobytes, which is important for high-speed or long-distance connections.
- Selective Acknowledgments (SACK): Permission for each side to acknowledge specific ranges of received data instead of only the most recent byte. This makes recovering from lost packets much more efficient.
- Timestamps: Used to calculate how long packets take to travel between the two devices, helping TCP fine-tune its timing for retransmissions.
All of these options are proposed in the initial SYN packet and confirmed or adjusted in the SYN-ACK response, so both sides have agreed on the rules before any data starts flowing.
Connection States During the Handshake
Both the client and server move through specific internal states as the handshake progresses. Before anything happens, the server sits in a LISTEN state, waiting for incoming connections. When the client sends its SYN, the client enters a state called SYN_SENT. Once the server receives the SYN and sends back its SYN-ACK, the server moves to SYN_RECEIVED.
When the client gets the SYN-ACK, it immediately transitions to ESTABLISHED. The server reaches ESTABLISHED once it receives the client’s final ACK. These state labels show up in networking tools and diagnostic commands, so recognizing them helps when troubleshooting connection problems. If you see a connection stuck in SYN_SENT, for instance, the server’s SYN-ACK never made it back.
What Happens When a SYN-ACK Gets Lost
If the SYN-ACK packet is lost or dropped, the client never transitions to ESTABLISHED and the server stays in SYN_RECEIVED. The server will retransmit the SYN-ACK after a timeout, typically starting at 3 seconds. If repeated retransmissions fail, the connection attempt eventually times out entirely.
Firewalls are one of the most common causes of dropped SYN-ACK packets. Many firewalls are configured to reject TCP packets that don’t match an existing connection. If the original SYN went through one network path but the SYN-ACK returns through a different path (a situation called asymmetric routing), the firewall on the return path never saw the original SYN and silently drops the SYN-ACK. This can be confusing to diagnose because the client simply sees a connection that never completes, with no error message.
SYN Floods and SYN Cookies
The three-way handshake creates a potential vulnerability. When a server receives a SYN, it allocates memory to track the half-open connection while waiting for the final ACK. An attacker can exploit this by sending thousands of SYN packets from fake addresses. The server dutifully responds with SYN-ACKs that will never be answered and fills up its connection table with half-open entries. Eventually, legitimate users can’t connect. This is called a SYN flood attack.
The most widely used defense is called SYN cookies. Instead of storing state for every incoming SYN, the server encodes the connection information directly into the sequence number of its SYN-ACK. It doesn’t allocate any memory at all until the final ACK comes back with the correct number. This lets the server handle massive volumes of SYN packets without running out of resources, and it requires no changes on the client side.