The Socket: A Descriptor With Two Kernel Buffers Behind It

int fd = socket(AF_INET, SOCK_STREAM, 0) returns an integer — an index into the process’s File Descriptors table — pointing at a kernel object that is not yet connected to anything. That object owns two byte buffers: a send buffer that write()/send() copies into, and a receive buffer that the network stack fills and read()/recv() copies out of. On Linux each starts around 208 kB (net.core.rmem_default/wmem_default) and TCP autotunes them up to net.ipv4.tcp_rmem’s maximum, 6 MB by default. Everything the application does to a socket is a copy into or out of these buffers; the kernel does the rest asynchronously (Follow send() Through the OS to recv()).

Because it is a descriptor, a socket is subject to everything descriptors are subject to: it is inherited across fork(), closed by close(), counted against ulimit -n, and waited on by select/poll/epoll (I/O Multiplexing: select, poll, epoll, kqueue, IOCP). read() and write() work on it unchanged — Everything Is I/O in its purest form. send()/recv() add flags; sendmsg()/recvmsg() add scatter-gather and ancillary data (this is how a Unix socket passes descriptors).

The socket is the OS’s edge of the The Layer Model: TCP/IP First, OSI as a Map: above it, an application with a byte stream or datagrams; below it, the transport, IP, link and NIC. The rest of the Networking domain lives beneath this one call.

A server names its socket with bind(fd, {addr, port}) — “this socket answers at 0.0.0.0:8080” — and listen(fd, backlog) turns it into a listening socket: a socket that never carries data, only completed connections. From now on the kernel performs the The Three-Way Handshake on the server’s behalf: a SYN arrives, the kernel replies SYN-ACK and parks the half-open connection in the SYN queue; the final ACK arrives and the kernel moves it to the accept queue. The application has not run a single instruction.

accept(fd) takes the oldest completed connection from the accept queue and returns a new descriptor for it. The listening socket stays where it is; the new socket is the one you read and write. A busy server thus has one listening descriptor and thousands of connected ones, which is why C10K: Ten Thousand Connections, Then a Million is about descriptors and buffers, not about listening. The backlog argument caps the accept queue (Linux clamps it to net.core.somaxconn, 4096 since 5.4, 128 before). When the queue is full, Linux by default silently drops the final ACK and the client sees a connection that completed its handshake and then hangs, or retries — Why Can’t I Connect? covers what that looks like from outside.

Restarting a server immediately after stopping it fails with EADDRINUSE because the old connections are in TIME_WAIT (The Connection Lifecycle: Close, Reset, TIME_WAIT, CLOSE_WAIT) and still own the port. setsockopt(SO_REUSEADDR) before bind tells the kernel that binding over TIME_WAIT entries is fine; every production server sets it. SO_REUSEPORT (Linux 3.9+) goes further and lets several processes bind and listen on the same port, with the kernel load-balancing new connections across them — the trick behind multi-process Node cluster alternatives and nginx reuseport.

A client calls socket() and then connect(fd, {server addr, port}). It usually skips bind: the kernel picks an ephemeral port from net.ipv4.ip_local_port_range (32768–60999 on Linux, so about 28,000 per source address) and assigns it. connect blocks until the handshake completes — one round-trip, ~1 ms on a LAN, ~150 ms across an ocean — or, on a non-blocking socket, returns EINPROGRESS and the loop waits for writability.

Once connected, the kernel identifies the connection by its four-tuple (source IP, source port, destination IP, destination port) — plus the protocol, strictly. Every incoming segment is matched against that tuple to find the right socket and the right receive buffer. This is why a single server port can serve millions of connections: 10.0.0.5:8080 is one endpoint, but (client A:41000 → 10.0.0.5:8080) and (client A:41001 → 10.0.0.5:8080) are different tuples and different sockets. It is also why a *client* that opens many connections to one server runs out of ephemeral ports at ~28k, and a NAT (NAT: Many Private Hosts Behind One Public Address) has the same ceiling per public address (the ephemeral-port-exhaustion challenge).

Ports: Addressing a Process, Not a Machine are therefore not “channels” on the machine; they are one field of the key the kernel uses to demultiplex segments to sockets. The listening socket matches on (*, *, local IP, local port); connected sockets match on the full tuple, and the full-tuple match wins.

SOCK_STREAM (TCP) is a connected, ordered, reliable byte stream: send()s and recv()s do not correspond one-to-one, and framing is the application’s job — exactly like a Pipes: A Kernel Buffer Between Two Processes. SOCK_DGRAM (UDP, UDP: Datagrams and the Contract You Choose) is connectionless and message-oriented: each sendto() is one datagram that arrives whole or not at all, possibly reordered, with no listen/accept and no handshake. The receive buffer semantics differ accordingly: a full TCP receive buffer makes the peer stop sending (Flow Control: The Receive Window); a full UDP receive buffer makes the kernel *drop* the next datagram and increment a counter you will never look at (netstat -su, RcvbufErrors).

AF_UNIX sockets keep the whole API — bind to a *path* instead of an address, listen, accept, connect, stream or datagram — but never touch the network stack: the kernel copies directly between the two sockets’ buffers. They are as fast as a pipe, bidirectional, connectable by unrelated processes, and can carry descriptors and the peer’s credentials (SO_PEERCRED). That is why PostgreSQL, MySQL, Docker, systemd, D-Bus and every X11/Wayland display use them for local clients, and why a database connection string with host=/var/run/postgresql is faster than host=127.0.0.1.

ss (the modern netstat) lists sockets straight from the kernel. ss -tlnp shows TCP listeners with their process; ss -tan shows every TCP socket with its state and how many bytes are waiting in the receive (Recv-Q) and send (Send-Q) buffers. Those two columns are the most useful numbers in TCP Debugging: Reading the Handshake on the Wire: a growing Recv-Q means the *application* is not reading; a growing Send-Q means the *peer* is not acknowledging. On a listening socket the columns mean something else — Recv-Q is the current accept-queue length and Send-Q its capacity — so Recv-Q at 4096/4096 on the listener means connections are being dropped before accept().

The other view is from the descriptor side. ls -l /proc/<pid>/fd shows each descriptor as socket:[inode], and that inode is the join key into ss -e or /proc/net/tcp, so you can go from “fd 19 in process 4121” to “the connection to 203.0.113.9:51844 with 1.8 MB unread” and back. That round trip — descriptor → socket → peer → buffer occupancy — is the whole of socket debugging, and it is why this lesson sits between File Descriptors and the Networking domain.