IP, ports and how traffic finds a server

When someone types your site's address and a page appears, a surprising amount happens in between — and when it doesn't appear, you need to know that chain well enough to find the break. You do not need a networking degree for DevOps, but you do need a solid mental model of how a request finds a server and gets back. This module builds exactly that, and this first lesson lays the foundation: IP addresses, ports, and the journey a request takes.

The problem networking solves

There are billions of devices on the internet, and any one needs to be able to talk to any other. For that to work, two things must be true: every machine needs an address so traffic can be aimed at it, and there needs to be an agreed way of packaging and delivering the traffic. That is what IP and the protocols on top of it provide — addressing and delivery. Everything else is detail on top of those two ideas.

IP addresses: every machine has one

An IP address is the address of a machine on a network — like a postal address for a computer. Two forms exist:

• IPv4 — four numbers, 203.0.113.10. There are only ~4 billion of these, which the internet has run out of, hence:
• IPv6 — much longer, 2001:db8::1, with a vastly larger space. You will see both; the ideas are the same.

When your browser wants to reach a server, it ultimately needs the server's IP address, and traffic is routed across the internet to that address. But you rarely type an IP — you type a name like riztechacademy.com, and something translates the name to the IP. That something is DNS (the next lesson); for now, hold the fact that names are for humans, IP addresses are what the network actually uses.

A couple of addresses worth knowing:

• 127.0.0.1 — "localhost", meaning this same machine. When you run a dev server and visit localhost:3000, you are talking to your own computer.
• Private ranges (10.x, 192.168.x, 172.16-31.x) — addresses used inside a private network (your home, a company network, a cloud VPC) that are not reachable directly from the public internet. Cloud networking is largely about these (the AWS course goes deep here).

Ports: many services on one machine

An IP address gets you to the machine, but a machine runs many services at once — a web server, a database, SSH. Ports distinguish them: a port is a numbered door on the machine, and a service listens on a specific port. So a full destination is IP address + port: "this machine, that service".

Some ports are conventional, and you will use these constantly:

• 80 — HTTP (unencrypted web)
• 443 — HTTPS (encrypted web) — the one almost all real traffic uses
• 22 — SSH (the Linux module)
• 5432 — PostgreSQL, 3306 — MySQL, 6379 — Redis (common databases/caches)

When you visit https://riztechacademy.com, you are really connecting to that site's IP address on port 443. The browser hides the :443 because it is the default for HTTPS. When you run a local app on localhost:3000, 3000 is the port your app chose to listen on. "Connection refused" usually means nothing is listening on that port — a service that is down, or you have the wrong port. That single insight resolves a lot of "why can't I connect?" confusion.

The journey of a request

Put it together — here is what happens, roughly, when you load https://riztechacademy.com:

1. Name → address (DNS). Your machine asks DNS for the IP address behind riztechacademy.com (the DNS lesson).
2. Connect to IP + port. It opens a connection to that IP on port 443, using TCP — the protocol that provides a reliable, ordered stream (packets can arrive out of order or get lost; TCP sorts that out so the two sides see a clean connection).
3. Secure the connection (TLS). For HTTPS, the two sides do a TLS handshake to encrypt everything (the TLS lesson).
4. Make the request (HTTP). Your browser sends an HTTP request ("GET me this page"); the server replies with an HTTP response (the HTTP lesson).
5. Render. The browser draws the page, fetching more resources (images, scripts) the same way.

Every lesson in this module zooms into one of those steps — DNS, HTTP, TLS — and the last teaches you to probe each step from the command line. The value of holding this chain is diagnostic: when a site is down, the failure is at one of these steps, and knowing the chain lets you ask "is it DNS? the connection? TLS? the app?" instead of guessing.

TCP and UDP, briefly

Two transport protocols sit on top of IP, and you should recognise them:

• TCP — reliable and ordered: it guarantees the bytes arrive, in order, resending lost ones. The web, APIs, SSH, databases — almost everything you care about — use TCP, because they need every byte.
• UDP — fast and connectionless, no delivery guarantee: used where speed beats completeness, like video streaming, gaming, and DNS lookups. Losing a frame of video is fine; waiting to resend it is not.

For most DevOps work you deal with TCP; knowing UDP exists (and that DNS uses it) is enough for now.

Check your work

Networking solves addressing (every machine needs an address) + delivery (an agreed way to package and send traffic). Everything builds on those two.

IP address = a machine's address (IPv4 203.0.113.10; IPv6 longer, larger space). The network routes to IPs; humans type names, translated to IPs by DNS. 127.0.0.1 = localhost (this machine); private ranges (10.x,192.168.x,172.16-31.x) are internal, not publicly reachable.

Ports distinguish services on one machine (IP + port = machine + service): 80 HTTP, 443 HTTPS (almost all real traffic), 22 SSH, 5432 Postgres, 3306 MySQL, 6379 Redis. "Connection refused" usually = nothing listening on that port.

A request's journey: DNS (name→IP) → connect to IP:port over TCP → TLS handshake (HTTPS) → HTTP request/response → render. A down site fails at one step — the chain tells you where to look.

TCP vs UDP: TCP reliable/ordered (web, APIs, SSH, DBs — almost everything); UDP fast/no-guarantee (video, gaming, DNS).

Practice

1. Explain the difference between a name (riztechacademy.com), an IP address, and a port, with an example of each.
2. Name the default ports for HTTP, HTTPS and SSH, and say which one nearly all production web traffic uses.
3. Explain what 127.0.0.1/localhost means and why localhost:3000 talks to your own machine.
4. Walk through the five steps a request takes from typing a URL to seeing a page.
5. Explain what "connection refused" most often means in terms of ports and listening services.
6. Give one use case each for TCP and UDP and explain why each protocol suits it.

Official documentation

• MDN — How the web works — The request journey, for beginners.
• MDN — IP address (glossary) — What an IP address is.
• Wikipedia — Internet protocol suite — How TCP, UDP and IP fit together.

Next: DNS, and the records you will actually edit.