Networking Fundamentals: IP Addresses, Ports & TCP vs UDP

Beginner25 min5 steps

What you'll learn

Explain that every machine on a network has an IP address, and read an IPv4 dotted-quad (with a nod to IPv6 and localhost)
Read CIDR notation (/24) to tell which addresses are on your local network, and describe the gateway's job
Explain that a port numbers a specific service on a host, and recognize the well-known ports (22, 80, 443, 53)
Contrast TCP (reliable, connection-oriented) with UDP (fast, connectionless) and say which everyday services use each

Every machine has an address
See the core idea: data moves between numbered addresses, and yours is an IP address.
A network is just machines sending data to each other, and — exactly like the postal system — every machine needs an address so data knows where to go. On a network that address is an IP address (Internet Protocol address).
The kind you'll see most is IPv4, written as four numbers 0–255 separated by dots — a dotted quad — like 192.168.1.42. Each machine on a network has one, and when you connect to a website your computer is really sending packets to that server's IP address and getting packets back at yours.
A few addresses are worth knowing on sight:
- `127.0.0.1` — localhost, meaning "this machine, talking to itself." A service listening here is only reachable from the same computer. (The name localhost resolves to it.)
- `192.168.x.x`, `10.x.x.x`, `172.16–31.x.x` — private ranges used inside home and office networks. They aren't reachable directly from the public internet.
- Everything else you connect to publicly is a public address, unique across the internet.
There's also IPv6, a newer, much larger address space written in hex with colons (like 2001:db8::1), created because the world ran out of IPv4 addresses. The idea is identical — a unique address per machine — just more of them. For now, picture IPv4: four dotted numbers that name a machine.
```
$ ip addr show
```
```
1: lo: <LOOPBACK,UP> ...
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> ...
    inet 192.168.1.42/24 scope global eth0
```
ip addr shows this machine's addresses. 'lo' is the loopback interface with 127.0.0.1 (localhost — itself). 'eth0' is a real network interface with 192.168.1.42 — a private address, so this machine is on a home/office network. Your own output will show your interfaces and addresses.
WHY THIS MATTERS
Every service you start, every connection you debug, comes down to which address and (next) which port. Once "a machine is reachable at an IP address" is second nature, error messages like connection refused or no route to host start telling you exactly what's wrong.
Subnets & CIDR: which addresses are local
Read /24 notation to separate the network from the host, and understand the gateway.
Addresses are grouped into networks. The trailing /24 you saw — 192.168.1.42/24 — is CIDR notation, and it tells you how much of the address is the network part versus the host part.
Think of the address as network + host, like street + house number:
- `/24` means the first 24 bits (the first three numbers, 192.168.1) are the network, and the last number (.42) identifies the host on it. So every address 192.168.1.0–192.168.1.255 is on the same local network.
- A bigger host part means more machines: /16 (192.168.0.0–192.168.255.255) holds far more hosts than /24.
Why it matters: machines on the same network can talk directly. To reach anything outside it, your traffic goes through the gateway (also called the default gateway or router) — the machine that knows how to forward packets off your local network toward the rest of the world. It's the "exit door" of your network. Your computer keeps a small routing table that says, in effect, "local addresses: deliver directly; everything else: hand to the gateway."
So when you curl a website, your machine sees the destination isn't on your /24, and sends the packets to the gateway, which forwards them on.
```
$ ip route show
```
```
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 scope link
```
The routing table in two lines. 'default via 192.168.1.1' is the gateway — anything not on the local network goes there. '192.168.1.0/24 dev eth0' says addresses on that /24 are reachable directly on the eth0 interface. This is exactly the 'local: direct; everything else: gateway' rule.
Check yourself
Two machines have addresses 192.168.1.10/24 and 192.168.1.200/24. Are they on the same local network?
Ports: many services, one address
Understand that a port numbers a specific service, so one host can run many.
An IP address gets data to the right machine — but a machine runs many network programs at once (a web server, an SSH server, a database). How does an arriving packet know which one it's for? The answer is the port: a number from 1 to 65535 that identifies a specific service on the host.
If the IP address is the street address of an apartment building, the port is the apartment number. A connection is really to an *address and port* together — written 192.168.1.42:22 — which names one exact service on one exact machine.
Many ports are standardized so clients know where to knock. These well-known ports are worth memorizing:
- 22 — SSH (remote login)
- 80 — HTTP (web)
- 443 — HTTPS (encrypted web)
- 53 — DNS (name lookups)
- 25 — SMTP (mail)
That's why https://example.com quietly means "connect to example.com's IP on port 443" — the browser fills in the standard port for you. A server listens on a port ("I'll answer knocks on 443"); a client connects to that port. If nothing is listening, you get connection refused — the knock lands on a door with no one behind it.
```
$ ss -tlnp
```
```
State   Local Address:Port   Process
LISTEN  0.0.0.0:22           sshd
LISTEN  127.0.0.1:5432       postgres
```
ss -tlnp lists TCP (-t) listening (-l) sockets with numeric ports (-n) and the process (-p). sshd listens on 0.0.0.0:22 — port 22 on every interface, so reachable from the network. postgres listens on 127.0.0.1:5432 — only on localhost, so it accepts connections from this machine alone. The address:port pair tells you both where and what.
address:port names one exact service
Read 127.0.0.1:5432 as "the PostgreSQL service on this machine" and 0.0.0.0:22 as "the SSH service, reachable on any interface." When something 'can't connect', check both halves: is it the right address (localhost vs the network) and is anything listening on that port? Most connection failures are one of those two.
TCP vs UDP: two ways to send
Contrast reliable connections with fast fire-and-forget, and match each to real services.
Underneath the addresses and ports, there are two main ways to actually move the data: TCP and UDP. They make opposite tradeoffs.
TCP (Transmission Control Protocol) is the reliable, connection-oriented one:
- It sets up a connection first (a three-step handshake) before sending data.
- It guarantees delivery: lost packets are re-sent, and data arrives in order.
- The cost is a little overhead and delay for all that bookkeeping.
- Used when every byte must arrive correctly: web (HTTP/HTTPS), SSH, email, file transfers.
UDP (User Datagram Protocol) is the fast, connectionless one:
- No handshake, no connection — it just fires packets (datagrams) at the destination.
- No guarantees: packets can be lost, duplicated, or arrive out of order, and UDP won't fix it.
- The payoff is speed and low overhead.
- Used when speed beats perfection, or the app handles losses itself: DNS lookups, video/voice calls, live streaming, online games.
The mental model: TCP is a phone call — you connect, confirm the other side is there, and everything is acknowledged. UDP is a postcard — you write it and drop it in the mail; it usually arrives, but nobody confirms it. Neither is "better"; they fit different jobs. A DNS lookup uses UDP because it's one tiny question-and-answer where re-asking is cheaper than setting up a connection; downloading a file uses TCP because a single missing byte would corrupt it.
Check yourself
A service must guarantee that every byte arrives, in order, with lost packets re-sent. Is that TCP or UDP?
Same port number, different protocol
Ports are per-protocol, so TCP port 53 and UDP port 53 are different doors. DNS actually uses UDP 53 for ordinary lookups (fast, tiny) and TCP 53 for large responses and zone transfers. That's why tools like ss distinguish -t (TCP) from -u (UDP) — you're often asking about one specifically.
Now do it — inspect your own networking
Read your real address, gateway, listening ports, and a name lookup.
One continuous look at the machine you're on: find your address, your gateway, what's listening, and watch a name turn into an IP — the four ideas from this lesson, live.
```
$ ip -brief addr show; echo '--- gateway ---'; ip route | grep default
```
The -brief form gives one tidy line per interface with its address, then we pull just the default route to see the gateway. Together these answer 'what's my address, and where does off-network traffic go?' Your terminal fills in the real values.
```
$ ss -tuln | head
```
List listening sockets for both TCP (-t) and UDP (-u), numeric (-n), listening only (-l). Each line is an address:port a service is waiting on — a map of every 'door' open on this machine. Compare the TCP and UDP entries: different protocols, sometimes the same port number.
```
$ getent hosts example.com; echo '--- reachability ---'; ping -c 1 example.com
```
getent hosts resolves the NAME 'example.com' to an IP address (a DNS lookup — UDP port 53 under the hood), showing how names map to addresses. Then ping sends one packet to that address to check reachability. You've now watched a name become an address, then reached it.
```
$ curl -s -o /dev/null -w 'connected to %{remote_ip}:%{remote_port}\n' https://example.com
```
```
connected to 93.184.216.34:443
```
curl connects to example.com and reports the address:port it actually reached — port 443, the standard HTTPS port the browser/curl fills in for you. This is the whole lesson in one line: a name resolved to an IP, a connection made to a specific port, over TCP. (The exact IP will vary.)
The mental model to keep
A machine is reachable at an IP address (192.168.1.42); the `/24` says which addresses are local, and off-network traffic goes through the gateway. A port names one service on that host (:22 SSH, :443 HTTPS), so address:port identifies an exact service. Underneath, TCP is a reliable phone call (web, SSH) and UDP is a fire-and-forget postcard (DNS, streaming). ip addr, ip route, and ss -tuln show you all of it on your own machine.

