Every time you open a website… …something extraordinary happens. You type a name. You press Enter. And a page appears, almost instantly. But between that keystroke and that page lies a journey across cities, oceans, and machines. Let's follow one request across the internet.
The journey begins right here, on your device. Your browser works out what it needs: a page, from a server somewhere in the world. It hands the request to the operating system, which speaks a set of shared rules called protocols. Protocols are agreements. They let machines built by different companies understand each other. Data doesn't travel as one continuous stream. It is carried in small, manageable units called packets. Each packet carries a piece of the conversation, plus the information needed to deliver it.
First, the packet has to leave the room. Over Wi‑Fi, it travels as radio waves. Over Ethernet, as electrical signals in a cable. Either way, it reaches your router: the junction between your home and everything beyond it. Your phone, your TV, your game console. All of them share this same doorway. Inside your home, each device has a private address. To the outside world, they usually share one public address. The router keeps track of which conversation belongs to which device. This translation is called NAT.
But there is a problem. You typed a name: www.example.com. Computers don't route traffic by names. They route by numbers, called IP addresses. So your device asks a DNS resolver, usually run by your internet provider or a public service. DNS, the Domain Name System, is not one giant phonebook. It is distributed and hierarchical. If the answer isn't already cached, the resolver asks a root server, which points it to the servers for dot com. Those point it to the authoritative servers for example.com, which hold the actual answer. An IP address comes back. The resolver remembers it for a while, so next time is faster. The name is for humans. The address is for machines.
Now the request itself takes shape. At its heart is what your browser actually means: an HTTP request, asking for a page. The transport layer wraps it with port numbers and sequencing information. Protocols like TCP, or the newer QUIC, number the pieces, confirm delivery, and resend anything lost. The network layer adds source and destination IP addresses. This is what makes it a packet. And the link layer wraps it once more, as a frame, for the very next hop only. Layers inside layers. Each one solves one part of the problem. This is called encapsulation.
Before anything private is exchanged, the connection needs to be secured. With HTTPS, your browser and the server perform a TLS handshake. The server presents a certificate: a signed statement vouching that it really is example.com. The certificate proves identity. It doesn't encrypt the traffic by itself. Instead, both sides use key agreement to derive fresh session keys that never travel across the network. From then on, the contents are encrypted. Observers along the path see only scrambled data. They can still see which server you're talking to, and roughly how much. HTTPS protects content, not anonymity.
Now your packet leaves home. Your router hands it to your Internet Service Provider, over fiber, cable, DSL, or a cellular link. Your provider runs its own network: thousands of routers, switches and links. But your provider is not the internet. It is one network among tens of thousands. Home networks, providers, regional carriers, cloud platforms, content companies, universities, businesses. Each is run by a different organization. Together, they form a network of networks.
Pull back, and the scale changes. A city becomes a web of fiber. A country becomes a mesh of long-distance links. At the largest scale, high-capacity backbone networks carry enormous volumes of traffic between regions. Networks meet at interconnection points and internet exchanges, handing traffic to one another. No single company owns this. No single machine controls it.
And when your data needs to cross an ocean… …it usually doesn't go to space. It goes underwater. Hundreds of undersea fiber-optic cables lie across the ocean floor, some of them thousands of kilometers long. Inside, pulses of light carry data through strands of glass thinner than a human hair. Satellites matter, especially in remote places. But the vast majority of traffic between continents travels through these cables. The internet is not in the clouds. Much of it rests on the sea floor.
At every junction, a router makes a decision. It reads the destination address and looks it up in its forwarding table. Then it sends the packet to the next hop: one step closer, not the whole route. No router knows the entire internet. Each router makes forwarding decisions based on the information available to it. When a link is congested, traffic may shift to another path. Packets from the same conversation can take different routes and arrive out of order. TCP or QUIC puts them back together.
But how do large networks know where anything is? Each major network is an autonomous system: an independently run island, with its own routing policies. Using the Border Gateway Protocol, BGP, they announce which blocks of addresses they can reach. Neighbors pass these announcements along, choosing routes by policy, business relationships, and path length. BGP isn't a GPS with a perfect map. It is a constant exchange of claims between networks. When a link fails, those announcements are withdrawn, and traffic gradually finds another path.
Let's follow one packet, all the way. Laptop. Wi‑Fi. Router. Provider. Regional network. Backbone. Data center. Server. Each step adds a little delay. Propagation: the time for the signal to physically travel. Light in fiber covers about two hundred kilometers every millisecond. Transmission: the time to push the bits onto the link. Processing: the time for each device to examine the packet. Queuing: the time spent waiting in line when a link is busy. Individually tiny. Together, they're the latency you feel.
Our packet arrives at a data center. Rows of servers. Power, cooling, and a constant mechanical breath. Depending on the service, the request may first reach a load balancer, which spreads work across many machines. An application server builds the response. It might check a cache for recent results, or query a database. A single website can involve dozens of systems. And the server is often not one physical machine at all.
But what if the data center is on the other side of the world? Content delivery networks keep copies of popular content in edge locations, close to users. When you request an image, it can come from a nearby edge server instead of the distant origin. Shorter distance means lower latency. And the origin handles far less traffic. This is caching: keeping a copy where it's needed, and refreshing it when it changes.
The response begins its journey back. It isn't one giant file. The first response is usually an HTML document. That document refers to stylesheets, scripts, images, fonts and data, each fetched with its own request. Modern protocols carry many of these at once, over the same connection. A single page can trigger dozens, even hundreds, of network requests.
Back on your device, packets arrive and are reassembled in order. The browser parses the HTML into a tree of elements, called the DOM. CSS is applied to calculate styles. The layout engine works out where everything goes. JavaScript adds behavior. Images are decoded. Fonts shape every letter. Then the page is painted, layer by layer, and composited onto your screen. Much of the final work happens right here, on your own machine.
Two words describe speed, and they're often confused. Bandwidth is capacity: how much data can move each second. Think of the width of a highway. Latency is delay: how long data takes to arrive, and a response to come back. Think of the length of the trip. A wider road doesn't make a long trip shorter. That's why a fast connection can still feel slow when the server is far away, or a page needs many round trips.
Things break. All the time. A cable is cut. A router fails. A server is overloaded. Often, when alternate paths exist, traffic routes around the damage. But not always. If DNS is unreachable, names stop resolving. If the only link fails, a region can go dark. Resilience is not magic. It comes from redundancy, and from the people who build and repair it.
The internet feels invisible, because we reach it through glass screens. But underneath the interface is a vast physical system. Phones and routers. Cell towers and exchange points. Data centers, power plants, and cables under the sea. And people. Engineers, operators and technicians, keeping it running every hour of every day.
So when you open a webpage… Your device prepares a request. DNS finds the address. Routers across many networks pass it along. Encryption protects it. Servers answer. Your browser builds what you see. Real systems can be more complex. But that's the journey, often in less than a second. The internet is not one machine. It's tens of thousands of independent networks, choosing to cooperate. And the next time you type a web address… …the journey begins again.
Keys: space pause · ←/→ scene · M sound · C captions · N narration · T transcript · F full screen · Shift+D debug