Networking · 28 min read
Ports and Sockets
How transport-layer port numbers multiplex many conversations on one host, and how the socket abstraction turns those numbers into a programming interface.
Why this exists
An IP address only gets a packet to a host (or anycast instance). A host runs many programs at once: browser tabs, DNS caches, game clients, OS updates.
Ports name the receiving and sending endpoints for transport protocols so demultiplexing can finish the delivery. Sockets are the OS abstraction that binds applications to those endpoints.
Without ports, every host could run only one networked program, or every app would invent a private demux scheme inside a single stream. Ports are the small idea that makes multi-service hosts possible.
Axioms & primitives
- 01A port is a 16-bit transport demultiplexing key used by TCP, UDP, and similar protocols.
- 02A conversation is typically identified by a 5-tuple: protocol, source IP, source port, destination IP, destination port.
- 03Listening sockets bind to local addresses and ports; connecting clients usually pick ephemeral source ports.
- 04Well-known ports are conventions for discovery, not cryptographic identity.
- 05Firewalls and NATs key much of their policy and state on ports as well as addresses.
- 06Sockets are the programmer's handle; ports are the on-wire numbers.
Learning objectives
After this lesson you should be able to:
- Explain what problem ports solve that IP addresses alone do not.
- Read a 5-tuple and say which fields identify a TCP connection.
- Contrast a well-known listening port with an ephemeral client port.
- Describe listen/accept/connect at a conceptual level without API trivia overload.
- Predict how two browser tabs avoid mixing bytes from the same server.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Your laptop has one (or a few) IP addresses but dozens of networked programs. When a reply packet arrives, the OS must know whether it belongs to the browser, the game, or the DNS client.
Ports are those sorting labels. Servers advertise a stable listening port by convention (53 for DNS, 443 for HTTPS). Clients pick temporary source ports so many parallel conversations can coexist.
As a programmer, you rarely poke raw port fields. You create a socket, bind or connect, and read/write. Underneath, the 5-tuple keeps your bytes from mixing with someone else's.
Formal shape
TCP and UDP headers carry source and destination ports. Privileged binding to ports below 1024 is an OS policy on many Unix systems, not a network law.
A TCP connection is uniquely identified by its 5-tuple while established. Two clients can use the same destination IP and port because their source ports (or source IPs) differ.
UDP demux is similar but connectionless: the socket API may still present connected UDP sockets as a convenience filter on peer address.
Firewalls express allow/deny rules on ports because services cluster on ports by convention. That convention is also why port scanning is informative and why security should not stop at 'close unused ports.'
Worked examples
Browser to https://example.com: client picks ephemeral source port 52344, destination port 443. Another tab might use 52345 to the same destination. Different tuples, different TCP byte streams.
DNS: stub resolver sends from some high port to resolver:53/UDP. The reply's destination port must match the client's source port or it will not land in the right socket.
SSH on a nonstandard port (e.g. 2222) still speaks SSH; only the discovery convention changed. Security through obscurity is weak, but operationally people move ports to cut noise.
TIME_WAIT and ephemeral port exhaustion: under extreme connection churn, a host can run out of usable local ports. That is a ports-and-sockets resource problem, not an IP shortage.
Edge cases
NAT rewrites ports as well as addresses; logs on both sides may disagree about port numbers.
Port 0 is reserved/special in APIs meaning 'pick an ephemeral port for me.' Seeing port 0 on the wire is a bug.
SCTP and QUIC change demux details (QUIC uses connection IDs beyond classic 5-tuples in some cases) but the need to multiplex remains.
Binding to IPv6 vs IPv4 sockets, dual-stack wildcards, and Docker port publishing all create 'I thought that port was free' incidents. Always ask which address family and interface.
Mental models
Apartment numbers
The building is the IP address. The apartment number is the port. Mail needs both to reach the right resident.
Call center extensions
The company has one phone number (IP). Extensions (ports) reach different desks (services).
Labeled mail slots
The OS sorts arriving segments into slots by destination port (and full tuple for established connections).
Common misconceptions
Myth
Port 443 means the traffic is safe.
Reality
443 is a convention for HTTPS. Attackers can speak TLS or nonsense on 443. Ports are labels, not authenticity.
Myth
Closing a port in a firewall 'deletes the service' on the server.
Reality
It blocks reachability on a path. The process may still listen locally. Different paths may still reach it.
Myth
One process per port always.
Reality
SO_REUSEPORT and multiple acceptors exist; also multiple addresses and protocols. Still, a given bind tuple is constrained.
Myth
Localhost ports are reachable from the internet.
Reality
Binding to 127.0.0.1 keeps a service machine-local. Binding to 0.0.0.0 exposes on all interfaces (subject to firewalls).
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
Why can two browsers on one laptop download from the same server at once without mixing bytes?
What good looks like
Different source ports (and thus 5-tuples) demultiplex separate TCP connections.
Exercise 02
A service listens on 127.0.0.1:8080. A coworker on another machine tries to connect to your LAN IP port 8080. What happens and why?
What good looks like
Not reachable; bound to loopback only. Contrast with 0.0.0.0:8080.
Exercise 03
Write the 5-tuple fields for a UDP DNS query from 192.0.2.10:53001 to 8.8.8.8:53.
What good looks like
proto UDP, src 192.0.2.10, sport 53001, dst 8.8.8.8, dport 53.
Sources & further reading
External references. Prefer primary documents and clear explainers.
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
- Beej's Guide to Network ProgrammingDeep dive
Teaches sockets, bind, listen, and connect with working examples. Use it when ports must become code.
IANA rules for port assignment and registration. Read it when you care about well-known versus ephemeral ports.
Linux socket address families and options overview. Use it as a reference while writing socket code.