Linux Sockets & IPC

The Object Model

A socket is not a network thing. It is a file descriptor backed by a protocol state machine. TCP over a NIC, a Unix socket under /run, a netlink channel to the routing table and a vsock to a guest are the same kernel object wearing different ops tables. Three structs stack up: struct file is what your fd indexes, struct socket is the generic VFS-facing layer, and struct sock is the protocol control block holding the queues, timers and wakeup callbacks.

   user space              kernel
   fd 3 --+
          |  fdtable[3] -> struct file   f_op = socket_file_ops
          +---------------+
                          v
                   struct socket   VFS view: type, state, .ops
                          |        .ops = inet_stream_ops | unix_stream_ops
                          v
                   struct sock     sk_receive_queue, sk_write_queue,
                          |        sk_backlog, timers, sk_data_ready
                          v
                   tcp_prot | udp_prot | unix_proto | netlink_proto

   one shape, four dispatch tables - the family only changes the bottom row

Sockets live in sockfs, an internal filesystem, which is why they carry an inode number you can see in ss -e and /proc/net/unix but have no path unless you bind one. Because a socket is a struct file, everything that works on files works on it: dup() shares it, fork() inherits it, epoll watches it beside a timerfd in the same interest set. That uniformity is the actual design win behind "everything is a file descriptor".

Families & Types

The family picks the namespace and the stack. The type picks the delivery contract. They are orthogonal, and half the confusion in this area comes from treating SOCK_DGRAM as a synonym for UDP.

creation, correctly// OR the flags into type: no fork race between socket() and fcntl()
int fd = socket(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK | SOCK_CLOEXEC, 0);

// same for the accept side - accept4(), never accept() + fcntl()
int c = accept4(lfd, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC);

// a preconnected bidirectional pair, no namespace at all
int sv[2];
socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, sv);

The Syscall Arc

The classic sequence hides two queues, and those queues are where a service either sheds load gracefully or falls over silently.

   client                          server
   socket()                       socket() + setsockopt(SO_REUSEPORT)
      |                           bind() + listen(backlog)
   connect() --- SYN ------------>  [ SYN queue ]   tcp_max_syn_backlog
      |     <-- SYN+ACK ---------       |
      |     --- ACK ------------->  [ accept queue ]  min(backlog, somaxconn)
   ESTABLISHED                          |  accept4() pops one
                                        +--> connected fd (a NEW struct socket)

   accept queue overflow: the ACK is dropped silently, TcpExtListenOverflows++

Two backlogs, two failure modes. The SYN queue holds half-open request_socks; its overflow triggers SYN cookies if tcp_syncookies is on. The accept queue holds fully established connections your process has not yet accepted, bounded by min(backlog, net.core.somaxconn). On overflow the kernel drops the client's ACK silently, so the client sits in ESTABLISHED sending data to a server that has no idea the connection exists. tcp_abort_on_overflow=1 sends an RST instead: honest, but sheds harder. somaxconn was 128 for two decades and moved to 4096 in 5.4, and plenty of running boxes still carry the old value.

Unix Domain Sockets

AF_UNIX is not "TCP over loopback with a shorter path". No IP header, no checksum, no congestion control, no retransmit timer, no port space. A write copies into the peer's receive queue and wakes it. What you give up is routability. What you get back is three capabilities no IP socket has.

Naming: two namespaces, two scopes

That asymmetry decides which one crosses a container boundary: a pathname socket follows the mount namespace (bind-mount it in), an abstract name follows the netns. A stale socket file is the classic restart failure, since bind() returns EADDRINUSE on the leftover inode and a connect() to it returns ECONNREFUSED rather than ENOENT, which reads as a live-but-broken server.

Passing file descriptors

