Ports

1What a Port Actually Identifies

An IP address (see the IP/IPv4/IPv6 topic) gets a packet to the right host. But a host runs dozens of processes at once — a web server, a database, an SSH daemon — often all listening for network traffic simultaneously. A port is a 16-bit number that tells the transport layer (TCP or UDP — see the TCP vs UDP topic) which process on that host a packet is for.

IP address  → which HOST
Port number → which PROCESS on that host

Ports are a transport-layer concept, not a network-layer one — IP itself doesn't know or care about ports; TCP and UDP headers are what actually carry the source and destination port numbers.

2The Port Number Range and Its Bands

Ports are 16-bit unsigned integers, so they range from 0 to 65535 (2¹⁶ = 65536 total values). This range is split into three conventional bands:

Common well-known ports worth memorizing on sight:

20/21  FTP (data/control)
22     SSH
25     SMTP
53     DNS
80     HTTP
443    HTTPS
3306   MySQL
5432   PostgreSQL
6379   Redis
27017  MongoDB

3Client Ports vs Server Ports

When your browser connects to https://example.com, two ports are involved, and they play very different roles:

• Server port (443): fixed, well-known, and the server is actively listening on it, waiting for any client to connect.
• Client port (an ephemeral port, e.g. 51344): chosen automatically by the client's operating system for this one connection, from the ephemeral range, and released when the connection closes.

This asymmetry is why you never have to "know" what port your browser is using — the OS picks a free ephemeral one for you on every outgoing connection, while the server's port has to be fixed and known in advance so clients can find it at all.

4Sockets: A Port Alone Doesn't Identify a Connection

A single port number identifies "which process," but a live TCP connection is uniquely identified by a 4-tuple:

(source IP, source port, destination IP, destination port)

This is why a busy web server on port 443 can handle thousands of simultaneous connections through the same port — every one of those connections has a different client IP and/or client port, so the 4-tuple is unique per connection even though the server-side IP and port are identical every time. The operating system uses this 4-tuple (called a socket, in this context) to route incoming packets to the correct in-memory connection state.

Connection A: (198.51.100.7:51344 → 203.0.113.10:443)
Connection B: (198.51.100.9:51344 → 203.0.113.10:443)   ← different client IP, same client port — still unique
Connection C: (198.51.100.7:51400 → 203.0.113.10:443)   ← same client IP, different client port — still unique

5TCP Ports and UDP Ports Are Independent Namespaces

A subtlety that trips people up: TCP port 53 and UDP port 53 are completely separate. A process can bind TCP port 53 and a different process can simultaneously bind UDP port 53 on the same host, with no conflict — the protocol is part of what identifies the listener, not just the number. DNS actually does exactly this in practice (using UDP:53 for typical queries and TCP:53 for larger responses like zone transfers).

⚠️ Common Pitfalls

1. Thinking a port is a physical thing — a port is purely a number in a packet header; there is no separate "wire" per port. All 65536 possible ports for a given host share the exact same physical network interface.
2. Assuming TCP and UDP ports are the same namespace — binding UDP port 53 has zero effect on whether TCP port 53 is free; they are tracked completely independently by the OS.
3. Believing the client always uses the same source port for every connection — the OS typically assigns a fresh ephemeral port per outgoing connection; assuming a fixed client port breaks under NAT (see the NAT/DHCP/ARP topic) and under connection reuse scenarios.
4. Confusing "port is closed" with "port is filtered" — a closed port (nothing listening) typically gets an active RST reply; a filtered port (blocked by a firewall — its own topic) typically gets no reply at all, which is why a port scan can take much longer against a well-firewalled host — it's waiting out timeouts on filtered ports instead of getting an instant RST.
5. Forgetting TIME_WAIT can exhaust ephemeral ports under load — a service that opens huge numbers of short-lived outbound connections can genuinely run out of usable source ports before those ports finish expiring, causing failed outbound connections that look unrelated to "too many ports in use" at first glance.
6. Assuming a well-known port number guarantees what's running there — port 443 is conventionally HTTPS, but nothing stops a process from listening on it with a completely different protocol; the number is a strong convention, not an enforced contract.

📋 Quick Reference

Port = 16-bit number (0-65535), identifies WHICH PROCESS on a host
IP address = identifies WHICH HOST

0-1023      well-known/system (often privileged to bind)
1024-49151  registered
49152-65535 ephemeral/dynamic (typically client-side, auto-assigned)

Socket = (src IP, src port, dst IP, dst port) — the actual unique connection identifier
TCP:53 and UDP:53 are independent namespaces — no conflict between them

No listener on a port  → OS replies RST ("connection refused")
Firewall blocks a port → typically no reply at all ("filtered" / times out)

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: net_ports_theory.md · generated by tools/build_lessons.py