How Data Moves Across a Network
Before TCP. Before HTTP. Before the Internet Got Fancy.
I'm a passionate backend dev
Let’s start with a question most of us never really stop to ask.
When you click a link, send a message, or refresh a page, how does that data actually move from your machine to another one somewhere far away?
Not which protocol is used.
Not which library handles it.
I mean the actual movement. How does information leave your laptop and show up on another computer that you’ve never seen?
To understand backend properly, we need to go below TCP and HTTP, before any comforting abstractions appear.
Imagine You Want to Send a Note to Someone Far Away
Let’s forget computers for a moment.
Imagine you write a message on a piece of paper. Now you want someone, far away, to read it. You immediately run into a problem. You can’t magically place that paper into their hands.
It has to travel, and that travel introduces uncertainty.
This simple problem is exactly what computers face too.
Computers Don’t Send Messages. They Send Signals.
Here’s the first thing that quietly changes everything.
Computers don’t send words. They don’t send requests. They don’t even send “data” in the way we imagine it.
They send signals.
Electrical signals through cables. Radio signals through the air. Everything else is something we humans layered on top to make sense of those signals.
From Signals to Bits
To make signals useful, we had to agree on a very simple rule.
A signal in one state means 1.
A signal in another state means 0.
That’s all. Once we agreed on that, suddenly everything became representable as bits.
Text, images, videos, money, messages. All of it eventually becomes long sequences of 0s and 1s.
Your friendly message like:
Hello
Slowly turns into something much less friendly:
01001000 01100101 01101100 01101100 01101111
It’s ugly, but it’s consistent. And consistency is enough to build systems.
Distance Is the Real Enemy
Now comes the hard part. Your laptop cannot directly send signals to a server on the other side of the world.
Signals weaken.
Noise interferes.
Physical limits exist.
So instead of one big jump, we do something more practical. We pass the data along.
Data Moves Hop by Hop
Data doesn’t travel in one straight line. It moves in small steps, hopping from one machine to another.
Your laptop sends data to your router.
Your router sends it to your ISP.
Your ISP passes it through multiple routers.
Eventually, it reaches the destination.
Each stop only knows one thing:
“Where should this go next?”
It doesn’t care what the message means. It doesn’t care who you are. It just forwards.
Why Data Is Broken into Small Pieces
There’s another very practical problem. Sending one huge chunk of data is risky. If something goes wrong halfway, everything is lost. So computers do something sensible.
They split data into small pieces and send them separately.
Each piece takes its own journey through the network.
Some may arrive early.
Some may arrive late.
Some may never arrive at all.
At this level, these pieces are just data with minimal direction attached.
There Is No “Conversation” Yet
This is important and often misunderstood.
At this stage, there is:
No connection
No guarantee anyone is listening
No confirmation the data arrived
You are essentially throwing information into the network and hoping it makes it through. It’s closer to shouting into the dark than having a phone call.
The Network Makes No Promises
The network is not clever. It’s not polite. It doesn’t reassure you. It never promises:
Delivery
Order
Reliability
Retries
It simply does its best. Sometimes your data arrives. Sometimes it doesn’t. This isn’t a flaw.
This honesty is what allows the network to scale globally.
Why This Feels Messy (And Why It Should)
At this raw level:
Data can be lost
Data can arrive out of order
Data can be duplicated
Data can be delayed
If this sounds uncomfortable, that’s a good sign. Because this chaos is exactly why higher-level systems exist. Nothing above this layer makes sense unless you accept that the foundation is unreliable.
A Simple Mental Image
Imagine throwing paper airplanes between buildings.
Some land perfectly.
Some fall short.
Some arrive out of order.
Now imagine trying to build something dependable on top of that. That’s what networking looks like before protocols step in.
This Is the Ground Floor of Networking
At this level, we only have:
Signals
Bits
Paths
Best-effort delivery
No structure. No guarantees. And yet, this is enough. Everything else in backend engineering is built on top of this shaky ground.
Why Backend Engineers Should Care
If you skip this mental model:
Protocols feel like magic
Failures feel random
Debugging feels frustrating
If you understand this layer:
TCP feels necessary
HTTP feels obvious
Retries and timeouts make sense
You stop memorizing behaviors. You start reasoning about systems.
What Comes Next
We’ve seen the messy foundation. The next natural question is unavoidable:
“How do we make something reliable on top of this?”
That’s where TCP comes in.
➡️ Next article:
Why TCP Exists: Making Unreliable Networks Useful
This article is part of the Thinking in Backend series, where we learn backend engineering by focusing on how systems think, not just how code runs.
