What exactly is a socket, and how does it let programs communicate?

Sockets can also be used between processes on the same machine. Unix-domain sockets use a local filesystem path as their address instead of an IP address and port. They behave much like network sockets, but avoid the network stack and can use filesystem ownership and permissions for access control. A listening server can accept multiple clients and handle each connection separately.

For network communication, an endpoint is commonly identified by an address and a port, such as 192.0.2.10:443. A server usually creates a socket, binds it to a local address and port, and listens for connections. A client creates its own socket and connects to the server. With TCP, the connection provides an ordered, reliable byte stream. With UDP, messages are sent as separate datagrams, with less overhead but no built-in guarantee that they will arrive or arrive in order.

On Unix-like systems, sockets are treated similarly to files because the kernel represents them with file descriptors. You can pass that descriptor to operations such as read, write, send, and receive, but a socket is not normally for storing data on disk. Data written to it is placed in a kernel buffer and is consumed when the other side reads it.

A simple analogy is a telephone system: the socket is one endpoint, the address and port identify where to reach it, and connect or accept establishes the conversation. After that, both programs exchange bytes through the socket. The socket API hides the lower-level details of moving those bytes between processes or machines.

A socket is a kernel-managed communication endpoint. It gives a program a way to exchange data with another program, either on the same computer or across a network. Programs typically create a socket, then use operations such as connect, listen, accept, send, and receive. The operating system keeps track of the underlying buffers, connection state, addresses, and permissions.