The Internet Throws Your Data Away
Right now, somewhere between you and this page, a machine is throwing away pieces of someone's data. When an internet router gets more data than it can pass on, the router simply drops the extra. Drops happen all day, every day, and the internet was built to expect them.
Yet a game you download arrives exact, down to the last of its billions of bits. A video call over the same Wi-Fi freezes, skips and turns into blocks. Same internet, same lost data, two very different results.
Make your guess. A 1 GB download crosses busy routers, and some of its pieces get thrown away. What happens to the file?
- It arrives with a few tiny errors that nobody notices
- The download fails and starts again from zero
- It arrives perfect, just a little later
- Nothing gets lost: downloads take a special safe road
Show answer
C. It arrives perfect, just a little later
Your computer notices every missing piece and asks for that piece again. The file arrives exact, and the cost is a short wait. A video call makes the opposite choice. By the end of this page you will know why.
Start with a message short enough to watch.
Send a message
You text a friend: meet me at the park at 6. Your phone doesn't send one long stream. The phone cuts the data into small pieces called packets, and each packet travels on its own.
Here each packet carries one word, so you can follow the words. A real packet holds up to about 1,500 letters' worth of data, so a photo from your phone becomes thousands of packets.
Your goal: watch the first message arrive. Then press Send again and tap a road while a packet is on it.
Three things happened. Packets took different roads and sometimes arrived out of order, and the numbers put the words back in place. After a road was cut, the next packets went around the cut. And a packet caught on the cut road vanished, until your phone sent that word again.
Each of those tricks has a reason. Start with the first: why chop a message into pieces at all?
Why chop it up?
In the early 1960s, the phone network worked the other way. A call reserved a whole chain of wires from one phone to the other for as long as the call lasted, even through the silences.
Two engineers proposed a different plan. In the United States, Paul Baran wanted a network that kept working even after parts of the network were destroyed. In Britain a few years later, Donald Davies wanted many computers to share the same lines. Davies named the small pieces packets.
An animation of three conversations sharing one line. Packets from three pairs of phones meet at a router, take turns on the single line between two routers, and split up again at the far router. The animation plays by itself, in a loop, and stops for a moment now and then so you can look at the shared line.
Text version
Three phones on the left each talk to a matching phone on the right, and each pair has its own colour. The three phones on the left join one router, the three phones on the right join a second router, and one line joins the two routers. Each phone sends packets in bursts, with gaps in between, so each phone's own road is often empty. At the first router the packets take turns: whenever one phone has nothing to send, a packet from another phone takes the slot. The shared line in the middle is always full of packets in all three colours, back to back. At the second router each packet goes down the road to its own receiver.
Packets from millions of people now share the same roads. So how does each packet know where to go?
Every packet has a label
Each packet carries a small label in front of its data, called the header. The header says who sent the packet, where the packet is going, and the packet's number in the message.
The "from" and "to" in a real header are IP addresses: numbers such as 203.0.113.7 that name a device on the internet, the way a street address names a house.
The label says where to go, but not how to get there. No packet carries a map. So who picks the road?
Routers ask their neighbors
At every crossing sits a machine called a router. The Wi-Fi box in your home is one. A router reads the "to" address on a packet and hands the packet to one neighbor, the neighbor closest to that address.
No router has a map of the whole internet. Each router learns the way from its neighbors: every so often, each router tells its neighbors how far away it is from each address.
Your goal: press Share once, again and again, until You shows how many roads away Friend is. Then cut a blue road and share again.
Friend's number spread outward one ring per round, like news passing through a crowd. No router ever saw the whole network. Yet the blue roads, put together, trace a shortest way from You to Friend.
Real routers trade this news all the time, and a message to a far-away website often crosses 10 to 20 routers. Routers that run out of room still throw packets away, and roads still break. So how does a message arrive whole?
Lost and sent again
Your phone and Friend's phone follow a set of rules called TCP. For every packet that arrives, Friend's phone sends back a tiny "got it" note, called an acknowledgement. When no "got it" note comes back in time, your phone sends that packet again.
An animation of a lost packet being sent again. Your phone sends packets 1, 2 and 3 to a friend, packet 2 is lost on the way, a timer runs out, and your phone sends packet 2 again. The animation plays by itself, in a loop, and stops for a moment just after packet 2 is lost.
Text version
Your phone is on the left and your friend's phone is on the right, with a row of three slots for the packets your friend has. Packets 1, 2 and 3 leave your phone one after another. Packet 2 disappears halfway across, and a red X marks the spot. Packets 1 and 3 arrive and fill their slots, and for each one your friend's phone sends back a "got it" note. A timer for packet 2 starts when packet 2 leaves. No "got it" note for packet 2 ever comes back, so the timer runs out, and your phone sends packet 2 again. The new packet 2 arrives and fills the empty slot, its "got it" note comes back before the second timer runs out, and the timer shows a check mark.
Packets can also arrive damaged: a burst of radio noise can flip a few bits. So each packet carries a short checksum, a number worked out from the data. When the checksum doesn't match the data that arrived, the receiver throws the packet away, and the missing packet gets sent again.
How TCP really does it
A handshake first. Before any data moves, the two computers trade three short packets to agree on a starting number. Then every byte of data has its own number, so the receiver knows exactly which bytes are missing.
"Got it" notes count. A real acknowledgement says "I have everything up to byte so-and-so". When packets after a gap keep arriving, the receiver keeps repeating the same number. Three repeats tell the sender to resend at once, without waiting for the timer.
The timer adapts. The sender measures how long a round trip takes and sets its wait a little longer than that. A round trip across town can take a few thousandths of a second; across an ocean, often around a tenth of a second.
Loss means slow down. Many packets in flight keep the line busy, so TCP keeps sending more and more before hearing back. A lost packet usually means some router's line was full, so TCP cuts its speed and builds back up. That is why a download's speed wobbles.
Resending sounds like a small patch. How much does resending actually matter?
A 2,000-packet photo crosses a bad link that loses 1 packet in 100. With no resending, what is the chance that every packet arrives?
- About 99 in 100
- About 1 in 2
- About 2 in a billion
Show answer
C. About 2 in a billion
Each packet makes it 99 times in 100, but all 2,000 packets must make it. That is 0.99 multiplied by itself 2,000 times: about 0.000000002. Without resending, almost no photo would ever arrive whole.
Resending turns that hopeless 2-in-a-billion into a sure thing, and costs only about 20 extra packets out of 2,000.
Show the math (try it yourself first)
- One packet. Each packet is lost with chance \(p\), so each packet arrives with chance \(1-p\).
- All the packets, no resending. If one packet's luck doesn't affect another's, the chances multiply:\[ P(\text{all arrive}) = (1-p)^N \]With \(p = 0.01\) and \(N = 2000\):\[ 0.99^{2000} = e^{2000 \ln 0.99} \approx e^{-20.1} \approx 2 \times 10^{-9} \]
- With resending. A packet goes through on the first try with chance \(1-p\), on the second with chance \(p(1-p)\), on the \(k\)-th with chance \(p^{k-1}(1-p)\). The average number of tries is\[ \sum_{k=1}^{\infty} k\,p^{k-1}(1-p) = \frac{1}{1-p} \]
- The cost. With \(p = 0.01\), each packet takes \(1/0.99 \approx 1.0101\) sends on average. For 2,000 packets that is about 2,020 sends: about 20 extra packets to make the photo perfect.
- The catch. Every resend arrives late, by at least one round trip. For a photo, late is fine. For a voice, late is a problem.
So waiting for lost packets makes every download perfect. Then why doesn't a video call wait too?
Wait or skip?
In a video call, each packet carries a sliver of sound or a piece of a picture meant for right now. A resent packet shows up late, and by then the moment has passed.
Your goal: watch both lanes on Some loss, then press Bad Wi-Fi. The dashed ring is where the ball is live; the solid ball is what each app shows.
The waiting lane shows every frame, but runs behind live and never catches up. The skipping lane stays live, so the ball freezes and jumps. In a conversation, a delay hurts more than a freeze: once the delay passes a fraction of a second, people start talking over each other. Phone engineers aim to keep the one-way delay under about 0.15 seconds.
So most video calls, voice calls and online games skip lost packets, using a lighter set of rules called UDP that never resends. Downloads, web pages and messages wait, using TCP.
| Doing | Lost packet | Why |
|---|---|---|
| Download, web page, email | Wait | Every bit must be exact |
| Streaming a show | Wait | Loads seconds ahead, so resends arrive in time |
| Video or voice call | Skip | Late is as bad as lost |
| Online game | Skip | Only the newest position matters |
One choice, wait or skip, explains a lot of the internet around you. Where else does that choice show up?
Where you meet it
- The spinning circle on a video. The app has played everything it loaded ahead and is waiting for packets.
- Wi-Fi versus a cable. Wi-Fi shares the air with your neighbors' Wi-Fi, microwaves and walls, so Wi-Fi loses more pieces than a cable does, and Wi-Fi's own quiet resends add delay. For calls and games, a cable usually means fewer freezes.
- Lag in a game. The game skips lost updates, so another player seems to jump from one spot to the next.
- A cut cable, and the internet keeps going. Routers trade news, and traffic flows around the break, as in your first toy. Your messages might just take a little longer.
Where to go next
You can now explain how a message crosses the internet. The message travels as numbered packets. Routers pass each packet toward its address, using what their neighbors told them. Lost packets get sent again when exact matters, and skipped when late is worse than missing.
Those answers open new questions:
- How does my phone turn nerd-notes.com into an IP address? Look up: DNS.
- Packets pass through strangers' routers, so who can read my messages? Look up: HTTPS and encryption.
- Why is Wi-Fi slower and patchier than a cable? Look up: Wi-Fi interference, 2.4 GHz versus 5 GHz.
- How does a video app decide to go blurry instead of freezing? Look up: adaptive bitrate streaming.
- How do my packets cross an ocean? Look up: undersea internet cables.
Prefer to watch? Code.org's short video tells the same story with Vint Cerf, who designed the internet's TCP/IP rules with Bob Kahn.
Ask Phy
- Walk me through everything that happens, step by step, between typing nerd-notes.com and seeing the page.
- Why does TCP slow down when a packet is lost? Show me with numbers.
- How does HTTPS keep my packets private when they cross routers I don't trust?