Opening and Closing TCP Connections

Before any data flows, TCP establishes the connection with three segments:

Why three steps instead of two? Both sides need to agree on two things: the client’s ISN and the server’s ISN. A two-step handshake would let the server accept without the client confirming the server’s ISN. The third step completes the exchange.

The initial sequence numbers are chosen randomly (not starting from zero) to prevent segments from old, defunct connections from being mistaken for segments belonging to a new connection on the same port. If every connection started at sequence number zero, a delayed packet from a previous connection could be accepted as valid data in the current one.

What happens when the server does not respond to the SYN? The client waits, retransmits the SYN after a short delay, and retransmits again with increasingly longer delays. After several retries spanning a total of roughly 30 to 75 seconds (depending on the operating system), the connection attempt gives up and your application receives a timeout error.

This is the error you see when connecting to a host that is unreachable, firewalled, or simply not running a server on the target port. The long delay before the error appears is TCP being patient — giving the network every chance to deliver the SYN.

If the server is reachable but nothing is listening on the port, the response is faster: the server immediately sends a RST (reset) segment, and your application gets a "connection refused" error within milliseconds.

Closing a TCP connection takes four segments because each direction of the stream is shut down independently:

In practice, the server’s ACK and FIN are often combined into a single segment, reducing the exchange to three segments. But logically, the four steps reflect two independent half-closes.

Because each direction is closed separately, it is possible to shut down sending while still receiving. This is called a half-close.

Consider an HTTP client that sends a request and then calls shutdown(SHUT_WR) on its socket. This sends a FIN to the server, signaling that the client is done writing. But the client’s receive side remains open. The server sees the FIN, knows no more request data is coming, processes the request, sends the response, and then closes its end.

Half-close is useful in protocols where the client needs to say "I am done sending, but keep your response coming." Without it, the server would have no way to distinguish "the client is done" from "the client is still thinking."

A TCP connection passes through a series of states from creation to destruction. Understanding these states is the key to diagnosing connection issues:

After both sides have exchanged FINs and ACKs, you might expect the connection to disappear immediately. Instead, the side that initiated the close enters TIME_WAIT and holds the socket open for a period called 2MSL (twice the Maximum Segment Lifetime, typically 60 seconds).

TIME_WAIT exists for two reasons:

The practical consequence is the dreaded "address already in use" error. If your server shuts down and immediately restarts, it cannot bind to the same port because the old connections are still in TIME_WAIT. The standard solution is to set the SO_REUSEADDR socket option before binding, which tells the OS to allow binding to a port that has connections in TIME_WAIT.

A RST (reset) segment is the emergency stop. It terminates the connection immediately, without the graceful FIN exchange. The receiving side sees an error on the socket — typically "connection reset by peer."

RST is sent in several situations:

RST segments are not acknowledged. Once sent, the connection is destroyed. Any unsent or unacknowledged data is discarded.

During the three-way handshake, each side advertises its Maximum Segment Size (MSS) — the largest chunk of data it can receive in a single TCP segment. This is communicated as a TCP option in the SYN and SYN-ACK segments.

The MSS is typically set to the local interface’s MTU minus the IP and TCP header sizes. For an Ethernet link with a 1500-byte MTU, the MSS is usually 1460 bytes (1500 - 20 bytes IP header - 20 bytes TCP header).

Negotiating the MSS helps TCP avoid IP fragmentation. If both sides know the largest segment the other can handle, TCP can size its segments to fit without requiring IP to split them.

A TCP server uses two kinds of sockets:

The listening socket is bound to a well-known port and calls accept() in a loop. Each call to accept() blocks until a client connects, then returns a connected socket dedicated to that client.

The listening socket is never used for data transfer. It exists solely to create connected sockets. The connected socket carries all the data for a single client conversation. When the conversation ends, the connected socket is closed, but the listening socket remains, ready for the next client.

A server handling multiple clients simultaneously needs a strategy for managing many connected sockets. Options include spawning a thread per connection, using an event loop with non-blocking I/O, or — as Corosio provides — using coroutines that co_await on socket operations. The mechanism differs, but the pattern is the same: one listening socket, many connected sockets, each managed independently.

The TCP connection lifecycle is not academic trivia. It is the explanation behind errors you will see regularly:

The next section looks at what happens during the ESTABLISHED state — how TCP actually moves your data across the connection efficiently.