How the Internet Works: A Simple Guide for Curious Beginners

How the Internet Works: A Simple Guide for Curious Beginners

When I first started learning web development, I could write HTML and CSS but had no idea how my code got from a file on my computer to someone's browser on the other side of the world.

I was building on a foundation I didn't understand. It worked — until it didn't, and I had no idea why.

Understanding how the internet works isn't just academic. It explains why HTTPS matters, why DNS outages break websites, why your app needs to handle slow connections, and why latency affects user experience more than bandwidth for most web apps.

You don't need a computer science degree to understand this. This guide explains the internet using plain English and everyday analogies, covering everything a web developer needs to know to build and debug confidently.

The Big Picture: A Letter to a Friend

The internet is often compared to a postal system, and the analogy holds up well.

When you want to send a letter to a friend:

1. You write the letter (the data)
2. You put it in an envelope with their address (a packet)
3. The post office routes it through sorting facilities (routers)
4. It arrives at your friend's address (their computer)
5. They open and read it (the application)

The internet works the same way — just millions of times faster and with billions of simultaneous "letters."

Building Blocks: IP Addresses and Packets

IP Addresses

Every device on the internet has an IP (Internet Protocol) address — a unique numerical identifier, like a street address.

• IPv4: 142.250.80.46 (four numbers, 0–255 each)
• IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (newer, much larger address space)

Your home router has a public IP address visible to the internet. Devices inside your home network get private IP addresses (like 192.168.1.x) that are invisible from outside.

Packets

Data doesn't travel as one piece — it's broken into small chunks called packets. A 10MB file becomes thousands of packets, each individually routed across the network and reassembled at the destination.

This is why the internet is resilient. If one route fails, packets take a different path. They don't all need to travel the same route and can arrive out of order and be reassembled correctly.

DNS: The Internet's Phone Book

You type google.com into your browser. Your computer doesn't know what google.com means — it needs an IP address.

DNS (Domain Name System) translates domain names into IP addresses:

google.com → 142.250.80.46
github.com → 140.82.121.4

How a DNS Lookup Works

1. Browser checks its local cache — if you visited recently, it knows the IP
2. If not cached, asks your OS resolver (also has a cache)
3. If not there, queries your ISP's DNS server
4. If the ISP doesn't know, queries root nameservers → TLD nameservers (for .com) → authoritative nameservers (for google.com)
5. Answer returns and is cached at each step for future requests

This entire process typically takes under 50 milliseconds. DNS failures cause websites to become unreachable even when the server is running fine — this is why major DNS outages (like the 2021 Cloudflare DNS incident) can take down thousands of sites simultaneously.

TCP/IP: Reliable Delivery

TCP (Transmission Control Protocol) ensures packets arrive correctly:

1. Connection — a "handshake" between client and server establishes a connection (SYN → SYN-ACK → ACK)
2. Transmission — data is sent in numbered packets
3. Acknowledgment — receiver confirms each packet
4. Retransmission — if a packet is lost, it's resent
5. Reordering — packets that arrive out of order are reassembled correctly

TCP is reliable but has overhead. For real-time applications (gaming, video calls) where some data loss is acceptable, UDP (User Datagram Protocol) skips the handshake and acknowledgments for lower latency.

What is a Port?

A port is like a specific door in a building. Your server at IP 142.250.80.46 handles many types of traffic. Ports direct traffic to the right service:

HTTP: The Language of the Web

HTTP (HyperText Transfer Protocol) is the communication protocol browsers and servers use. Every web request is an HTTP transaction.

HTTP Request

GET /about HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0 (Chrome)

A request has:

• Method — what to do (GET, POST, PUT, DELETE)
• Path — which resource to request (/about)
• Headers — metadata about the request

HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4523

<!DOCTYPE html>
<html>...

A response has:

• Status code — what happened
• Headers — metadata about the response
• Body — the actual content (HTML, JSON, image data, etc.)

HTTP Status Codes

Understanding status codes is essential for debugging APIs and web applications. Our API tutorial for beginners covers HTTP methods and status codes in depth.

What Actually Happens When You Type a URL

Let's trace https://github.com/login step by step:

1. DNS lookup — browser resolves github.com to an IP address
2. TCP connection — browser opens a TCP connection to GitHub's server on port 443
3. TLS handshake — browser and server negotiate encryption (because HTTPS)
4. HTTP request — browser sends GET /login HTTP/1.1
5. Server processing — GitHub's server looks up the login page
6. HTTP response — server returns HTML with status 200
7. HTML parsing — browser reads the HTML, finds references to CSS, JS, and images
8. Sub-requests — browser requests each CSS, JS, and image file (steps 4–6 repeat for each)
9. Rendering — browser executes JavaScript, applies CSS, and paints the page

This is why the first page load is slower than subsequent loads — DNS and connection setup happen only once, and assets are cached. For more on this and why HTTPS matters at step 3, see our HTTP vs HTTPS guide.

Servers, Clients, and the Web Stack

The client is your browser — it requests resources. The server is a computer (usually in a data center) that responds to requests.

What's Actually Running on a Server?

When you access example.com, a server is running software that:

1. Listens for incoming HTTP connections (a web server like Nginx or Apache)
2. Routes requests to application code (application server — Node.js, Python, etc.)
3. Queries a database if needed
4. Returns a response

The full stack: Browser → DNS → TCP/IP → Web Server → App Server → Database → Response

CDNs: Serving Files From Everywhere

A CDN (Content Delivery Network) stores copies of your static files (images, CSS, JS) on servers distributed globally. When a user in Tokyo requests your image, they get it from a CDN node in Tokyo rather than your server in New York.

This reduces latency dramatically — the difference between 300ms and 30ms for each asset. Our web performance guide covers CDNs and how to configure them.

Frequently Asked Questions

What's the difference between the internet and the web?

The internet is the physical infrastructure (cables, routers, servers). The web is a service that runs on the internet — the system of pages and links accessed through browsers.

What is DNS?

DNS translates domain names (google.com) into IP addresses (142.250.80.46) that computers use to route traffic. Like a phone book for the internet.

What is an IP address?

A unique numerical identifier for every device on a network — like a street address for your computer.

What happens when you type a URL?

DNS lookup → TCP connection → TLS handshake → HTTP request → Server processes → HTTP response → Browser parses and renders.

What are bandwidth and latency?

Bandwidth is how much data transfers per second (pipe width). Latency is how long a packet takes to travel (pipe length). For web apps, low latency matters more than high bandwidth.