A SYN packet is the very first message one computer sends to another when it wants to open a network connection using TCP (Transmission Control Protocol). The name comes from “synchronize,” because the packet’s job is to sync up both sides before any real data flows. Every time you load a webpage, send an email, or stream a video, a SYN packet fires off behind the scenes to get that connection started.
How SYN Packets Fit Into the Three-Way Handshake
TCP is the protocol responsible for reliable data delivery across the internet. Before two devices can exchange information, they go through a short setup ritual called the three-way handshake. It works like this:
- Step 1 (SYN): Your computer sends a SYN packet to the server. This packet includes a proposed starting number, called an initial sequence number, which both sides will use to keep track of the data they exchange.
- Step 2 (SYN-ACK): The server responds with a packet that has both the SYN and ACK flags set. It acknowledges your sequence number and proposes its own.
- Step 3 (ACK): Your computer sends back a final acknowledgment, confirming the server’s sequence number. The connection is now open, and data can flow.
The SYN flag is only used during this connection setup phase. Once the handshake finishes, it never appears again for that connection. Think of it as a doorbell: it rings once to start the conversation, then it’s done.
What’s Actually Inside a SYN Packet
A SYN packet is a standard TCP segment with one specific bit flipped on in its header. The TCP header contains fields for source and destination ports, a sequence number, an acknowledgment number, several single-bit control flags, a window size, and a checksum. The SYN flag is one of those control bits. When it’s set to 1, it tells the receiving machine: “I want to start a new connection, and here’s my proposed starting sequence number.”
That initial sequence number matters more than it might seem. Both sides use sequence numbers to track every byte of data sent during a connection, ensuring nothing gets lost or delivered out of order. Modern operating systems generate these numbers using cryptographic methods, often hashing together the source and destination addresses, ports, and a secret key. Older systems used simple time-based counters, which turned out to be a serious security problem because attackers could guess the next number and hijack connections.
SYN Flood Attacks
The three-way handshake has a built-in vulnerability. When a server receives a SYN packet, it allocates memory and resources to track the new half-open connection while it waits for the final ACK that completes the handshake. An attacker can exploit this by flooding a server with thousands of SYN packets and never sending the finishing ACK for any of them. Each fake request eats up server resources, and eventually the server runs out of room to accept legitimate connections.
This is called a SYN flood attack, and it’s one of the most common forms of denial-of-service (DoS) attack. The asymmetry is what makes it effective: sending a SYN packet costs the attacker almost nothing, while the server has to commit resources for each one.
How Servers Defend Against SYN Floods
The most widely used defense is called SYN cookies. Instead of storing connection information in a table after receiving a SYN, the server encodes everything it needs directly into the sequence number it sends back in the SYN-ACK. That sequence number packs in a timestamp (5 bits), the agreed-upon maximum segment size (3 bits), and a cryptographic hash of the connection details (24 bits). When the client’s final ACK comes back, the server can recalculate the hash and verify the connection is legitimate, all without having stored anything in memory. If the ACK never arrives, the server hasn’t wasted any resources.
SYN Packets in Port Scanning
Security professionals and attackers alike use SYN packets to probe whether ports on a remote machine are open. A tool like Nmap can send a SYN packet to a target port and draw conclusions from the response without ever completing the handshake.
If the port is open, the target responds with a SYN-ACK, inviting the connection. Nmap notes the port as open and never sends the final ACK. The operating system on the scanning machine automatically sends a reset (RST) packet instead, killing the half-formed connection. If the port is closed, the target immediately sends back a RST packet on its own. If no response comes back at all, or the scanner receives an ICMP “unreachable” error, the port is marked as filtered, likely blocked by a firewall.
This technique is called a SYN scan or “stealth scan” because no full TCP connection is ever established. Many older logging systems only recorded completed connections, so SYN scans could slip past without leaving a trace. Modern intrusion detection systems are better at spotting them, but SYN scanning remains the default method for network reconnaissance.
SYN vs. FIN: Starting and Ending Connections
If the SYN flag opens a connection, the FIN flag closes it. When one side is done sending data, it sends a packet with the FIN flag set. The other side acknowledges it, then sends its own FIN when it’s also finished. That second FIN gets acknowledged too, making it a four-step process compared to the three-step handshake for setup.
The key difference is scope. The SYN flag only appears in the first packets of a connection and is never reused. The FIN flag only appears at the end. Between those two bookends, all the actual data transfer happens using regular packets with the ACK flag set, with sequence numbers ticking upward to keep everything in order.
Connection States Triggered by SYN Packets
When your computer sends a SYN packet, it enters a state called SYN-SENT, meaning it’s waiting for the server’s SYN-ACK reply. The server, after receiving the SYN and sending back its SYN-ACK, enters SYN-RECEIVED. Once the final ACK arrives, both sides move to the ESTABLISHED state, and the connection is fully operational. Before any of this happens, a server waiting for incoming connections sits in the LISTEN state.
These states are defined in RFC 9293, the current official specification for TCP maintained by the Internet Engineering Task Force. If you’ve ever run a command like netstat or ss on your computer, you may have seen these state names listed next to active connections. A large number of connections stuck in SYN-RECEIVED can be a sign that a server is under a SYN flood attack.