The Life of a Network Packet: A 14K Kms Journey in 200ms

You're sitting in a café in Bengaluru. You tap a link. A webpage loads. The whole thing took maybe a second.

But in that one second, something extraordinary happened. A tiny bundle of data left your laptop, got converted into light, shot under the Indian Ocean, hopped across three continents, knocked on the door of a server in Virginia, got an answer, and brought it all the way back to your screen.

This is the story of that journey.

First, Let's Shrink Ourselves Down

Imagine you need to send a book to a friend who lives on the other side of the world. You wouldn't stuff all 500 pages into one envelope — it'd be too heavy, too fragile, too likely to get lost. Instead, you'd tear out each chapter, put it in its own envelope, number them, and mail them separately. Your friend would collect all the envelopes, sort them by number, and reassemble the book.

That's basically what your computer does with data.

When you tap that link, your browser doesn't send a single massive blob of information. It breaks everything into small, manageable chunks called packets. Each packet is typically around 1,500 bytes — roughly the size of a single page of plain text.

Each packet gets its own envelope. And on that envelope is written:

Where it came from (your IP address)
Where it's going (the server's IP address)
What number it is in the sequence (so the other side can reassemble them in order)
A checksum — a small math trick to make sure nothing got corrupted along the way

Think of it like a self-addressed, numbered, tamper-proof envelope. That's your packet.

Now let's follow one of these packets out the door.

Step 1: Leaving Your Device

Our packet starts its life inside your laptop's memory. Your browser hands it to the operating system and says, "Send this." The OS looks at the destination address and thinks: that's not on my local network. I need to send this to my default gateway — the router.

But before your laptop shoves thousands of envelopes out the door, it needs to make sure the server on the other side of the world is actually listening. So a tiny, invisible conversation happens first. Your machine reaches out and says, "Let's talk" (SYN). The server replies, "Sure, let's talk" (SYN-ACK). Your machine confirms, "Great" (ACK). Three messages. A connection is established. This is called a TCP three-way handshake, and it happens in the background before a single byte of real data leaves your machine. Now the two sides are officially talking.

With that settled, the packet is ready to leave. But there's a problem. The packet knows its final destination — an IP address in Virginia. That's great for the big journey, but right now, it just needs to get from your laptop to the café's router, which is sitting two metres away. Your laptop's Wi-Fi chip doesn't care about Virginia. It needs to know: which physical device on this local network am I handing this to?

That's where MAC addresses come in. Every network device — your laptop, the router, your phone — has a unique MAC address burned into its hardware. It's not a location on the internet. It's more like a name tag on a specific piece of equipment.

Your laptop wraps the packet in one more layer — a frame — with the router's MAC address on it. Think of the IP address as the final postal destination (Virginia, USA), and the MAC address as handing that envelope to the specific courier standing in your café. The courier bag gets the packet from your laptop to the router. Once it arrives, the courier bag gets discarded, and the original IP envelope continues its journey.

If you're on Wi-Fi, this first leg happens as radio waves, pulsing through the air between your laptop's antenna and the router's. If you're plugged in via Ethernet, it's tiny electrical pulses racing through a copper cable.

Either way, the packet just took its very first step.

Step 2: The Router — Your Packet's First Decision Point

The café's router receives the packet and peels off the outer layer (the frame). Now it's looking at the IP envelope inside.

"Where is this headed?" it asks. It sees the destination IP and checks its routing table — a small map of the internet as the router understands it. The router doesn't know the full path to Virginia. No single router does. It just knows the next step. It's like asking someone for directions in a city you've never been to, and they say, "I don't know where that is exactly, but go down that road and ask again."

The router decides the packet should go to your ISP — your Internet Service Provider. It wraps the packet in a fresh frame, addresses it to the ISP's nearest router, and sends it out through the fibre optic cable connected to the café.

And this is where things start to get fast.

Step 3: Into the Fibre

Your packet, which has been electrical signals or radio waves so far, now becomes light.

At the boundary between copper and fibre, a small laser diode converts the packet's ones and zeros into pulses of infrared light. These pulses enter a glass fibre that's thinner than a human hair — about 125 micrometres across. The light bounces along the inside of this glass strand through a principle called total internal reflection. The glass is so pure that if you made a window out of it, you could see through it even if it were kilometres thick.

Your packet is now travelling at roughly 200,000 kilometres per second — about two-thirds the speed of light in a vacuum. It's slower than light in empty space because the glass is denser than air, but still, it crosses a city in microseconds.

This fibre connects the café to your ISP's nearest Point of Presence (PoP) — a building full of networking equipment where traffic from thousands of homes and businesses converges.

Step 4: Climbing the Internet's Hierarchy

The internet isn't flat. It's shaped like a hierarchy, and your packet is about to climb it.

At the bottom is your local network — the café's narrow lane. Above that is your ISP, acting like a state highway. And above them are the backbone carriers — the massive, six-lane global motorways that connect continents.

When your packet hits the ISP's main router, it faces a massive intersection. The destination is Virginia, USA. The router consults its routing table — this one is much larger, with hundreds of thousands of entries — and makes its decision. But it doesn't just guess. It relies on the internet's invisible navigation system: BGP (Border Gateway Protocol).

BGP is a constant, global chatter between networks. Every major router is whispering to its neighbours: "I can reach these addresses, and it'll take this many hops." Over time, each router builds a map of the most efficient paths to every corner of the internet. It isn't centrally planned. Nobody designed this map from the top down. It assembles itself, like ants finding the shortest path to food. Each router makes local decisions, and the global system just works.

Most of the time.

Based on this chatter, the router decides the fastest path right now runs through a submarine cable stretching from Karnataka across the Indian Ocean.

