Networking · foundation

Port and socket

A port is a 16-bit number in a transport protocol such as TCP or UDP. A socket is a kernel communication object that a process usually accesses through a file descriptor. An internet socket can bind to a local protocol, IP address, and port; a connected TCP socket also records the remote address and port.

Why it matters

Diagnosing a connection requires separating name resolution, IP routing, port selection, bind scope, and socket state. A host can be reachable while no matching socket is listening, and a completed TCP handshake still does not prove the intended application is healthy.

Mental model

How to reason about port and socket

DNS may map a name to an IP address; IP gets packets to a host or interface; then TCP or UDP plus the destination port selects a matching socket. A listener is bound to a local endpoint. Each accepted TCP connection becomes a separate socket identified by its protocol and local and remote IP/port pairs.

Analogy

An IP address is a building address and a port is a numbered service desk. A listening socket is the staffed reception desk; each accepted TCP connection is a separate conversation, even though every visitor arrived through the same desk number.

Examples

See the boundary, not just the happy path

Worked example · List listening TCP sockets

ss -ltnp

On Linux, ss shows numeric TCP listeners, their bound local addresses and ports, and available process details. Seeing another user's process information may require additional privileges.

Worked example · Inspect established connections

ss -tn state established

Each row shows a connected TCP socket with local and peer endpoints. Many rows can share the same local server port because their remote addresses or ephemeral ports differ.

Worked example · Many clients share one server port

192.0.2.20:53144 → 198.51.100.10:443
192.0.2.21:61002 → 198.51.100.10:443

Both clients connect to server port 443, but their source address and ephemeral source port make the established TCP connections distinct.

Worked example · Test a TCP endpoint

nc -vz example.com 443

Common netcat implementations attempt a TCP connection to port 443. Success means some endpoint completed the handshake; it does not prove valid HTTPS, a healthy application, or a successful request through every backend.

Useful contrast · Same number, different transport namespace

UDP port 53 and TCP port 53

TCP and UDP maintain distinct port spaces and socket semantics. DNS commonly uses both, so a UDP listener on 53 does not itself create a TCP listener on 53.

Useful contrast · Loopback bind versus wildcard bind

127.0.0.1:8000  vs  0.0.0.0:8000

The first IPv4 bind accepts only traffic addressed through loopback; the wildcard bind can accept traffic addressed to local IPv4 interfaces. Firewall and routing rules still determine actual reachability.

Common mistakes

Misconceptions to remove early

Assuming one port permanently belongs to one application

Service registries provide conventions, not ownership. Binding depends on the current host, address, protocol, permissions, and existing sockets; services can also use non-default ports.

Treating a port as a complete endpoint

Port 443 alone does not identify a socket. The transport protocol and local address matter, and an established TCP connection is further distinguished by its remote address and port.

Assuming one connection consumes the server port

A TCP listener can accept many clients on the same local port. The kernel creates a connected socket for each accepted client and distinguishes connections using local and remote endpoint information.

Applying TCP's handshake model to UDP

UDP is connectionless and has no TCP-style handshake proving that a peer application is ready. A lack of response can mean filtering, packet loss, an application choice, or no listener.

Treating a successful TCP connect as an application health check

It proves that some TCP endpoint completed the handshake. The listener can still speak the wrong protocol, reject the request, or fail during application processing.

Quick check

Can you predict the result?

1. Which set best identifies one side of an internet transport conversation?
  • • Transport protocol, IP address, and port
  • • PID and filesystem inode only
  • • Domain name and URL fragment only
Answer: Transport protocol, IP address, and port
2. Why can TCP and UDP both use port 53 on the same IP address?
Answer: TCP and UDP have separate transport namespaces and separate sockets.
3. Why can thousands of clients connect to one server's TCP port 443 at the same time?
Answer: Each accepted connection has its own socket and a distinct combination of local and remote IP addresses and ports, even though the server port is shared.
4. What is the difference between a listening TCP socket and an accepted TCP socket?
Answer: The listener waits on a local endpoint for new connections; accept creates a connected socket for one client while the listener remains available for others.

Keep building

Related concepts

IP address and network interfaceNetworking from the TerminalTCP vs UDPNetworking from the TerminalFile descriptorProcesses & FilesystemsLocalhost and loopbackNetworking from the Terminal

Put the concept to work

Practical guides that use this mental model

Connection refused vs timed out vs no route to host9 min systems guideHow to find the process listening on a port8 min systems guideWhy localhost works on the host but not in Docker9 min systems guide

Authoritative references

Make the idea retrievable.

Concepts are coming to Terminaster in the next update. You'll be able to study this one with spaced repetition, next to the commands where you use it.

Get Terminaster