Chapter 3: Sockets, Ports, and the Connection Lifecycle

Why this matters

"Port already in use," "connection refused," and "too many open files" are three of the most common networking errors an application engineer encounters directly — and all three only make sense once sockets, ports, and the connection lifecycle are understood precisely. This chapter builds that foundation, directly extending the companion Operating System book's file descriptor and IPC concepts into the networking domain specifically.

The core concept

[BEGINNER] A socket is the OS-level abstraction representing one endpoint of a network connection — from the companion OS book's perspective, a socket is a specific kind of file descriptor (Chapter 12 of that book), which is why sockets are subject to the same per-process descriptor limits as any other open file or pipe. A port is a 16-bit number (0-65535) identifying which application on a machine a piece of traffic is meant for — the IP address gets traffic to the right machine; the port gets it to the right process on that machine.

A connection is uniquely identified by a 4-tuple:
(source IP, source port, destination IP, destination port)

Example: (192.168.1.10, 51234, 93.184.216.34, 443)
This describes ONE specific connection between your machine's ephemeral port 51234
and a server's well-known port 443 (HTTPS) — a different source port means a
DIFFERENT connection, even to the exact same destination.

Well-known ports (0-1023) are reserved by convention for standard services (80 = HTTP, 443 = HTTPS, 22 = SSH, 53 = DNS); ephemeral ports (typically 32768-60999 on Linux, though the exact range is configurable) are temporarily assigned by the OS to the client side of an outgoing connection, freed when the connection closes.

A minimal socket, in Python, to make this concrete

import socket

# Creating a TCP socket (the mechanism underlying the "sockets" from the companion OS book,
# now specifically used for network — not just same-machine — communication).
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # more on this below
server.bind(("0.0.0.0", 8080))  # claims port 8080 on all local network interfaces
server.listen(5)                 # starts accepting connections, with a backlog queue of 5

print("Listening on port 8080...")
conn, addr = server.accept()     # BLOCKS until a client connects (Waiting state, OS book Chapter 2)
print(f"Connection from {addr}")
data = conn.recv(1024)
conn.sendall(b"HTTP/1.1 200 OK\r\n\r\nHello")
conn.close()

import socket

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(("127.0.0.1", 8080)) # OS assigns an ephemeral source port automatically
client.sendall(b"GET / HTTP/1.1\r\n\r\n")
response = client.recv(1024)
print(response)
client.close()

The TCP connection lifecycle: the three-way handshake and beyond

[BEGINNER] Establishing a TCP connection requires a three-way handshake before any actual data is exchanged — this is the direct mechanism behind the Flags [S] seen in Chapter 2's tcpdump output:

Client                                          Server
  |------------ SYN (seq=x) ------------------->|   "I want to connect, my starting sequence is x"
  |<----------- SYN-ACK (seq=y, ack=x+1) --------|   "OK, acknowledged, my starting sequence is y"
  |------------ ACK (ack=y+1) ------------------>|   "Acknowledged — connection established"
  |                                               |
  |========== connection now ESTABLISHED =========|

Only after this handshake completes can actual application data (like an HTTP request) be sent. This is a real, measurable cost — a full round-trip (or more, over an encrypted connection, per Chapter 7) before any useful data moves at all, which is exactly why connection reuse (keeping a TCP connection open across multiple requests, rather than establishing a new one per request) is such a significant performance optimization, covered further in Chapter 6's HTTP/1.1 keep-alive and HTTP/2 multiplexing discussion.