The decision is made in microseconds. Your packet is routed to the coast.

Step 5: Crossing the Ocean Floor

Now your packet reaches one of the most remarkable pieces of infrastructure on the planet: a submarine cable.

There are over 500 submarine cables criss-crossing the world's oceans right now. Some are over 20,000 kilometres long. They sit on the ocean floor, sometimes at depths of over 6,000 metres. They carry 99% of all intercontinental internet traffic. Not satellites. Physical cables. On the seabed.

The cable your packet enters is roughly the thickness of a garden hose. Inside it are pairs of incredibly pure glass fibres, protected by layers of steel wire, copper sheathing, and polyethylene. Near coastlines, where cables are vulnerable to ship anchors and fishing trawlers, they're armoured even more heavily and buried into the seabed.

But glass fibres, even incredibly pure ones, lose signal over distance. The light gets dimmer. So every 60 to 80 kilometres along the cable, there's a repeater — a small device sealed in a capsule on the ocean floor that amplifies the optical signal and sends it onward. These repeaters are powered by a constant electrical current running through the copper sheathing from landing stations on shore. They're designed to work for 25 years without maintenance. Because retrieving something from the bottom of the Indian Ocean isn't a casual Tuesday afternoon job.

Your packet, as pulses of light, races through the dark. From Karnataka, it crosses the Indian Ocean, surfaces at a landing station in the Middle East — say, Fujairah in the UAE. From there, it travels overland through another series of fibre optic cables and routers, racing into Europe. Then it dives back underwater, plunging into the Atlantic toward the east coast of the United States.

The entire ocean crossing — thousands of kilometres — takes about 70 to 80 milliseconds. That's less time than it takes you to blink.

Step 6: The Crossroads

Along this journey, your packet passes through several Internet Exchange Points (IXPs). These are physical locations — usually nondescript data centres — where different networks meet and exchange traffic directly.

Without IXPs, if you were on Network A and wanted to reach something on Network B, your packet would have to travel up through A's hierarchy, across a transit provider, and back down through B's hierarchy. Slow and expensive.

IXPs let networks shortcut this. They plug into a shared switching fabric in the same building and hand traffic to each other directly. DE-CIX in Frankfurt. LINX in London. AMS-IX in Amsterdam. These are some of the busiest intersections on the internet, handling terabits of data per second. Your packet might pass through one or two of these, seamlessly hopping from a European carrier to an American one, before continuing its sprint west.

Step 7: Arrival — The Data Centre

Your packet reaches the east coast of the US and enters a massive data centre — a building that might cover the area of several football fields, humming with the sound of thousands of servers and cooling systems.

Inside, the packet hits a load balancer — a traffic cop that decides which specific server should handle your request. The website you're visiting doesn't run on one computer. It runs on hundreds or thousands of them. The load balancer spreads the work so no single machine gets overwhelmed.

The chosen server receives your packet. Its network interface card converts the signals back into data. The operating system reassembles the information, hands it to the web server software, which processes your request — maybe looking something up in a database, maybe fetching an image from storage — and prepares the response.

Step 8: The Return Journey

The response gets broken into dozens of new packets, addressed back to your IP in Bengaluru, and pushed out the door.

The entire journey happens in reverse. Through the data centre's routers, under the Atlantic, through Europe, under the Indian Ocean, up through your ISP, through the café's router, and across the air to your laptop's antenna.

Two oceans. Three continents. Two hundred milliseconds.

Step 9: Reassembly — Putting Humpty Dumpty Together Again

Here's the thing about those response packets — they might not all take the same route back. One might travel through London, another through Marseille. Packet #4 might arrive before Packet #2.

This is where that TCP connection from Step 1 saves the day.

Every packet sent over TCP carries a sequence number. Your laptop uses these to put everything back in the correct order, no matter how jumbled the arrivals. If a packet goes missing — maybe a router dropped it because it was too busy — TCP notices the gap and asks the server to retransmit just that one.

TCP also manages flow control. If the server is blasting packets faster than your laptop can handle, TCP slows things down. If the network is congested, TCP detects the jam — usually by noticing dropped packets or rising latency — and reduces the sending rate. Then it gradually ramps back up, constantly probing for the maximum speed the network can handle.

This dance — slow down, speed up, slow down, speed up — is called congestion control. It's the invisible brake system that keeps the entire internet from collapsing under its own weight.

The Invisible Miracle

Let's zoom back out.

Your packet left your laptop. It was converted from electrical signals to radio waves to light. It crossed two oceans and passed through maybe 15 to 20 different routers, each one making a split-second decision about where to send it next. It traversed cables laid by ships on the ocean floor. It was amplified by repeaters sitting in the crushing darkness of the deep sea. It arrived at a specific building in a specific city on a specific server, got a response, and made it all the way back.

And you didn't notice. You just saw the page load.

This is what gets me about networking. It's an absolute miracle of engineering, and it's completely invisible. Nobody thinks about submarine cables when they scroll through social media. Nobody considers the BGP routing tables when they stream a video. The whole thing is designed to disappear — to work so well that you forget it exists.

Every time you tap a link, thousands of engineers' decades of work spring into action: the people who laid the cables, the ones who wrote the protocols, the teams who designed the routers, the crews who maintain the repeaters on the ocean floor.

Your packet didn't just travel the world. It travelled the accumulated work of generations.

And it did it before you finished your sip of chai.

If you found this interesting, you might enjoy learning about how DNS works (the internet's phone book), how TLS encryption wraps your packets in a layer of secrecy, or how CDNs bring content closer to you so packets don't have to travel as far. Each of these is its own rabbit hole — and each one is just as fascinating.