Ports & Protocols

Every server has an IP address (a number that identifies the machine on a network). But a single machine usually runs many programs at once — a website, a database, an SSH login service, and more. So how does network traffic know which program it belongs to? The answer is ports. A port is a numbered “door” on an IP address, and each running service listens behind one of those doors. Understanding ports and the protocols that use them is the foundation of almost everything in DevOps: opening firewalls, connecting to databases, debugging “connection refused” errors, and securing your servers.

What is a port?

Think of an IP address as the street address of an apartment building, and a port as the specific apartment number inside it. The IP gets you to the right machine; the port gets you to the right program on that machine.

A port is just a number from 0 to 65535 (16-bit). When a program wants to receive network traffic, it “binds” to a port and listens. When another program wants to talk to it, it sends traffic to that machine’s IP plus the port number, written as IP:PORT — for example 203.0.113.10:443.

Ports are split into three ranges:

Range	Name	Typical use
0–1023	Well-known ports	Standard services (SSH, HTTP, HTTPS). Binding requires root/sudo.
1024–49151	Registered ports	Apps that registered a number (Postgres 5432, MySQL 3306).
49152–65535	Dynamic / ephemeral ports	Temporary ports the OS hands out for outgoing connections.

The “binding requires root” rule for ports below 1024 is a Linux security feature. It’s why you often run a web server on port 8080 during development (no sudo needed) but use 80/443 in production behind a process that has the right privileges.

Common well-known ports

You will see these constantly. Memorising the top few saves a lot of time.

Port	Protocol	Service	What it does
22	TCP	SSH	Secure remote login and file transfer
80	TCP	HTTP	Unencrypted web traffic
443	TCP	HTTPS	Encrypted web traffic (HTTP over TLS)
53	TCP/UDP	DNS	Turns domain names into IP addresses
5432	TCP	PostgreSQL	The default Postgres database port
3306	TCP	MySQL/MariaDB	The default MySQL database port
6379	TCP	Redis	In-memory data store

On Ubuntu you can look up what a port is “supposed” to be by checking the system services file:

grep -E "^(ssh|http|https|postgresql)\b" /etc/services

Output:

ssh             22/tcp
http            80/tcp
https           443/tcp
postgresql      5432/tcp

This file is just a name-to-number map — it does not mean those services are running. It’s a reference, not a status check.

TCP vs UDP

When data travels over a network, it uses a transport protocol — a set of rules for how the data is packaged and delivered. The two you must know are TCP and UDP.

TCP (Transmission Control Protocol) is the reliable one. Before sending data, it performs a handshake (a short back-and-forth to set up the connection). It guarantees that every piece of data arrives, in the right order, with nothing lost. If a packet goes missing, TCP resends it. The trade-off is a little extra overhead and delay.

UDP (User Datagram Protocol) is the fast, “fire and forget” one. It sends data without a handshake and without checking whether it arrived. There’s no guarantee of delivery or order. The trade-off for that risk is much lower latency (delay).

When to use which

	TCP	UDP
Reliability	Guaranteed delivery & order	No guarantee
Speed/overhead	Slower, more overhead	Faster, minimal overhead
Connection	Handshake first	Connectionless
Use when	Data must be complete	Speed matters more than perfection
Examples	SSH, HTTP/HTTPS, databases, email	DNS lookups, live video/voice, online games

Use TCP for almost everything in day-to-day DevOps: web servers, SSH, database connections, file transfers. If losing data would break things, use TCP.

Use UDP when occasional loss is acceptable but speed is critical — like a video call where a dropped frame is better than a frozen screen, or a quick DNS lookup where re-asking is cheaper than maintaining a connection.

A common mistake: opening port 53 (DNS) for TCP only in a firewall. DNS uses both TCP and UDP, and large responses fall back to TCP. If you only allow one, some lookups silently fail.

Checking which ports are listening

The modern Ubuntu tool for inspecting ports is ss (socket statistics). It replaced the older netstat. Run this to see every TCP port your server is listening on, plus the program behind each one:

sudo ss -tlnp

The flags mean: -t TCP only, -l listening sockets only, -n show numbers not names (faster), -p show the process. You need sudo to see process names for other users’ programs.

Output:

State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
LISTEN   0        128      0.0.0.0:22           0.0.0.0:*           users:(("sshd",pid=812,fd=3))
LISTEN   0        244      127.0.0.1:5432       0.0.0.0:*           users:(("postgres",pid=1190,fd=5))
LISTEN   0        511      0.0.0.0:80           0.0.0.0:*           users:(("nginx",pid=1532,fd=6))

Read the Local Address:Port column carefully — it tells you who can reach the service:

0.0.0.0:22 means “listening on all network interfaces” — reachable from the internet (if the firewall allows it). Here SSH and Nginx are exposed.
127.0.0.1:5432 means “listening on localhost only” — Postgres can only be reached from the same machine. This is the safe default for a database.

To check UDP ports instead, swap -t for -u:

sudo ss -ulnp

To find out what is using one specific port (for example, “what is on 80?”):

sudo ss -tlnp 'sport = :80'

Output:

State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
LISTEN   0        511      0.0.0.0:80           0.0.0.0:*           users:(("nginx",pid=1532,fd=6))

Best Practices

Bind databases and internal services to 127.0.0.1 (localhost) so they are never exposed to the internet — only open a public port when something outside the machine genuinely needs it.
Run sudo ss -tlnp after every install or deploy to confirm only the ports you expect are listening; an unexpected 0.0.0.0 entry is a red flag.
Keep standard services on their standard ports (22, 80, 443) unless you have a clear reason; non-standard ports add confusion without adding real security.
Use TCP unless you specifically need UDP’s speed and can tolerate lost data.
Pair every open port with a firewall rule (ufw) so the firewall, not luck, decides what’s reachable.
Remember DNS and some other services need both TCP and UDP — check the protocol before writing firewall rules.

Ports & Protocols

What is a port?

Common well-known ports

TCP vs UDP

When to use which

Checking which ports are listening

Best Practices

Related Topics