Closing a connection — a four-way process (FIN from each side, ACK'd by the other), and each side that has finished sending (but might still be receiving) enters a TIME_WAIT state for a period after closing, specifically to handle any final, delayed packets from the old connection and ensure they aren't confused with a future connection reusing the same port combination.

The backlog queue, and why SO_REUSEADDR exists

[SENIOR INSIGHT] The listen(5) call above sets a backlog queue size — the number of fully-established connections allowed to wait for the application to call accept() before the OS starts refusing new ones. Under sudden load (a traffic spike), if the application can't call accept() fast enough, this queue fills up, and new connection attempts start failing with connection refused — a very common, very real production symptom directly explained by this specific queue's size and the application's accept() rate, not a mysterious network failure.

SO_REUSEADDR addresses a specific, common annoyance: if a server process restarts quickly (a deploy, a crash-restart), the old socket's address might still be lingering in the OS's TIME_WAIT bookkeeping from the previous process's connections, causing bind() to fail with "address already in use" even though nothing is actually still using it in any meaningful sense — SO_REUSEADDR tells the OS to allow the bind anyway in this specific, safe case.

Common mistakes

1. Confusing "connection refused" (nothing is listening on that port, or the backlog queue is full) with a timeout (nothing responded at all — often a firewall silently dropping packets, or the host being unreachable) — these are different failure modes with different causes and different diagnostic next steps.
2. Not accounting for the three-way handshake's round-trip cost when reasoning about request latency, especially for connections that aren't reused — this cost is invisible in application-level code but very real on the wire, and directly measurable with curl -v's timing breakdown.
3. Hitting a "too many open files" error under load and not recognizing it as the exact same file-descriptor exhaustion pattern from the companion OS book (Chapter 12), just manifesting via sockets specifically — a leaked/unclosed socket connection consumes a file descriptor exactly like a leaked file handle does.
4. Not understanding why a rapidly-restarting server sometimes fails to bind to its own port — the TIME_WAIT state from a very recent previous instance's connections is the usual cause, and SO_REUSEADDR (or an equivalent) is the standard fix.

Checklist: reasoning about sockets and connections in practice

1. Distinguish "connection refused" from "timeout" immediately when diagnosing a failed connection — they point to different layers/causes (refused = something responded negatively; timeout = nothing responded at all).
2. Consider connection reuse (keep-alive, connection pooling) for any code making repeated requests to the same host — avoiding a fresh three-way handshake (and TLS handshake, Chapter 7) per request is a significant, measurable optimization.
3. Treat "too many open files" involving network code as a socket-leak investigation, using the same diagnostic approach as any file descriptor leak (companion OS book, Chapter 12) — find the code path that opens a connection without a corresponding close.
4. Size a server's backlog queue and monitor accept() throughput deliberately for services expecting bursty traffic, rather than discovering the default is insufficient during an actual incident.

Discussion / interview questions

1. "What is a TCP three-way handshake, and why does it matter for performance?" Strong answer: SYN, SYN-ACK, ACK — establishes a connection before any data can be sent, costing at least one full round-trip; this cost is why connection reuse (HTTP keep-alive, connection pooling) is a meaningful optimization, since it avoids paying this cost on every single request.

2. "What's the difference between a 'connection refused' error and a connection timing out?" Strong answer: "Connection refused" means something at the destination actively responded that it's not accepting the connection (nothing listening on that port, or the backlog queue is full); a timeout means no response was received at all within the wait period, often indicating a firewall silently dropping packets or an unreachable host — different causes requiring different diagnostic steps.

3. "How does a socket relate to a file descriptor, and why does that matter for debugging 'too many open files' errors involving network code?" Strong answer: A socket is a specific kind of file descriptor at the OS level, subject to the same per-process descriptor limits as any other open file or pipe — a network-related "too many open files" error is a socket leak, diagnosed the same way as any file descriptor leak (checking for missing close() calls on connections).

4. "What is a connection backlog queue, and what happens when it fills up under load?" Strong answer: The queue of fully-established connections waiting for the application to call accept(); if it fills up (the application isn't accepting fast enough relative to incoming connection rate), new connection attempts are refused — a real, common cause of "connection refused" errors under sudden traffic spikes, distinct from the server being down entirely.

Chapter summary / cheat sheet

• A socket is a file-descriptor-backed endpoint of a network connection; a port identifies which application on a machine traffic is meant for; a connection is uniquely identified by the (source IP, source port, destination IP, destination port) 4-tuple.
• TCP connections require a three-way handshake (SYN, SYN-ACK, ACK) before data flows — a real round-trip cost that connection reuse avoids paying repeatedly.
• "Connection refused" (something actively said no) and "timeout" (nothing responded) are different failure modes with different causes.
• Sockets are file descriptors — network-related "too many open files" errors are the exact same leak pattern as the companion OS book's Chapter 12, just manifesting through unclosed connections specifically.
• A full backlog queue under load causes new connections to be refused, independent of whether the server itself is otherwise healthy.

---