The three-way handshake

Each side needs to tell the other its initial sequence number and learn that the other heard it. The client sends SYN with ISN *x*; the server replies SYN-ACK — its own ISN *y*, and ack *x+1* to prove it received the SYN; the client sends ACK *y+1*. Three packets is the minimum for both sides to have their ISN acknowledged — two would leave the server unsure the client received its ISN. The SYN also carries options that shape the whole connection: MSS, window scaling, SACK permitted, timestamps. ISNs are randomised so old duplicates from a previous connection and off-path attackers cannot be confused with the live stream.

State on the server (Linux): a SYN creates a mini-socket in the SYN queue (SYN_RECV); the final ACK moves a full socket into the accept queue, where accept() picks it up. If the accept queue is full because the application is slow to call accept(), the kernel drops the final ACK (or the SYN) and the client retransmits — a slow connect with a healthy-looking server, visible as overflows in ss -ltn (Recv-Q vs Send-Q on the listener) and nstat -az TcpExtListenOverflows. SYN floods exploit the SYN queue; SYN cookies avoid storing state until the ACK arrives.

What can go wrong is a diagnostic ladder. No SYN-ACK at all → the client retransmits with exponential backoff (1, 2, 4, 8… s; ~2 minutes total by default on Linux) and reports "connection timed out": the SYN was dropped by a firewall, no route, host down, or the SYN-ACK was lost on an asymmetric return path. RST in reply to SYN → "connection refused", immediately: the host is reachable, no socket listens on that port (or a firewall *rejects* rather than drops). Handshake completes then RST → a stateful middlebox lost state, or the application closed instantly. Each is a different layer, and the client error names which.