Sockets and Ports

A socket is the kernel's endpoint for communication. For TCP and UDP it is identified by an address and a port — 0.0.0.0:443, 10.0.0.42:5432 — and the kernel uses that pair to decide which process receives an arriving packet. A port on its own is just a 16-bit number from 1 to 65535; it means nothing until a process binds a socket to it and tells the kernel "deliver traffic for this port to me." When you say a service is "listening on 443," you mean it created a socket, bound it to port 443, and called listen().

The operational consequence is that almost every "the service is down" page starts here. Before you blame DNS, routing, or the firewall, you ask one question: is the process actually running and bound to the address and port you expect? One command — ss -tlnp — answers it, showing every listening TCP socket, the exact address it is bound to, and the PID that owns it. Half of all connectivity incidents end the moment you read that output, because the answer is "nothing is listening there" or "it is bound to the wrong address."

Ports, Sockets, and the 4-Tuple

A listening socket is half-specified: it has a local address and port but no peer. When a client connects, the kernel creates a second, fully-specified socket for that connection — and what makes it unique is the 4-tuple: source IP, source port, destination IP, destination port. This is why a single listening socket on :443 can serve thousands of simultaneous connections. Each connected client has a different source IP or source port, so each 4-tuple is distinct, and the kernel demultiplexes incoming packets to the right connection by matching all four values. The listening socket itself never carries data; it only spawns connected sockets.

TCP and UDP differ in what a socket means. A TCP socket is connection-oriented: listen() then accept() establishes a stateful session with a handshake, and the kernel tracks its state through to teardown. A UDP socket is connectionless — there is no LISTEN state and no per-connection socket, just a single bound socket that receives datagrams from anyone. That is why ss shows UDP sockets as UNCONN rather than LISTEN: there is nothing to listen for. Ports below 1024 are privileged — a process needs CAP_NET_BIND_SERVICE (or root) to bind them — which is why a web server binding 80 or 443 either starts as root and drops privileges, or is granted the capability explicitly.

ss in Practice

The tool is ss from iproute2. It replaced netstat from the deprecated net-tools package: ss reads socket state directly from the kernel over Netlink instead of parsing /proc/net line by line, so it is faster on a busy host with tens of thousands of sockets and it reports more state. The flags worth committing to memory are -t (TCP), -u (UDP), -l (listening only), -n (numeric — do not resolve ports to service names or addresses to hostnames), and -p (show the owning process, which requires root to see other users' sockets).

# Every listening TCP socket, numeric, with the owning process
sudo ss -tlnp
# Typical output
State   Local Address:Port   Peer Address:Port  Process
LISTEN  127.0.0.1:5432       0.0.0.0:*          users:(("postgres",pid=812,fd=5))
LISTEN  0.0.0.0:443          0.0.0.0:*          users:(("nginx",pid=1190,fd=6))
LISTEN  [::]:22              [::]:*             users:(("sshd",pid=701,fd=3))

Read that output as three facts per line: what state the socket is in, the address and port it is bound to, and who owns it. Postgres above is bound to 127.0.0.1:5432 — loopback only, reachable from this host and nowhere else. Nginx is on 0.0.0.0:443 — every IPv4 interface. SSH on [::]:22 is the IPv6 wildcard, and on a dual-stack Linux box that single socket usually accepts IPv4 too via mapped addresses. To see established connections instead of listeners, drop the -l; to filter, ss takes expressions like ss -tn state established '( dport = :443 )' or ss -tnp dst 10.0.0.5.

Bind Address Pitfalls

The single most common "works locally, fails remotely" cause is a service bound to 127.0.0.1 instead of 0.0.0.0. Binding to 127.0.0.1 attaches the socket to the loopback interface alone: the process is up, the port is open, curl localhost on the box succeeds — and every connection from another machine is refused at the kernel before the application ever sees it, because no socket is bound to the interface the packet arrived on. Binding to 0.0.0.0 attaches to all IPv4 interfaces; binding to a specific address like 10.0.0.42 attaches to exactly that interface and is the right choice when a host has a public and a private NIC and the service should only answer on one.

The fix is in the application's own config, not the network. Postgres has listen_addresses, MySQL has bind-address, an app server has a host flag — defaults frequently ship as 127.0.0.1 for safety. Confirm with ss -tlnp: if the Local Address column reads 127.0.0.1 when you expected 0.0.0.0, you have found the fault, and no amount of firewall or routing work will help until the bind address changes.

Connection States

Every TCP socket moves through a state machine, and four states show up constantly in ss -tan output. Reading them correctly separates a non-problem from a real bug.

The two that get misread are TIME_WAIT and CLOSE_WAIT, and they mean opposite things. Thousands of sockets in TIME_WAIT after a load test is expected: whichever side closes the connection first holds the socket for roughly 60 seconds (twice the maximum segment lifetime) so that delayed packets from the finished connection cannot be misdelivered to a new one reusing the same 4-tuple. It is not a leak and it clears on its own; the kernel reuses these efficiently and the historical net.ipv4.tcp_tw_reuse knob is rarely needed. CLOSE_WAIT is the alarm. It means the remote end closed the connection but your application never called close() on its file descriptor, so the socket sits forever. A growing CLOSE_WAIT count is a file-descriptor leak that will eventually exhaust the process's ulimit -n and cause "too many open files" — the bug is in the application code, not the kernel.

Unix Domain Sockets

Not every socket has a port. A Unix domain socket is a local-only endpoint addressed by a filesystem path — /run/postgresql/.s.PGSQL.5432, /var/run/docker.sock — or by an abstract name, and it never touches the network stack. Two processes on the same host talk through it directly via the kernel, skipping TCP/IP entirely, which is faster and means the connection cannot be reached from another machine no matter how the firewall is set. This is why Postgres, MySQL, and the Docker daemon all expose a Unix socket alongside (or instead of) a TCP port: local clients get lower latency and access is governed by ordinary filesystem permissions on the socket file rather than by network rules.

You list them with ss -xlnp (the -x selects Unix sockets). The practical consequence for debugging is that a client failing to connect over a Unix socket is a different problem from a network failure: there is no port, no bind address, and no firewall involved — the usual culprits are the wrong socket path or filesystem permissions denying the client access to the socket file. When a tool defaults to the Unix socket and you want TCP, you generally have to pass an explicit host (psql -h 127.0.0.1 rather than letting psql reach for the local socket).