TCP Three-Way Handshake & Connection Lifecycle

The 3-way handshake is required because both sides must independently announce and verify their Initial Sequence Numbers (ISNs) across an unreliable network.

A two-way handshake is insufficient because the server would have no guarantee that the client received its SYN-ACK, which would lead to zombie half-open connections. The asymmetry of the problem:

• Client needs to: (1) send its ISN, (2) receive server's ISN, (3) acknowledge server's ISN
• Server needs to: (1) receive client's ISN, (2) send its ISN + acknowledge client's ISN, (3) confirm client received its ISN

The minimum number of messages to achieve mutual ISN agreement with confirmation is exactly 3. ISNs are randomized using clock-based algorithms (RFC 6528) to prevent TCP Sequence Prediction Attacks where an attacker injects forged data into an existing connection.

When closing a TCP connection with a FIN packet:

• The initiating side enters TIME_WAIT state (typically 60 to 120 seconds, equal to 2 × MSL or Maximum Segment Lifetime).
• Why TIME_WAIT exists:
  1. To allow final ACK packets to reach the server if lost.
  2. To prevent lingering duplicate packets from a previous connection from corrupting a new connection reusing the same port tuple.

The 4-way teardown is necessary (vs 2-way) because each direction is an independent half-connection: the client can say FIN (no more data from me), but the server may still have data to send before issuing its own FIN.

If microservices open a new TCP connection for every single HTTP request without connection pooling, thousands of sockets remain locked in TIME_WAIT. The operating system runs out of ephemeral ports (out of the ~65,000 range), causing all outgoing requests to fail with EADDRNOTAVAIL.

Solution: HTTP Keep-Alive & Connection Pooling. PgBouncer for PostgreSQL, HikariCP for JDBC, and connection pools in Redis clients reuse existing established connections for multiple requests, amortizing the 1-RTT handshake cost across thousands of queries.

SYN Flood Attack: An attacker sends millions of SYN packets with forged source IPs. The server allocates a half-open connection entry in memory for each SYN, waiting for the ACK that never comes (because the source IP is fake). The server's SYN backlog queue fills up, causing legitimate connections to be rejected — this is a classic Denial of Service attack.

SYN Cookies Defense: Instead of allocating memory on SYN receipt, the server encodes the connection parameters (IP, port, timestamp) as a cryptographic hash and embeds it as the ISN in the SYN-ACK. Only when a valid ACK arrives (with the correct ISN+1) does the server allocate memory. This makes the server stateless during the handshake, immune to SYN flood resource exhaustion.

Linux enables SYN cookies automatically when the SYN backlog overflows: net.ipv4.tcp_syncookies = 1.