Foundations · Lesson 05

Network sockets

Under every HTTP request is something humbler: a socket — the actual two-way pipe between two machines. Understanding it explains why connections cost something, why "keep-alive" matters, and what a server really means when it says "too many open connections."

An address plus a door number

To reach a specific program on a specific machine you need two things. The IP address finds the machine — like a building's street address. The port finds the program on it — like an apartment number. A web server typically listens on port 443 (HTTPS); a database might listen on 5432. The pair IP : port is a socket — one specific endpoint of a connection.

A live connection is actually two sockets joined: (your-IP:random-port) ↔ (server-IP:443). That's how one server on port 443 can hold thousands of simultaneous connections — each client uses a different port on its own side, so every pair is unique.

TCP: the reliable handshake

Most APIs run over TCP, which guarantees your bytes arrive in order and intact. To earn that guarantee, TCP opens with a three-way handshake — a quick "can you hear me?" exchange before any real data flows:

That setup is "free" on a fast local network but expensive across the world: a 150 ms round trip means ~150 ms before your request even starts. Now you can see why reopening a connection per request — HTTP/1.0's flaw from Lesson 02 — was so costly.

TCP vs UDP, in one breath

Most APIs want TCP's reliability. UDP shines when a late packet is worthless anyway (a video frame from two seconds ago helps no one). Recall from Lesson 02 that HTTP/3's QUIC is built on UDP and re-adds reliability itself to dodge TCP's head-of-line blocking — a deliberate "rebuild it our way" choice.

Under the hood: the actual socket syscalls and the SYN/SYN-ACK/ACK packets

A "socket" is exposed to your program through a small set of OS system calls. The sequence differs between the server and the client, and understanding it explains every error message you will ever see — from "connection refused" to "address already in use."

Server-side syscall sequence:

// 1. socket() — allocate a socket; returns a file descriptor (fd)
int fd = socket(AF_INET, SOCK_STREAM, 0);
//   AF_INET = IPv4, SOCK_STREAM = TCP  (SOCK_DGRAM for UDP)
//   fd is now just a number — no address, no port yet

// 2. bind() — assign a local IP:port to this socket
bind(fd, {.sin_addr=INADDR_ANY, .sin_port=htons(443)}, sizeof(addr));
//   INADDR_ANY = listen on all interfaces; htons converts host→network byte order
//   "address already in use" (EADDRINUSE) fires here if port 443 is taken

// 3. listen() — mark the socket as passive (willing to accept)
listen(fd, 128);
//   128 = backlog — max SYNs queued before the kernel drops them
//   "SYN flood" attacks saturate this queue

// 4. accept() — block until a client connects; returns a NEW fd for that connection
int client_fd = accept(fd, &client_addr, &client_len);
//   fd is reused for the next accept(); client_fd is the actual pipe to this client
//   each accepted connection consumes one file descriptor from the OS limit

// 5. send() / recv() — exchange data
recv(client_fd, buf, sizeof(buf), 0);  // read the HTTP request
send(client_fd, response, len, 0);     // write the HTTP response

// 6. close() — release the file descriptor; triggers FIN teardown
close(client_fd);

Client-side syscall sequence:

// 1. socket() — same as server: allocate an fd
int fd = socket(AF_INET, SOCK_STREAM, 0);
//   client does NOT call bind(); the OS picks a free ephemeral port (49152-65535)

// 2. connect() — initiate the TCP three-way handshake
connect(fd, {.sin_addr=server_ip, .sin_port=htons(443)}, sizeof(addr));
//   kernel sends SYN; blocks until SYN-ACK received; kernel sends ACK; returns
//   "connection refused" (ECONNREFUSED) = server sent RST (nothing listening)
//   "connection timed out" (ETIMEDOUT) = no reply at all (firewall drops SYN)

// 3. send() / recv() — same as server side
send(fd, request, len, 0);
recv(fd, buf, sizeof(buf), 0);

// 4. close() — sends FIN; server ACKs; server FIN; client ACKs (4-way teardown)
close(fd);

The SYN/SYN-ACK/ACK exchange at the packet level — here is what tcpdump actually shows during a handshake to port 443:

The sequence numbers (seq/ack) are how TCP detects lost packets and reassembles segments in order. The client's initial seq is random (prevents old packets from prior connections being mistaken for new ones). Each ACK is next expected byte = other side's seq + 1.

How to debug & inspect it

Three tools cover almost every socket-level problem you will encounter: ss (socket statistics — the modern replacement for netstat), lsof (which process owns which fd), and tcpdump (the raw packet view).

Connection error symptom-to-cause-to-fix table:

Debug checklist:

1. Start with ss -lntp — confirm the service is listening on the expected port and interface.
2. If "connection refused": the service is not listening. Check if the process is running; check the port in config.
3. If "timed out": the port is being filtered. Use traceroute and check firewall rules.
4. If "too many open files": run lsof -p <pid> | wc -l to count fds; check for socket leaks with ss -ntp | grep <pid>.
5. For a detailed handshake trace: tcpdump -i any -n "host <ip> and port <port>" — look for RST (refused/reset) or lone SYNs with no reply (filtered).
6. High TIME_WAIT count is usually benign but can exhaust ephemeral ports; check with ss -nt state time-wait | wc -l.

By the numbers

Concrete scenario: a Node.js service calls an upstream REST API. Round-trip time (RTT) between the two hosts is 50 ms. TLS 1.3 is in use. The service makes 2,000 req/s at peak with an average upstream latency of 50 ms per call (once connected).

What a new connection actually costs

Opening a fresh HTTPS connection requires two sequential handshakes before a single byte of application data can flow:

(RFC 8446 §2 — TLS 1.3 handshake overview)

Without pooling: 1,000 sequential calls pay setup 1,000 times

Connection reuse turns 150 seconds of wall time into 50 seconds — a 3× speedup with zero code change to the business logic.

Pool sizing via Little's Law

How many connections should the pool hold? Exactly the number in flight at peak — which is Little's Law (L = λ · W) applied to the upstream call:

This is the canonical formula used by every connection-pool library (HikariCP, pg, pgx, SQLAlchemy pool). (HikariCP — About Pool Sizing)

Worked connection-lifecycle trace

Service starts cold at 08:00:00. Pool max = 100 connections, RTT = 50 ms, upstream latency = 50 ms.

Decision math — pool size and the "too many open files" ceiling

The pool has a hard upper bound: the OS file-descriptor limit per process. A typical Linux default is 65,536 fds per process. Each open socket consumes one fd. A service holding connections to K upstream services with P connections each uses K × P fds just for connection pools:

The decision rule: set pool_max = ceil(peak_QPS × avg_latency_s) × 1.25 (25% headroom), verify it fits within the fd ceiling, and set keepalive-idle timeout to be shorter than any upstream or load-balancer timeout (typically 55 s when the upstream has a 60 s idle timeout — a 5-second margin prevents surprise RSTs). (RFC 9293 §3.3.2 — TCP keepalive)

Sources & further reading

• Beej's Guide to Network Programming (sockets, hands-on)
• MDN — TCP · RFC 9293 — TCP
• MDN — UDP