How Networking Works: What Happens When You Open a Web Page

In this series we learn computer networking the practical way, for developers and DevOps. Instead of dry theory, we start with a familiar question and follow it through the whole series: what actually happens when you type a web address and hit Enter?

The journey of a request

You type https://example.com and hit Enter. In about a second, a lot happens. Here's the big picture — don't worry if it doesn't all make sense yet, each step is its own article ahead:

   You type https://example.com
        │
   (1)  ▼  DNS: which IP is "example.com"?  ──────────────► 93.184.x.x   (Article 7)
        │
   (2)  ▼  Routing: the packet travels from your machine     (Articles 3,4,5)
        │   through routers, gateway, NAT... to that IP
        │
   (3)  ▼  TCP: 3-way handshake, open a connection to port 443  (Article 6)
        │
   (4)  ▼  TLS: negotiate encryption, check the certificate  (Article 9)
        │
   (5)  ▼  HTTP: send "GET / HTTP/1.1", get the page back    (Article 8)
        │
   (6)  ▼  The browser renders the page

These six steps capture nearly all of applied computer networking. A quick read-through:

1. DNS translates the name example.com into an IP address — because machines route by numbers, not names.
2. Routing: your packet doesn't go straight to the server; it hops across many devices (routers) along the way and crosses your home network's NAT.
3. TCP establishes a reliable connection to port 443 on the server (the HTTPS port).
4. TLS negotiates encryption keys and verifies the server really is example.com (via a certificate) — this is the "S" in HTTPS.
5. HTTP is the language your machine and the server speak to each other: you "GET" the page, the server returns it.
6. The browser builds the page from that response.

Each layer builds on the one below. The whole series digs into each layer, then the final article assembles them so you can trace a single request end to end.

Why developers and DevOps need to understand networking

You can write code without knowing networking — until something breaks. And network problems happen constantly:

• "The API call won't go through" — bad DNS? port blocked? expired TLS certificate? Each cause lives at a different layer.
• "The service is running but nobody can reach it" — bound to the wrong address? firewall? misconfigured load balancer?
• "Sometimes fast, sometimes slow" — a routing problem, DNS, or the connection?

Without understanding the network layers, you're just guessing. Once you do understand them, you can isolate the problem: is it DNS, TCP, TLS, or HTTP — and you know which tool to use to check each layer. This is the skill that separates someone whose "code runs" from someone who "operates the system."

On top of that, everything DevOps touches is networking: containers talk over a virtual network (Docker series), cloud servers live in a VPC (AWS series), Linux uses ip/ss/dig (Linux series, Article 13). This series is the foundation that explains why they work the way they do.

One idea throughout: networking is stacked in layers

The most important thing to carry with you: networking is designed as layers, each handling one job and relying on the layer below. DNS doesn't need to know how TCP works; HTTP doesn't need to know which router the packet passed through. Each layer "hides" its complexity from the layer above.

This layering (Article 1) is why the Internet scales to billions of devices and still works. And for you, it's a thinking tool: when troubleshooting, asking "which layer is the problem at?" narrows things down far faster than poking around blindly.

Series roadmap

1. The layered model: OSI and TCP/IP — the mental framework for the whole series.
2. IP addresses and subnets — IP, CIDR, private/public networks.
3. The link layer: MAC, ARP, switches — how the local network (LAN) works.
4. Routing: routers, gateways, routing tables — packets crossing between networks.
5. NAT and private/public IPs — why a whole household shares one IP to the Internet.
6. TCP and UDP: ports and connections — handshake, ports, two transfer styles.
7. DNS: domain name resolution — names to IPs, the record types.
8. HTTP and HTTPS — the language of the web, methods, status codes.
9. TLS/SSL: encryption and certificates — how the "S" in HTTPS works.
10. Firewalls and network security — controlling who can reach which port.
11. Load balancers and reverse proxies — distributing load, scaling services.
12. Network diagnostic tools — ping, traceroute, dig, ss, tcpdump, curl -v.
13. Tracing a request from end to end — putting it all together, and where to go next.

What you'll need

• A Linux environment to run network tools — a container (see Linux series, Article 1) is enough for most of it. A few articles need Internet access to demo (dig, curl to real servers).
• No prior networking knowledge required. Basic comfort with the command line is enough.

After this article there's nothing to do yet. Article 1 builds the most important mental framework: the layered model — so every article after it "lands in the right place."