Recap

Every machine has an IP address (IPv4 dotted-quad like 192.168.1.42); 127.0.0.1 is localhost (itself), and 192.168/10/172.16 ranges are private. IPv6 is the same idea with a far larger address space.
CIDR like /24 splits the address into network + host: same network part = same local network (talk directly). Anything else goes through the gateway (default route).
A port (1–65535) names a specific service on a host, so address:port identifies one exact service. Know 22 SSH, 80 HTTP, 443 HTTPS, 53 DNS; a server listens on a port, a client connects to it.
TCP is reliable and connection-oriented (handshake, re-sends, in order) — web, SSH, mail; UDP is fast and connectionless (no guarantees) — DNS, streaming, games. TCP is a phone call, UDP a postcard.

Networking fundamentals at a glance
Term	What it means
IP address	a machine's address on a network (e.g. 192.168.1.42)
127.0.0.1 / localhost	this machine, talking to itself
/24 (CIDR)	network part is the first 24 bits; rest identifies the host
gateway	the router that forwards off-network traffic
port	a numbered service on a host (22 ssh, 443 https, 53 dns)
TCP	reliable, ordered, connection-oriented (web, ssh)
UDP	fast, connectionless, no guarantees (dns, streaming)
ip addr / ip route / ss -tuln	show your addresses / gateway / listening ports

Networking Fundamentals: IP Addresses, Ports & TCP vs UDP

Every machine has an address

Subnets & CIDR: which addresses are local

Ports: many services, one address

TCP vs UDP: two ways to send

Now do it — inspect your own networking