sendmsg with an SCM_RIGHTS control message moves an open fd into another process. The receiver gets a new fd number pointing at the same struct file, sharing the offset and status flags. This is capability passing: a privileged process opens a socket, a device or a memfd, hands it across, drops privileges, and the receiver uses something it could never have opened itself.

   proc A                                   proc B
   fd 7 -> struct file X
     |  sendmsg(msg_control = SCM_RIGHTS [7])
     +---------> [ AF_UNIX ] ---------> recvmsg(MSG_CMSG_CLOEXEC)
                                            fd 9 -> struct file X  (same offset)

   in-flight fds hold a refcount; unix_gc() reaps sockets that only reference each other

SCM_RIGHTS, the whole dancechar buf[CMSG_SPACE(sizeof(int))] = {0};
struct iovec io = { .iov_base = "x", .iov_len = 1 };   // must send >= 1 real byte
struct msghdr m = { .msg_iov = &io, .msg_iovlen = 1,
                     .msg_control = buf, .msg_controllen = sizeof buf };

struct cmsghdr *c = CMSG_FIRSTHDR(&m);
c->cmsg_level = SOL_SOCKET;
c->cmsg_type  = SCM_RIGHTS;
c->cmsg_len   = CMSG_LEN(sizeof(int));
memcpy(CMSG_DATA(c), &fd_to_send, sizeof(int));
sendmsg(sock, &m, 0);

// receiver: ALWAYS MSG_CMSG_CLOEXEC, and check msg_controllen before trusting the count
recvmsg(sock, &m, MSG_CMSG_CLOEXEC);

Credentials the kernel vouches for

Buffers & Backpressure

Both directions are bounded queues, and those bounds are the flow control. send() copies into the send buffer and returns; that means the kernel took custody, not that anything was delivered. When the buffer fills, a blocking socket sleeps and a nonblocking one returns EAGAIN. That moment is the only backpressure signal your application ever gets. Ignoring it is how you grow an unbounded userspace queue and turn a slow consumer into an OOM kill.

   app --write()--> [ sk_write_queue ] --> qdisc --> NIC --> wire
                       ^ full = EAGAIN = the only backpressure you get

   wire --> NIC --> softirq --> [ sk_receive_queue ] --read()--> app
                                   ^ full = shrinking advertised window = sender stalls

   BDP = rate x RTT   |   10 Gb/s at 30 ms needs ~37.5 MB in flight to fill

Nagle plus delayed ACK remains the most common self-inflicted latency bug: the sender holds a small trailing segment waiting for an ACK, the receiver holds the ACK waiting for data to piggyback on, and you eat up to 40 ms per exchange. The real fix is writing a complete message with one sendmsg or a writev, so there is no small trailing segment to hold. TCP_NODELAY is the belt to that suspenders.

Removing copies, one layer at a time

Readiness & epoll

This is the one place where the API generations are genuinely different algorithms rather than different spellings. select and poll are stateless: you hand the kernel the whole set every call, it walks the set, you walk the result. Cost is linear in watched descriptors no matter how few are active, and select additionally caps at FD_SETSIZE (1024) with a bitmap that corrupts memory above it. epoll is stateful: the interest set lives in the kernel and the cost is linear in ready descriptors.

   epfd
    +-- interest set : rb-tree keyed by (fd, struct file)   epoll_ctl ADD/MOD/DEL
    +-- ready list   : doubly-linked list of epitems        epoll_wait drains
             ^
             | ep_poll_callback() links the epitem when the wait queue fires
   sk_data_ready() -> wake_up(sk_sleep) -> callback

   register O(log n) · wakeup O(1) · wait O(ready), not O(watched)

edge-triggered accept loop, the only correct shape// EPOLLET + nonblocking + drain-to-EAGAIN is ONE indivisible pattern.
// Using two of the three is a hang, not a slowdown.
ev.events = EPOLLIN | EPOLLET | EPOLLEXCLUSIVE;
epoll_ctl(ep, EPOLL_CTL_ADD, lfd, &ev);

