The TCP handshake is the three-way exchange of SYN, SYN-ACK and ACK segments that two hosts perform before a TCP connection can carry data. In networking and specifically among transport protocols, it serves three purposes at once: it confirms that both endpoints are reachable and willing, it synchronizes the initial sequence numbers that make reliable delivery possible, and it negotiates connection options such as the maximum segment size and window scaling.
The handshake is defined in the core TCP specification, now consolidated as RFC 9293, and it costs one full round-trip time before the client can send its first byte of application data. That single round trip is why the handshake matters far beyond theory: it shapes page load times, connection pooling strategies and the behavior of firewalls and load balancers.
How the three-way handshake works
The handshake works by having each side announce its own starting sequence number and acknowledge the other side’s number, which takes three segments because the middle segment does both jobs. The client starts in the CLOSED state, the server sits in the LISTEN state on a known port number, and the connection is not usable until both sides reach ESTABLISHED.
The following table shows each step with the flags set, the sequence and acknowledgment values, and the resulting connection state on each side.
| Step | Sender | Flags | Key values | State after the step |
|---|---|---|---|---|
| 1. SYN | Client | SYN | seq = x (client ISN) | Client: SYN-SENT |
| 2. SYN-ACK | Server | SYN, ACK | seq = y, ack = x + 1 | Server: SYN-RECEIVED |
| 3. ACK | Client | ACK | seq = x + 1, ack = y + 1 | Both: ESTABLISHED |
The SYN flag consumes one sequence number even though it carries no payload, which is why each acknowledgment is the received number plus one. The initial sequence number (ISN) is not zero: modern stacks derive it from a clock and a keyed hash of the connection’s addresses and ports, which makes it hard for an off-path attacker to guess and prevents old segments from a previous connection being mistaken for new data.
The final ACK may already carry application data, and many clients send the first request immediately after it. The server, however, cannot send data before receiving that ACK in the standard model, so the earliest response arrives after two round trips for a simple request and response.
Options negotiated during the handshake
Several TCP options can only be agreed in the SYN and SYN-ACK segments, so the handshake fixes important performance properties for the entire life of the connection. If one side does not echo an option, the connection falls back to the behavior without it.
| Option | Purpose | Typical values |
|---|---|---|
| Maximum segment size (MSS) | Largest payload each side will accept | 1460 bytes on Ethernet with IPv4, 1440 bytes with IPv6 |
| Window scale | Multiplies the 16-bit receive window | Shift count 0 to 14, often 7 to 9 |
| SACK permitted | Allows selective acknowledgment of gaps | Present or absent |
| Timestamps | Round-trip measurement and wrap protection | 32-bit values in every segment |
| TCP Fast Open cookie | Allows data in a repeat SYN | Cookie of 4 to 16 bytes |
The MSS value is derived from the interface MTU minus the IP and TCP headers, which is why a path with a smaller MTU, such as a tunnel or PPPoE link, often requires MSS clamping on a router. Window scaling matters most on high-bandwidth, high-latency links: without it, the receive window is capped at 65,535 bytes, which limits throughput on a long-distance path regardless of link speed.
TCP handshake compared with related connection setups
The TCP handshake is one of several ways to establish a session, and comparing it with its neighbors clarifies what it does and does not provide. UDP has no handshake at all, and protocols built on top of TCP or UDP often add their own.
| Mechanism | Round trips before data | What it establishes |
|---|---|---|
| TCP three-way handshake | 1 | Reachability, sequence numbers, options |
| UDP | 0 | Nothing; each datagram stands alone |
| TCP plus TLS 1.2 | 3 | Connection, keys and server authentication |
| TCP plus TLS 1.3 | 2 | Connection, keys and server authentication |
| TCP Fast Open (repeat visit) | 0 for the first request | Data in the SYN with a valid cookie |
| QUIC | 1, or 0 on resumption | Transport and encryption together over UDP |
The handshake is also distinct from connection termination, which uses a separate FIN and ACK exchange in each direction and is often called the four-way close. A connection can additionally be aborted at any point with an RST segment, which a host sends when a SYN arrives for a port where no socket is listening.
Failure modes and what they look like
Most connection problems become visible at the handshake stage, so reading a packet capture of the first three segments is one of the fastest diagnostic techniques in practice. The pattern of what is sent and what returns usually identifies the cause.
| Observed pattern | Likely cause | Typical fix |
|---|---|---|
| SYN answered by RST | No service listening on that port | Start the service or correct the port |
| SYN with no reply, retransmitted | Firewall drop or routing problem | Check filtering rules and return path |
| Handshake completes, large transfers stall | MTU black hole after the MSS agreement | Enable MSS clamping or fix ICMP filtering |
| Many half-open connections on a server | SYN flood or overloaded backlog | Enable SYN cookies, raise the backlog |
| Slow connects on every request | No connection reuse | Use keep-alive or connection pooling |
Initial SYN retransmissions follow exponential backoff, commonly starting at one second and doubling, so an unanswered connection attempt on Linux with default settings can wait for over a minute before failing. Applications that need fast failure therefore set their own connect timeout, typically a few seconds, rather than relying on the operating system.
Security aspects of the handshake
The handshake makes a server allocate state before the client has proven anything, which is the weakness exploited by the SYN flood attack. An attacker sends large numbers of SYN segments, often with spoofed source addresses, and fills the server’s queue of half-open connections so that legitimate clients cannot connect.
The standard defense is SYN cookies: when the queue fills, the server encodes the connection parameters into its own initial sequence number and keeps no state until a valid final ACK returns. The trade-off is that some negotiated options are reduced or lost while cookies are active. Firewalls and load balancers add further protection by proxying the handshake and only forwarding connections that complete it.
- Port scanners use the handshake itself: a SYN-ACK reveals an open port, an RST reveals a closed one.
- Stateful firewalls track the handshake and drop segments that do not belong to a known connection.
- Randomized initial sequence numbers protect against blind injection into an existing connection.
A plain-language summary
The TCP handshake is a short greeting that two computers exchange before they start talking. One says hello, the other answers hello and confirms it heard the first one, and the first confirms it heard the answer. Only after these three messages does the real conversation begin.
During the greeting, each side also announces the number it will use to count its messages and a few rules, such as how large each piece of data may be. This lets both sides notice lost or repeated pieces later. The cost is one short wait for the greeting, which is why websites try to reuse a connection instead of greeting again for every request.
An example from practice
A network administrator investigates complaints that an internal web application takes several seconds to open from a branch office. A packet capture on the client shows the SYN leaving and a SYN-ACK returning after 40 milliseconds, so the path and the service are healthy. Pages with small responses load quickly, but pages with large tables hang after the handshake.
Comparing the options shows that both sides agreed on an MSS of 1460 bytes, while the branch connects through a VPN tunnel with a smaller path MTU, and a firewall is blocking the ICMP messages that would report the problem. Full-size segments are silently dropped. The administrator enables MSS clamping to 1360 bytes on the branch router, and large pages now load in under a second without any change to the application.