a Unix-domain socket

You have met the idea of a socket as the endpoint for talking over a network. A Unix-domain socket is the same socket programming model, but kept entirely inside one machine — no network involved. It is full two-way communication between two local processes, using the very same API (socket(), bind(), listen(), accept(), connect(), send(), recv()) you would use for the network, just with the address family AF_UNIX instead of AF_INET.

Instead of an IP address and port, a Unix-domain socket is addressed by a path in the filesystem, like /run/docker.sock. A server creates the socket, bind()s it to that path (which makes a special socket file appear), listen()s, and accept()s incoming connections; a client connect()s to the same path. Because both ends are on the same kernel, the data never touches a network card or the IP stack — it is just copied through kernel buffers, making it markedly faster and lower-latency than looping a TCP connection back to the same machine. It is the standard way local daemons expose a service: databases, container runtimes, system buses, and display servers all listen on a Unix-domain socket.

Two things make Unix-domain sockets especially powerful for local IPC, beyond mere speed. First, the server can read the connecting client's credentials (its user and process id) straight from the kernel, so it can enforce permissions without the client claiming an identity. Second, and almost magically, two processes can pass an open file descriptor across the socket — the receiver ends up with a working descriptor for a file or socket the sender opened. The honest scope note: a Unix-domain socket only connects processes on the same host. The instant you need to reach another machine, you switch the address family to a network socket — same calls, different world.