A deep, practical reflection on the decades of engineering that make the modern internet possible—servers, data centers, fiber, protocols, browsers, and the web stack—and why today’s AI depends on this foundation.
The most impressive “AI demo” is a webpage loading in 200 milliseconds
It’s easy to feel like we’re living at the peak of human engineering when we watch a model write code, draft a contract, or generate a photorealistic scene on demand. Modern AI is a genuine technological leap. But there’s a quiet risk in the way we talk about it: we start acting as if everything impressive began around the time we started prompting.
Meanwhile, something astonishing happens all day, every day, with almost no fanfare: you type a URL, press Enter, and a page appears—sometimes from the other side of the planet—in a fraction of a second. Text is crisp. Images snap into place. Buttons respond instantly. Videos buffer barely at all. Your browser has negotiated encryption, located a server, routed packets through a maze of networks, and reconstructed a coherent document out of streams of bytes that took different physical paths across oceans and continents.
This isn’t “just the internet” as a vague idea. It’s an orchestration of decades of work across electrical engineering, computer science, telecommunications, standardization bodies, hardware manufacturing, and operations disciplines. It’s one of the most remarkable collective engineering achievements in human history—and modern AI is built on top of it in the most literal sense: AI systems train on internet-scale datasets, deploy via cloud networks, and deliver responses through the same protocols and infrastructure that make a webpage possible.
If you want a more grounded sense of wonder in the age of AI, it helps to look down at the foundation.
The internet isn’t a thing; it’s an agreement, repeated billions of times
A useful way to see the internet is not as a single technology, but as a stack of agreements—interfaces and protocols—implemented by countless independent actors who mostly don’t trust each other, yet still manage to interoperate.
A few of the core “agreements”:
- IP (Internet Protocol): a common addressing and packet format so any two machines can exchange data across many intermediate networks.
- Routing (especially BGP): a way for networks operated by different organizations to announce which IP ranges they can reach and how.
- TCP/UDP/QUIC: rules for reliable delivery (or fast delivery) across unreliable networks.
- DNS: a globally distributed naming system that maps human-readable names to addresses.
- TLS: encryption and authentication at internet scale.
- HTTP: a standardized request/response model for fetching resources.
- HTML/CSS/JS: a universal application layer for expressing documents, layout, and interactive behavior.
- Browser engines: a common runtime that interprets those technologies consistently enough for “the web” to exist.
What’s staggering is not that any single protocol exists, but that they work together across:
- different countries and regulatory environments,
- different hardware architectures,
- different operating systems,
- wildly different network qualities,
- and competing commercial interests.
And still: your phone loads a page on a café Wi‑Fi as if the world were one coherent computer.
From keystroke to pixels: what actually happens when you load a webpage
To appreciate the achievement, it helps to trace the path from “Enter” to “rendered pixels.” The steps below happen so quickly that your brain experiences them as a single event, but they’re a chain of coordinated systems.
1) Your browser parses the URL and decides what to ask for
A URL encodes more than a destination—it encodes a method of access:
https://implies using HTTP over TLS (encrypted).example.comis a DNS name that must be resolved./pathidentifies a resource on that host.
Even before the first packet leaves your device, the browser consults caches, security policies, HSTS rules, and sometimes preloads known assets. “Loading a page” begins with local decisions.
2) DNS: finding an address in a global, distributed phonebook
Humans don’t navigate by IP addresses; networks do. DNS bridges that gap.
Under the hood, resolving example.com may involve:
- checking your browser cache,
- checking the OS cache,
- asking a recursive resolver (often your ISP, enterprise network, or a public resolver),
- which in turn may query:
- root servers (to find the TLD),
- TLD name servers (to find authoritative servers),
- authoritative servers (to get the A/AAAA records),
- plus possible indirections like CNAMEs, and optimizations like EDNS Client Subnet for geolocation.
This system is distributed, hierarchical, cached, and designed to degrade gracefully. It’s also been hardened over time with features like DNSSEC (though adoption varies) and operational practices that keep it stable despite being a frequent target for abuse.
The result of all that: a number (an IP address) that tells your device where to send packets.
3) Routing: how packets traverse the planet without a central controller
Once you have an IP address, you might assume there’s a global map that says “take this route.” There isn’t.
Instead, the internet is a federation of networks called autonomous systems (ASes)—ISPs, cloud providers, universities, enterprises—connected by peering agreements and transit relationships. The protocol that stitches these networks together is BGP (Border Gateway Protocol).
BGP is one of the internet’s most underappreciated achievements and one of its most delicate compromises:
- It scales to the size of the global routing table.
- It allows independent networks to make their own policies.
- It converges (eventually) when links fail.
- It is also vulnerable to misconfigurations and hijacks, which is why operational discipline and mitigations (like RPKI) matter so much.
When you load a webpage, your packets are hop-by-hop forwarded by routers that only need local knowledge: “for this destination prefix, send to that neighbor.” The “path” emerges from many local decisions.
4) The physical layer: fiber, photons, and the geography of latency
Under every abstract protocol is physics.
Most long-distance internet traffic rides on fiber-optic cables. In a fiber, data is encoded into light, and that light is amplified and multiplexed across wavelengths using technologies like DWDM (Dense Wavelength Division Multiplexing). Undersea cables cross oceans, landing at coastal stations and connecting to terrestrial backbones.
Latency is constrained by:
- the speed of light in fiber (slower than in vacuum),
- the route geography (cables do not go perfectly straight),
- the number of hops and optical/electrical conversions,
- queuing and congestion.
That’s why “milliseconds” is already incredible. A round trip from Europe to the US East Coast is bounded by physics; engineers spend huge effort shaving milliseconds through better peering, smarter routing, and edge caching.
5) Transport and security: establishing a connection you can trust
Modern web traffic is typically https, meaning:
- a transport handshake (TCP or QUIC),
- plus a TLS handshake for encryption and identity.
In the TCP + TLS world, the browser and server negotiate:
- cryptographic parameters,
- certificates and trust chains to a root CA,
- session keys,
- and sometimes application protocols via ALPN (e.g., HTTP/2).
With QUIC (used by HTTP/3), some of these steps are fused and optimized to reduce latency, especially on mobile networks where packet loss is common.
The point isn’t just secrecy; it’s integrity and authenticity. Without TLS, the “global web” would be a constant exercise in interception and tampering. The fact that browsers can validate certificates at scale—and that certificate transparency, revocation mechanisms, and ecosystem rules mostly work—is its own silent miracle.
6) HTTP: requesting documents and assembling a page from many resources
Now the browser can finally ask:
“GET /path HTTP/2” (or HTTP/3)
But a “webpage” is rarely one file. It’s an entry point—an HTML document that references:
- CSS stylesheets,
- JavaScript bundles,
- images,
- fonts,
- APIs,
- analytics endpoints,
- video segments,
- and more.
The browser becomes a resource scheduler. It prioritizes critical assets, pipelines requests (especially with HTTP/2 multiplexing), reuses connections, and leverages caching headers (Cache-Control, ETag, Last-Modified) to avoid unnecessary transfers.
A good modern page load is as much about not downloading as it is about downloading.
Data centers: the industrial machinery behind “the cloud”
People say “the cloud” as if it were a metaphor. It’s not. It’s an industrial-scale arrangement of:
- servers (compute),
- storage systems,
- network fabrics,
- power distribution,
- cooling,
- physical security,
- and operational processes.
A request that looks simple from a browser may fan out behind the scenes to:
- a load balancer,
- an edge proxy,
- a service mesh,
- multiple microservices,
- databases and caches,
- queues and stream processors,
- observability pipelines (logs, metrics, traces).
And it must do so reliably, under bursty load, with failures happening constantly—because in large systems, something is always failing.
Two ideas underpin the web’s reliability:
- Redundancy: multiple servers, multiple links, multiple power feeds, multiple regions.
- Automation: orchestration systems that replace failed instances, reroute traffic, and scale capacity.
This is the less romantic side of the internet, but it’s a crucial part of the achievement: the internet is not just protocols; it’s operations at planetary scale.
CDNs and the edge: cheating latency by moving the internet closer to you
One of the reasons the web feels fast is that it often doesn’t travel as far as you think.
Content Delivery Networks (CDNs) replicate and cache content at edge locations near users—sometimes inside ISP networks. When you request a popular image or a JavaScript bundle, you might be served from a node within your city rather than a distant origin data center.
CDNs also provide:
- TLS termination at the edge,
- DDoS protection,
- request filtering (WAF),
- smart routing and origin shielding,
- image/video optimization.
This is another quiet coordination victory: your browser doesn’t need to know about any of it. DNS, Anycast routing, and CDN control planes make the “nearest” edge node appear as the correct destination.
Browsers: a universal runtime that turns bytes into meaning
It’s easy to treat the browser as an app that “shows websites.” In reality, it’s one of the most sophisticated pieces of software most people run.
A browser must safely execute untrusted code (JavaScript) from millions of sources while:
- isolating sites from each other (sandboxing, site isolation),
- enforcing permissions,
- preventing memory corruption exploitation as much as possible,
- delivering performance on everything from high-end desktops to low-power phones.
HTML: the document model the world agreed to share
HTML is deceptively simple: tags that describe structure. But the real power is that HTML creates a DOM (Document Object Model)—a tree the browser can traverse, manipulate, and render.
The HTML parser is famously complex because it must be compatible with decades of content “in the wild.” Browsers learned to be forgiving not because it’s elegant, but because interoperability demanded it.
CSS: a layout and styling engine built for human expression
CSS is not “colors and fonts.” It’s a constraint-solving and layout system:
- cascade and specificity rules,
- box model,
- flexbox and grid,
- reflow and repaint,
- compositing,
- GPU acceleration.
The fact that designers can express rich layouts declaratively, and that engines can compute them quickly, is a triumph of both language design and performance engineering.
JavaScript: interactivity, applications, and a sandboxed compute layer
JavaScript evolved from small scripts to a platform for applications. That evolution required:
- JIT compilation,
- garbage collection,
- event loops and async APIs,
- Web APIs (fetch, storage, workers),
- security boundaries.
When you load a modern app, you’re effectively downloading a program, verifying it, executing it, and granting it carefully scoped capabilities—within milliseconds—without the user thinking of it as “installing software.”
The web became a universal app runtime not by accident, but by relentless iteration and standardization.
Standardization: the social engineering that made the technical engineering possible
The internet’s technical stack is inseparable from its governance model:
- open standards,
- rough consensus,
- reference implementations,
- interoperability testing,
- backward compatibility,
- and a bias toward incremental deployability.
Bodies like the IETF and W3C, along with browser vendors, network operators, academics, and independent engineers, shaped a system where no single entity “owns” the whole. That’s messy, slow, and political at times—but it’s also why the web is resilient.
A key theme: internet technologies are often engineered to be adoptable in parts. You can deploy a new HTTP version, a new cipher suite, a new routing policy, a new browser feature—without requiring everyone on Earth to upgrade on the same day.
That kind of evolvability is one of the internet’s greatest design achievements.
The hidden difficulty: the internet works despite being hostile terrain
The wonder isn’t only in performance; it’s in robustness under adversarial conditions.
The internet operates while facing:
- packet loss,
- noisy radio links,
- misconfigured routers,
- accidental fiber cuts,
- natural disasters,
- power instability,
- nation-state interference,
- spam and botnets,
- constant vulnerability discovery,
- and deliberate attacks (DDoS, BGP hijacks, phishing).
Yet, for most users most of the time, it works well enough to feel like a utility.
That “utility feeling” is the final magic trick: the infrastructure is so effective that it becomes invisible.
Why AI is not separate from this story—AI is downstream of it
Modern AI can feel like a new layer of reality: a machine you talk to that responds with knowledge. But nearly every part of that experience depends on the internet’s foundation.
Training: datasets, storage, and transfer at planet scale
Training frontier models requires:
- massive datasets (often scraped, filtered, and deduplicated from the web),
- distributed storage systems,
- high-throughput networks between compute nodes,
- optimized transport protocols and data pipelines.
Even inside a single data center, the networking resembles a miniature internet: leaf-spine topologies, congestion control, load balancing, failure handling. At the global level, model training and dataset preparation lean on the same undersea cables, peering links, and backbone capacity that deliver webpages.
Deployment: low latency depends on the same tricks as the web
Serving AI in real time requires:
- global load balancing,
- edge points of presence,
- caching (for static assets and sometimes for responses),
- TLS, HTTP, and browser-based clients,
- observability and incident response.
When an AI chat interface feels “instant,” you’re seeing the same accumulated craftsmanship: optimized routing, efficient protocols, good CDNs, carefully tuned backends.
The interface: AI is consumed through the web stack
Even when AI runs in a native app, the control plane is typically web infrastructure:
- API gateways,
- HTTP requests,
- authentication flows,
- web views,
- browser engines,
- JavaScript frontends.
The default UI of the modern world is still: HTML, CSS, and JavaScript—running inside a browser that speaks HTTP over TLS over IP.
AI didn’t replace the web; it rides it.
A concrete walkthrough: the orchestration hiding inside a single page load
Imagine opening a news site on your phone.
In the time it takes you to blink:
- Your device connects to Wi‑Fi or LTE, negotiating local access.
- DNS resolution returns an IP, likely pointing to a CDN edge.
- BGP and ISP routing determine the physical path to that edge.
- A TLS handshake establishes encryption and authenticates the site.
- HTTP/2 or HTTP/3 begins streaming HTML.
- The browser parses HTML into a DOM, discovers CSS/JS, schedules fetches.
- CSS is parsed into a CSSOM; layout and paint begin.
- JavaScript bootstraps, attaches event handlers, requests APIs.
- Images are fetched—often from a different domain, different cache, different policy.
- The page becomes interactive, while background requests continue.
- Ads and analytics load—controversially, but technically: more distributed orchestration.
- All of this is observed: logs, metrics, and traces flow to monitoring systems so engineers can keep it stable.
No single team built this end-to-end. It’s a collaboration across industries and decades. Your browser is the conductor, but the orchestra is the world.
Seeing the internet again: how to recover a sense of wonder without romanticizing
Appreciating the internet doesn’t mean ignoring its downsides—privacy failures, misinformation, monopolistic pressures, security problems. In fact, seeing the infrastructure clearly makes those issues more concrete, not less.
But there’s value in remembering what the internet represents at its best:
- a system that can route information around failures,
- a platform where a small team can publish to the world,
- a shared runtime where ideas become software that anyone can access,
- and a set of standards that let diverse systems cooperate.
In the age of AI, it’s tempting to focus on the novelty at the top of the stack. Yet the deeper miracle is that we have a global substrate capable of moving knowledge, culture, and computation across the planet in milliseconds—reliably enough that we build ever more ambitious systems on it.
Modern AI is remarkable. But it is, in a very real engineering sense, a guest in a house built by generations of network engineers, protocol designers, data center operators, browser implementers, and standards communities.
The next time a page loads instantly—or an AI response arrives with uncanny speed—it’s worth pausing on the invisible choreography beneath it: photons through glass under oceans, routers exchanging routes, cryptography negotiating trust, servers balancing load, browsers turning markup into meaning.
That quiet choreography is not background. It is one of humanity’s greatest inventions.