How the internet works comes down to five protocols firing in sequence: DNS finds the server, TCP connects to it, TLS secures the channel, BGP routes packets across networks, and HTTP carries the actual request. You type a URL, hit Enter, and all of that happens in milliseconds, before a single pixel appears.
This guide follows one request from Enter to first pixel. You'll see what each layer does, why it was designed that way, and where it breaks. Then you'll learn the habits that keep your code standing when the network falls over, because sooner or later it will.
- The internet is thousands of independent networks joined only by shared protocols.
- Every request goes through DNS, a TCP handshake, a TLS handshake, BGP routing, then HTTP.
- Each handshake round trip crosses the full distance, so far-away servers cost more before any data moves.
- curl -v prints every layer, so you can see exactly where a request stalls.
- Give every call a timeout, retry safe calls with backoff, budget for latency and respect DNS TTLs.
- 0:00Intro
- 0:21Your code lives on the network
- 1:04A network of networks
- 1:53Built to survive failure
- 2:30DNS turns names into addresses
- 3:12Handshake first, then encrypt
- 3:48Packets hop the globe via BGP
- 4:30HTTP asks, the browser renders
- 5:19Every fetch rides this stack
- 5:51Trace one fetch call live
- 6:43Four ways the network bites back
- 7:36The whole trip, start to finish
- 8:00The network fails. Code like it.
Why does code that works on localhost fail in production?
It works on your laptop. You deploy it, and users see a spinner that never stops. Not one line of code changed. The bugs you can't reproduce locally usually live in the gap between two machines, and on localhost that gap doesn't exist.
Two things hide there. The first is hidden latency. Every real request crosses real distance and passes through real routers. Your laptop skips both, so a page that feels instant to you can crawl for a user on the other side of the world.
The second is silent failure. Packets get dropped, connections stall, and servers disappear mid-request. If you don't know which layer broke, you're debugging blind. Knowing the stack is how you stop guessing.
- Hidden latency: distance and routers that localhost never shows you
- Silent failures: dropped packets, stalled connections, vanished servers
What is the internet? A network of networks
The internet isn't one network. It's thousands of independent networks stitched together, passing your data along like a relay race. Your home ISP, a mobile ISP, backbone carriers, cloud providers and university networks all exchange traffic as peers, router to router, until each piece reaches its destination.
That traffic moves as packets, not streams. Your data is chopped into small packets, each stamped with a destination address. They can take different paths and arrive out of order, so something at the other end has to put them back together.
Nobody owns the whole thing. Thousands of organisations simply agree to speak the same protocols, and those shared rules are the only glue holding it together. That means there's no central switch to flip, and no central switch to break.
Why was the internet built to survive failure?
The design goes back to ARPANET and one goal: no single point should be able to take everything down. Compare two designs. In a central hub, every message passes through one switch. It's easy to build and just as easy to break. When the hub dies, the whole network goes dark.
ARPANET chose a distributed mesh instead. There are many paths between any two nodes, so if a link fails, traffic routes around the damage. With no single point of failure, losing one piece doesn't stop the rest.
That decision still shapes every protocol you use. Lost and rerouted packets are expected, not exceptional, and the protocols are built to cope. Failure isn't a bug in the internet. It's assumed. Your code should assume it too.
- Central hub: one switch, one failure, total outage
- Distributed mesh: many paths, lose a link, route around it
How does DNS turn a domain name into an IP address?
The trip starts with a translation problem. You typed a name, but routers only understand numbers. DNS, the Domain Name System, takes the domain name and returns an IP address.
Here's the lookup for shop.example.com. The browser checks its cache and misses. It asks a resolver, which asks a root server. The root server points to the .com TLD server. The TLD server points to the name server for example.com. Finally, the authoritative server answers: 203.0.113.7. Now you have an address.
That answer is cached everywhere. Your browser, your operating system and the resolver each keep it until its TTL, or time to live, expires, so the next lookup costs almost nothing. The catch is that a stale cache can send traffic to the wrong server.
- Browser cache → miss
- Resolver → ask a root server
- Root server → try the .com TLD
- TLD server → ask example.com's name server
- Authoritative server → 203.0.113.7
What happens during the TCP and TLS handshake?
An IP address isn't a connection yet. Your browser needs a reliable, private channel to the server, and it builds one in two layers: TCP first, then TLS on top.
The TCP handshake is three messages: SYN from the browser, SYN-ACK from the server, and ACK back. Both sides have now agreed to talk. Then TLS starts. The browser sends a ClientHello, and the server replies with a ServerHello plus its certificate, so the browser can verify who it's talking to. Only after that does the encrypted request go out.
Each of those arrows crosses the full distance to the server and back before any real data moves. Round trips add up. For a far-away server, connection setup can cost more time than the request itself.
- TCP: SYN → SYN-ACK ← ACK →
- TLS: ClientHello → ServerHello + certificate ←
- Then the encrypted request →
How do packets find the server? BGP routing explained
Your server probably isn't next door, and no single company controls the path to it. So how does a packet find its way? One hop at a time. Your laptop hands it to your home router, which passes it to your ISP. From there it crosses the backbone, enters the cloud provider's network and finally lands on the web server.
BGP, the Border Gateway Protocol, makes those hops possible. Each network announces to its neighbours which addresses it can reach, and routers choose paths based on those announcements.
Those paths can change. A link goes down or a route is updated, and your packets suddenly take a longer path, sometimes in the middle of a session. Latency isn't constant: the same call can be fast now and slow a minute later.
How HTTP requests and browser rendering work
Once the connection is secure, the browser finally asks for something. It sends an HTTP request inside the encrypted tunnel. The first line holds the method and path, GET /products. The Host header names shop.example.com, and Accept asks for HTML. The server answers with HTTP 200 OK and a content type.
That 200 often hides more work. Before replying, the server may query a database, check a cache or call other services, and each of those is a network call of its own. One request can fan out into many.
Then the browser parses the HTML and fires off more requests for CSS, scripts and images. A single page load is really dozens of trips through this same stack. And it isn't only browsers: REST APIs, video streaming, multiplayer games and IoT devices all need the same lookup, connection and route. Learn it once, and you can debug all of them.
GET /products HTTP/1.1
Host: shop.example.com
Accept: text/html
# server replies
HTTP/1.1 200 OK
Content-Type: text/htmlHow to trace a request with curl -v
You can watch all of this happen yourself. Run curl in verbose mode against a cart API, and every layer prints its own lines. The host is resolved to 203.0.113.7, which is DNS. curl tries port 443 and connects, which is TCP. It negotiates TLS 1.3, sends GET /api/cart and gets back HTTP/2 200.
Because each protocol logs separately, a hanging request shows you exactly where it stopped. That gives you a debug map. Stuck after "Trying"? Look at the network or a firewall. Failing at SSL? Check the certificate. Got a 500? The server is the problem. You stop guessing and start pointing.
- Stuck after Trying → network or firewall
- SSL error → certificate
- HTTP 500 → server
curl -v https://shop.example.com/api/cartCommon network mistakes programmers make (and fixes)
Real apps rarely break in clever code. They break because the code assumes the network just works. That one belief produces four classic bugs: being latency blind, with chatty calls that pile up; serving stale DNS after a migration; making calls with no timeouts; and having no retries.
The fixes are small. Budget for latency: batch requests, cache results, avoid long chains of sequential calls, and test on a throttled connection instead of just localhost. Give every network call a timeout. A single call without one can hang a worker forever. Retry idempotent calls with backoff.
Respect DNS TTLs, too. Lower the TTL before you move a server, and never hardcode IPs or cache them forever in your own code. Each fix takes minutes. Skipping one can cause an outage.
- Latency blind → batch, cache, test throttled
- No timeouts → timeout on every call
- No retries → retry safe calls with backoff
- Stale DNS → lower TTLs before moves, never hardcode IPs
The bottom line
- The internet is a network of networks with no single owner and no single point of failure.
- DNS resolves the name, TCP connects, TLS encrypts, BGP routes and HTTP carries the request.
- Handshake round trips and changing routes mean latency is real and never constant.
- curl -v shows which layer a request stalls on.
- The network is unreliable by design, so use timeouts, retries, latency budgets and DNS TTLs.
Quick-fire questions
What happens when you type a URL and press Enter?
DNS turns the domain name into an IP address, then TCP and TLS handshakes set up a secure connection. BGP routes the packets across networks to the server, and HTTP sends the request and brings back the response for the browser to render.
What's the difference between TCP and TLS?
TCP sets up a reliable connection with a three-step handshake: SYN, SYN-ACK, ACK. TLS runs on top of it, lets the browser verify the server's certificate and encrypts everything that follows.
Why is my API fast locally but slow in production?
Localhost skips the real distance, routers and handshake round trips that every production request goes through. Routes can also change mid-session, so latency rises and falls. Test on a throttled connection to see what users actually experience.
What is BGP and why does it matter to developers?
BGP, the Border Gateway Protocol, is how networks tell their neighbours which addresses they can reach, and routers pick paths from those announcements. When a link fails or a route changes, packets can take a longer path, so the same call may be fast now and slow a minute later.
Why shouldn't I hardcode IP addresses?
Servers move, and DNS is how clients find the new address. A hardcoded or permanently cached IP keeps pointing at the old server. Lower the DNS TTL before a migration so cached answers expire quickly.
How do I find which network layer is failing?
Run curl -v against the endpoint. If it stalls after "Trying", suspect the network or a firewall. An SSL error points to the certificate, and a 500 points to the server.
