Networking: how a request reaches a server
The internet sounds like deep magic, but it’s really just labelled messages being passed from one machine to the next, and you already use every idea behind it.
From your mentor
Don’t try to memorise the OSI model on day one. Learn what an address, a port, and a name resolve to, then trace one request end to end. Do that once and every cloud diagram you’ll ever see suddenly reads like plain English.
The network is just messages with addresses on them, and you already understand addresses.
In 10 minutes you’ll see how a name becomes a number, how a number finds a machine, and how a machine knows which app you wanted. You do NOT need subnet math or the OSI model memorised yet.
Pick your way in, same idea, 5 doors
Every computer has a house number (its IP address). Apps on it live behind numbered doors (ports). And because nobody remembers house numbers, there’s a phone book (DNS) that turns google.com into the number. That’s the whole thing.
It’s messages with addresses, not magic
The network does one thing forever: take a chunk of data, label it with where it’s going, and hand it to the next machine that’s closer. Everything else is detail on top of that.
In plain English
A request gets split into small packets. Each packet carries a source and destination address, gets passed router to router until it arrives, and is reassembled at the other end. If some go missing, they’re re-sent. You never see any of this, you just see the page load.
| Layer you’ll actually meet | Its job | In one request |
|---|---|---|
| IP | Address & route packets to a machine | Find the host at 93.184.216.34 |
| TCP | Reliable, ordered delivery between two apps | Don’t lose or scramble the bytes |
| TLS | Encrypt the conversation | Nobody on the path can read it |
| HTTP | The actual request & response | GET /index.html → 200 OK |
Why “layers” is the whole trick
Each layer only worries about its own job and trusts the one below it. HTTP doesn’t care how packets are routed; IP doesn’t care what’s inside them. That separation is exactly why you can learn one piece at a time without holding the entire internet in your head.IP addresses & subnets: where machines live
An IP address is a machine’s location on the network. A subnet is a neighbourhood of addresses that belong together. You only need to read them, not do mental math.
An IPv4 address looks like 192.168.1.42, four numbers (0–255) that together name one network interface. Some ranges are private (only valid inside your own network) and the rest are public (reachable across the internet).
| Range | Type | Where you see it |
|---|---|---|
| 10.0.0.0 – 10.255.255.255 | Private (10/8) | Cloud VPCs, big internal networks |
| 172.16.0.0 – 172.31.255.255 | Private (172.16/12) | Docker default networks |
| 192.168.0.0 – 192.168.255.255 | Private (192.168/16) | Home & office Wi-Fi |
| 127.0.0.1 | Loopback | “This machine”, aka localhost |
| Everything else | Public | Real servers on the internet |
CIDR /24 in one sentence
10.0.1.0/24 means “the first 24 bits are fixed, the last 8 are free”, so it’s the 256 addresses from 10.0.1.0 to 10.0.1.255. Bigger number after the slash means a smaller, tighter range. That’s 90% of the CIDR you need to read a cloud diagram.Worth pondering
192.168.x.x reaches the world through your router doing NAT(translating your private address to one shared public one). Cloud does the exact same trick with a NAT gateway.Ports: many doors on one machine
One server runs many apps. The IP address finds the machine; the port number says which app you wanted. Same building, numbered doors.
A port is a number from 0 to 65535. When a packet arrives at a machine, the port tells the OS which listening program should receive it. A web server listens on 443; your local dev server might be on 3000.
| Port | Service | You’ll meet it as |
|---|---|---|
| 22 | SSH | How you log into a server |
| 80 | HTTP | Plain web traffic (redirects to 443) |
| 443 | HTTPS | Encrypted web traffic, the default today |
| 53 | DNS | Name lookups |
| 5432 / 3306 | Postgres / MySQL | Database connections |
| 3000 / 8080 | Dev servers | Your app running locally |
man page: nc# what's listening on this machine, and on which port?$ ss -ltnp # listening TCP sockets + the owning process nc -zv example.com 443 # can I reach door 443 over there?State Recv-Q Local Address:Port Process LISTEN 0 127.0.0.1:5432 users:(("postgres")) LISTEN 0 0.0.0.0:443 users:(("nginx"))
0.0.0.0 vs 127.0.0.1 is a real security line
Listening on127.0.0.1 means “only this machine can connect”. Listening on 0.0.0.0 means “anyone who can reach my IP can connect”. Binding a database to 0.0.0.0 with a weak password is one of the most common ways servers get owned.DNS: turning names into numbers
Nobody types IP addresses. DNS is the internet’s phone book: give it a name, it gives you the address to actually connect to.
When you visit example.com, your machine asks a resolver “what’s the IP?”. The answer is cached for a while (its TTL), so the next visit skips the lookup. The most common records are A (name → IPv4) and CNAME (name → another name).
man page: dig# resolve a name yourself, the way your browser does$ dig +short example.com # just the IP address(es) dig example.com # the full answer, with TTL dig +short www.github.com CNAME # follow the alias chain93.184.216.34
| Record | Maps | Use it for |
|---|---|---|
| A | name → IPv4 address | Point a domain at a server |
| AAAA | name → IPv6 address | Same, for IPv6 |
| CNAME | name → another name | Alias www to your app, or to a CDN |
| MX | name → mail server | Where email for the domain goes |
| TXT | name → free text | Domain verification, SPF/DKIM |
Careful here
The journey: what happens when you hit enter
This is the question every interview asks in some form. Trace one request from the address bar to bytes coming back, and you’ve tied every idea above together.
You type https://example.com and press enter. Six things happen in well under a second, in this order:
| Step | What happens | Which idea |
|---|---|---|
| 1. Resolve | Browser asks DNS for the IP of example.com | DNS |
| 2. Connect | Opens a TCP connection to that IP on port 443 | IP + ports + TCP |
| 3. Secure | TLS handshake: agree on encryption, check the cert | TLS |
| 4. Request | Sends an HTTP GET / with headers | HTTP |
| 5. Respond | Server returns a status code + the page bytes | HTTP |
| 6. Render | Browser parses HTML, fetches CSS/JS, repeats 1–5 | All of it |
man page: curl# watch all of it: DNS, TCP, TLS, and the HTTP exchange in one command$ curl -v https://example.com* Connected to example.com (93.184.216.34) port 443 * TLS handshake, TLSv1.3 > GET / HTTP/2 > Host: example.com < HTTP/2 200 < content-type: text/html; charset=UTF-8
Read an HTTP status code at a glance
2xx worked, 3xx go somewhere else (redirect), 4xx you got it wrong (404 not found, 401/403 not allowed), 5xx the server broke. The first digit tells you who to blame.Exposing a service: the climb from “open to the world”
The networking equivalent of chmod 777 is binding to 0.0.0.0 and opening every port. It makes the error go away, then becomes the breach. Let’s climb it properly.
The moment a service can’t be reached, the tempting fix is to open everything: bind to 0.0.0.0, allow 0.0.0.0/0 in the firewall, every port. It works instantly, and it’s exactly how databases end up on the public internet.
- Rung 0 · Naive
Open to the whole world (0.0.0.0/0, all ports)
The connection fails, so you bind the service to 0.0.0.0 and open the firewall to every source on every port. It connects. Problem “solved”.
Now anyone on the internet can reach your database, your admin panel, your SSH. Scanners find an exposed port within minutes. This is the single most common cause of leaked data, not clever hacking, just a service left wide open. - Better
Only the ports you need, from known sources
Open 443 to the world for the website, but restrict 22 (SSH) and 5432 (database) to your own IP or your VPC’s range. Everything else stays closed by default.
The public reaches only what’s meant to be public. Management and data ports are invisible to the internet, so the attack surface shrinks from “everything” to “the one door that has to be open”. - Best practice today
Least privilege: private by default, reach in deliberately
Keep the database with no public address at all; reach it only from the app’s private subnet. Put the website behind a load balancer, and access servers through a bastion or SSM, not open SSH.
Nothing is exposed unless there’s a specific reason. A compromised front-end can’t even see the database’s address, let alone connect. This is exactly how a well-built cloud VPC is laid out.
Nice, that’s the win
chmod 777 climb from the Linux lesson. “Open it all to make the error vanish”, then “open only what’s needed”, then “closed by default, opened on purpose”. Least privilege is one idea, you’ll meet it in files, networks, and IAM.A security group is just a firewall with a friendlier name
In the cloud you won’t editiptables by hand. You’ll write rules like “allow TCP 443 from anywhere, allow 5432 only from the app tier”. Same three rungs, same least-privilege goal, nicer UI.Interview angle
Networking is assumed for every cloud, DevOps, and backend role. Expect the “what happens when you type a URL” walk-through and rapid-fire basics on DNS, ports, and private vs public.
“Walk me through what happens, end to end, when you type a URL and press enter.”
How to answer it
They’re testing whether you hold a clear mental model, not trivia. Move in order and name the idea at each step: resolve, connect, secure, request, respond, render. Calm and sequenced beats fast and scattered.
- 1DNS resolution: the browser resolves the hostname to an IP (checking caches first, then a resolver), returning an A/AAAA record.
- 2TCP connection: it opens a connection to that IP on port 443 (the three-way handshake: SYN, SYN-ACK, ACK).
- 3TLS handshake: client and server agree on encryption and the server presents a certificate the browser validates.
- 4HTTP request: the browser sends GET / with headers like Host and Accept.
- 5Response: the server returns a status code (ideally 200) plus the response body.
- 6Render: the browser parses HTML and fires more requests for CSS, JS, and images, repeating the cycle.
Green flags
- Names DNS, TCP, TLS, and HTTP as distinct layers
- Mentions caching and TTL, and the handshake
- Can say where it commonly breaks (DNS, closed port, cert, 5xx)
Red flags
- Jumps straight to “the server sends the page” with nothing in between
- Confuses an IP address with a domain name
- Thinks HTTPS is a different protocol rather than HTTP over TLS
Q.Private vs public IP address?
A.A private IP is only valid inside a local network; a public IP is routable across the internet. Private hosts reach out via NAT.
They’re checking: That you understand why cloud VPCs use private ranges and a NAT gateway.
Q.TCP vs UDP?
A.TCP is reliable and ordered (it retransmits lost data); UDP is fire-and-forget, lower latency, no guarantees.
They’re checking: That you pick the protocol from the requirement, not by reflex.
Q.What does DNS actually return, and why can changes lag?
A.DNS maps a name to records (commonly an A record → IP). Changes lag because answers are cached until their TTL expires.
- Resolvers cache answers to avoid asking every time; the TTL sets how long.
- Lower the TTL before a planned migration so the cutover propagates fast.
They’re checking: That you reach for TTL/caching when a DNS change “isn’t taking”.
Q.Port 80 vs 443?
A.80 is plain HTTP; 443 is HTTPS (HTTP over TLS). Modern sites serve 443 and redirect 80 to it.
They’re checking: That you know HTTPS is HTTP wrapped in TLS, not a separate protocol.
Q.A service is unreachable. How do you debug the network path?
A.Work outward in order: name, then route, then port, then firewall.
- dig the name, does it resolve to the IP you expect?
- ping / traceroute the IP, does the host even respond and where do packets stop?
- nc -zv host port, is the specific port open?
- Then check the firewall / security group and whether the app is bound to 0.0.0.0 vs 127.0.0.1.
They’re checking: That you isolate the layer instead of randomly restarting things.
Your turn, in your own terminal
No server or account needed. You’ll resolve a name, knock on a port, and watch a full HTTPS request happen against a public site. About 15 minutes, and it turns reading into instinct.
Now do it in your own account
Open a terminal and work through these in order. Every command reads the public internet; nothing changes anything, so it’s completely safe to run.
Before you start
2 to have readyA terminal: macOS Terminal, any Linux shell, or Windows WSL (Ubuntu).
echo $SHELLThe tools dig, curl, and nc. Most ship by default; on Debian/Ubuntu, sudo apt install dnsutils netcat-openbsd if missing.
curl --version && dig -v- 1
Resolve a name to an IP address, the way your browser silently does.
Free tierYour terminal
You should see: one or more IP addresses, e.g. 93.184.216.34.
- 2
Knock on the HTTPS door of that host and confirm it’s open.
Free tierYour terminal
You should see: “succeeded” or “open”, port 443 is listening.
- 3
Watch the full journey: DNS, TCP, TLS, and the HTTP exchange.
Free tierYour terminal
You should see: lines for Connected, TLS handshake, > GET /, then < HTTP/2 200.
- 4
See the route your packets take across the internet, hop by hop.
Free tierYour terminal
aws cli$ traceroute example.com # macOS/Linux (tracert on Windows)You should see: a numbered list of routers between you and the destination.
- 5
Look at what’s listening on your own machine, and on which ports.
Free tierYour terminal
aws cli$ ss -ltn # or: lsof -i -P | grep LISTENYou should see: a list of local listening ports, note which are 127.0.0.1 vs 0.0.0.0.
Last step: tear it down
Once you’ve seen it work, remove everything so nothing keeps billing.
Nothing to clean up, every command was read-only against public services.
If you installed dnsutils/netcat just for this, you can leave them, they’re tiny and useful.
Next up
Next, into the cloud
Put these foundations to work on a real cloud provider, starting with getting into AWS safely.