What Is It?
The internet is a global network of computers that agree to communicate using a shared set of rules called protocols. Not "the cloud" — actual physical cables, routers, and servers in data centres, connected to each other in a web-like structure where data can find multiple paths between any two points.
When you load a webpage, you're really asking a remote computer to send you some files, and those files travel from that machine to yours in small numbered chunks called packets. Every step of this is mechanical and deterministic — there's no magic, just layers of rules stacked on top of each other, each one doing a specific job.
The reason the internet is so reliable is that it was designed for redundancy. No single cable or router can bring it down. If one path breaks, packets take another. This design came from ARPANET, built in the 1960s for exactly this reason: a network that could survive a nuclear strike on any one node.
How It Actually Works
What actually happens when you type https://example.com and press Enter:
Step 1: DNS Lookup
Before anything else, your computer needs to find the IP address of example.com. It asks a DNS resolver (usually your ISP's or one you've configured like 8.8.8.8) to translate the human-readable name into a number like 93.184.216.34. Without this step, no data moves.
Step 2: TCP Connection
Your computer initiates a TCP connection to that IP address on port 443. TCP is a reliable protocol — it guarantees delivery and order. It does this via a "three-way handshake":
Your computer → SYN → Server
Your computer ← SYN-ACK ← Server
Your computer → ACK → Server
[Connection established]
SYN means "I want to connect". SYN-ACK means "OK, I'm ready". ACK means "Got it, let's go." This takes one full round-trip before any data moves.
Step 3: TLS Handshake
Because it's HTTPS, there's an encryption layer on top. Your computer and the server negotiate encryption settings and verify the server's identity using a certificate. This adds another round-trip (or half a round-trip with modern TLS 1.3).
Step 4: HTTP Request
Now your browser sends the actual request:
GET / HTTP/2
Host: example.com
Accept: text/html
This is a plain text message (technically over an encrypted tunnel) asking the server to send back the contents of /.
Step 5: Routing
Your request doesn't travel in one piece. It's broken into packets — each one roughly 1,500 bytes maximum. Each packet gets headers: source IP, destination IP, sequence number. Routers along the way read only the destination IP and decide the next hop:
Your laptop → Home router → ISP router → Internet backbone → Data centre router → Server
Each router makes an independent decision: "I don't know where this packet ends up, but I know this is the right direction for it." This is called hop-by-hop routing.
Step 6: Reassembly
Packets may arrive out of order — one might have taken a different route. TCP on the receiving end buffers them and reorders them by sequence number before handing data up to the HTTP layer. If a packet is lost, TCP detects the gap and requests a retransmission.
Step 7: Response
The server sends back packets containing the HTML. Your browser receives them, reassembles the content, and starts rendering. It discovers references to CSS, JavaScript, images — and starts new HTTP requests for each one.
The whole thing — DNS lookup, TCP handshake, TLS, request, response — typically takes 100-400ms for a fast server nearby. Overseas? 200-600ms minimum, because the speed of light through fibre is non-negotiable.
The Jargon Decoded
- IP Address — A unique number identifying a machine on the network. IPv4 looks like
192.168.1.1(4 billion possible addresses). IPv6 looks like2001:0db8::1(effectively unlimited). - TCP (Transmission Control Protocol) — The reliable transport layer. Guarantees packets arrive and in order. Has overhead because of handshakes and acknowledgements.
- UDP (User Datagram Protocol) — The fast, unreliable alternative to TCP. Fire and forget. Used for video streaming and gaming where speed matters more than perfection.
- Packet — A chunk of data with a header containing routing information. Maximum size is typically 1,500 bytes (the MTU, or Maximum Transmission Unit).
- Router — A device that reads packet destination addresses and forwards them toward their destination. Your home router is a small version of what ISPs run at massive scale.
- Port — A number (0–65535) that specifies which service on a machine should handle the traffic. Port 80 = HTTP. Port 443 = HTTPS. Port 22 = SSH.
- Latency — The time for a packet to travel from A to B. Measured in milliseconds. Fundamentally limited by the speed of light — London to New York is ~70ms minimum.
- Bandwidth — How much data can flow per second. High bandwidth doesn't mean low latency. A fast motorway still takes time to drive.
Why This Matters When You're Building
Every web app you ship lives on top of this stack. When your users complain about slowness, it's almost always one of three things: latency (server too far away), too many round trips (too many sequential requests at startup), or packet loss (bad network conditions).
If you instruct AI to "make it faster" without understanding this layer, you'll get vague suggestions. If you say "reduce the number of sequential HTTP requests on page load", you'll get concrete solutions.
Choosing where to host your server matters: a server in the US serving users in Australia adds 200ms of unavoidable latency to every request. CDNs exist precisely to solve this by caching content close to users.
Understanding TCP and packet loss explains why WebSockets exist, why long-polling works the way it does, and why UDP is used for real-time gaming and video calls. These aren't arbitrary choices — they're answers to real constraints.
What To Tell The AI
"My app feels slow on initial load. Analyse the network waterfall and tell me which requests are sequential that could be parallelised, and which resources could be moved to a CDN."
"I'm building a real-time multiplayer game. Explain whether I should use WebSockets or UDP for player position updates, and why the answer changes depending on whether I'm building a turn-based or fast-action game."
"My API server is in the US East region but most of my users are in Europe. What's the minimum latency penalty they're paying, and what are my options to reduce it without migrating the whole backend?"
"Explain what happens at the network level when a user on a 3G connection tries to load my app. What are the packet-level constraints I'm designing around?"
"My users are reporting intermittent timeouts. Walk me through the TCP-level reasons this could happen and what I should check in my server logs."
Common Misconceptions
"The internet is basically instantaneous." It's bounded by physics. London to Sydney is ~16,000km. Light through fibre travels at roughly 200,000km/s, so the absolute minimum round-trip is ~160ms. Real-world paths add routing hops and that becomes 250–400ms. No amount of optimisation beats physics.
"More bandwidth = faster website." Bandwidth and latency are different things. A site with 10 sequential requests of 1KB each is slower than a site with 1 request of 100KB, even on a fast connection, because each round trip costs latency. Most slow websites are latency-bound, not bandwidth-bound.
"Packets travel in a straight line." Packets are routed hop-by-hop by routers that don't know the full path — they just know the next best hop. Two packets from the same request can take completely different routes and arrive out of order. TCP handles the reordering.
"If my server responds quickly, the user sees it quickly." Server response time (TTFB — Time to First Byte) is only part of the story. There's also DNS lookup time, TCP handshake time, TLS negotiation time, and the time to transfer the actual bytes. A 10ms server response time still adds up to 300ms if there are multiple round trips before it even gets asked.
Sources
- How the Internet Works — Stanford CS101 — Clear, non-technical introduction from a university course
- Computer Networks: A Top-Down Approach (Kurose & Ross) — The standard textbook, chapters 1-2 for the overview
- Cloudflare Learning Center — How the Internet Works — Practical, well-illustrated explainer
- High Performance Browser Networking (Ilya Grigorik) — Free online book covering networking from a web performance perspective
- RFC 791 — Internet Protocol — The original IP specification from 1981, surprisingly readable