for (;;) {
    int n = epoll_wait(ep, evs, MAXEV, -1);
    for (int i = 0; i < n; i++) {
        for (;;) {                                  // drain, always
            int c = accept4(lfd, NULL, NULL, SOCK_NONBLOCK|SOCK_CLOEXEC);
            if (c < 0) {
                if (errno == EAGAIN) break;          // queue empty: NOW you may wait
                if (errno == EINTR)  continue;
                break;
            }
            register_conn(ep, c);
        }
    }
}

io_uring is a different model again: two shared-memory rings, submission and completion, so a batch of operations is issued and reaped with zero syscalls once IORING_SETUP_SQPOLL has a kernel thread polling the submission side. It expresses the operation rather than readiness, and supports multishot accept and receive, provided buffer pools, and registered files and buffers.

The IPC Toolbox

Sockets are the general answer, not always the right one. Roughly ordered by how often the answer is actually this:

Pipes are a circular buffer of pages, 64 KiB (16 pages) by default and resizable with F_SETPIPE_SZ up to /proc/sys/fs/pipe-max-size. Writes up to PIPE_BUF (4096) are atomic against interleaving from other writers, which is a real guarantee worth using for multi-writer line logs and worthless above that size.

Shared memory is the only mechanism with no per-message kernel involvement at all, which makes it both the fastest and the most dangerous. A single-producer single-consumer ring in a memfd with futex wakeups on the empty and full transitions gets sub-microsecond handoff, and you now own memory ordering, cache line alignment, false sharing, and the fact that a crashed peer leaves the structure exactly as it was mid-write. Robust futexes and sequence-number protocols exist for that.

memfd + seals + fd passing: the modern shmint fd = memfd_create("ring", MFD_CLOEXEC | MFD_ALLOW_SEALING);
ftruncate(fd, SZ);
void *p = mmap(NULL, SZ, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

// freeze the size so the receiver can trust it; trusting contents would need F_SEAL_WRITE
fcntl(fd, F_ADD_SEALS, F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_SEAL);
send_fd(uds, fd);            // SCM_RIGHTS; refcount handles cleanup, no ipcrm ever

Choosing a Transport

Order-of-magnitude figures, commodity x86, single hop, small messages. Ratios, not absolutes: NUMA placement, C-states and whether the pair shares an L3 move every row substantially.

• Cross host? TCP or QUIC. The question is settled, spend your effort on buffers and framing.
• Same host, request and response? AF_UNIX SOCK_SEQPACKET, or a length-prefixed stream. Credentials and fd passing come free.
• Same host, bulk data? Shared memory for the payload, a Unix socket alongside it for control and wakeups. This is what Wayland, PipeWire and the GPU stacks do.
• Might move off-box later? Loopback TCP, deliberately, so the code path is identical. That is the only good reason to pay for it.

Instrumentation & Forensics

ss replaced netstat and exposes far more of struct sock than the old tool ever did. These are the flags worth muscle memory.

ss, the useful subsetss -tanp                  # tcp, all states, numeric, with owning process
ss -lnt                   # listeners: Recv-Q = pending accepts, Send-Q = backlog max
ss -i                     # rtt, cwnd, retrans, bytes_acked, pacing rate
ss -m                     # skmem: rmem_alloc, rcv_buf, wmem_alloc, snd_buf, drops
ss -x -p                  # unix sockets: path, peer inode, process
ss -e                     # the sockfs inode - joins to /proc/net/unix and lsof
ss -tn state time-wait     # state filters take an expression, not just a flag

# the four counters that explain most mysteries (deltas, not totals)
nstat -az | grep -E 'ListenOverflows|ListenDrops|BacklogDrop|Syncookies'

   reference: socket(7) unix(7) tcp(7) epoll(7) pipe(7) cmsg(3) memfd_create(2)
   source   : net/socket.c · net/unix/af_unix.c · fs/eventpoll.c · net/ipv4/tcp.c
   docs     : Documentation/networking/{ip-sysctl,msg_zerocopy}.rst
   books    : Kerrisk TLPI ch.43-61 · Stevens UNP vol.1 & vol.2