Why Three Packets?
TCP is a reliable, ordered, bidirectional byte stream. Before two machines can exchange data, they need to agree on initial sequence numbers, window sizes, and capabilities. The three-way handshake establishes this:
- SYN: the client sends a packet with SYN flag set and its initial sequence number (ISN). "I want to talk. My sequence starts at X."
- SYN-ACK: the server responds with SYN+ACK, its own ISN, and acknowledges the client's ISN. "I hear you. My sequence starts at Y. I acknowledge your X."
- ACK: the client acknowledges the server's ISN. "I acknowledge your Y." Data can now flow in both directions.
This takes 1.5 round trips. On a cross-continent connection with 100ms RTT, that is 150ms before any data moves. On a cellular connection with 300ms RTT, it is 450ms. For short-lived HTTP/1.1 requests, the handshake can be longer than the actual data transfer.
Figure 1: The TCP three-way handshake. Client sends SYN, server responds with SYN-ACK, client sends ACK. Data can be sent with the third packet.
Why Not Two Packets?
The third packet (ACK) is essential. Without it, the server doesn't know if the client received the SYN-ACK. The server would allocate resources (memory for the connection state) without confirmation that the client is still there. This enables SYN flood attacks: an attacker sends millions of SYN packets with spoofed source IPs. The server allocates memory for each, sends SYN-ACKs to fake addresses, and waits. The server's connection table fills up. Legitimate connections are refused.
The defense: SYN cookies. The server encodes its state (ISN, window size, MSS) into the SYN-ACK's sequence number cryptographically. It allocates zero memory. When the client's ACK arrives, the server reconstructs the connection state from the ACK's sequence number. No memory allocated until the handshake completes. Linux enables SYN cookies automatically under load.
TCP Fast Open: Eliminating the Handshake
TCP Fast Open (TFO) lets the client send data in the first SYN packet — zero round trips for repeat connections. On the first connection, the server gives the client a cookie. On subsequent connections, the client includes the cookie and data in the SYN. The server validates the cookie and processes the data immediately, without waiting for the ACK.
Google measured that TFO reduces HTTP request latency by 10-40% for short transfers. Linux, macOS, and iOS support TFO. However, middleboxes (firewalls, NATs, proxies) sometimes drop SYN packets with data, which limits TFO's real-world deployment.
QUIC: No Handshake at All
QUIC (the protocol behind HTTP/3) eliminates TCP's handshake entirely. QUIC runs over UDP and combines transport setup and TLS encryption into a single round trip (or zero for repeat connections). Google's measurements show QUIC reduces page load time by 8% on desktop and 3.6% on mobile compared to TCP+TLS.
Connection States and TIME_WAIT
After a TCP connection closes, the socket enters TIME_WAIT for 2 × MSL (Maximum Segment Lifetime, typically 60 seconds on Linux). This prevents delayed packets from a closed connection being interpreted as part of a new connection on the same port. On high-traffic servers, thousands of TIME_WAIT sockets can exhaust the port space. The fix: net.ipv4.tcp_tw_reuse = 1 allows reusing TIME_WAIT sockets for new outgoing connections.