# TCP, UDP, and lost packets

> Two ways to handle a network that loses things: resend everything, or keep moving.

Lesson 5 of 6 in [How the internet actually works](https://learnfold.app/learn/internet/), a free course from Learnfold.

The network makes your packets exactly one promise. It will try. Packets get dropped, delayed, and delivered out of order, and the routers in the middle don't fix any of it. That job falls to the two computers at the ends. They usually pick one of two approaches.

### TCP: everything, in order

TCP, the Transmission Control Protocol, turns a stream of unreliable packets into a reliable conversation. It starts with a handshake of three messages. Your phone says "I'd like to talk." The server says "Got it, I'd like to talk too." Your phone says "Got it." Along the way, both sides agree on the numbers they'll use to count what they send.

From then on, every piece of data is numbered, and the receiver keeps sending back acknowledgments that mean "I have everything up to here." When the sender sees the same acknowledgment again and again, or hears nothing for too long, it concludes a packet was lost and sends it again. That's what you watched in the packets lesson.

### Loss means slow down

TCP treats a lost packet as a sign that some router along the way is overloaded. So it backs off, sending less, then speeds up again gently. This is called congestion control. It's a quiet bit of cooperation. Millions of computers ease off whenever the network gets crowded, so it doesn't jam.

That cooperation was added after the fact. In the mid-1980s, parts of the early internet nearly ground to a halt, with useful traffic on some links falling to a tiny fraction of normal. Congestion control was the fix, and it's still at work in your phone today.

### UDP: send it and move on

UDP, the User Datagram Protocol, does almost nothing. It sends packets and never checks whether they arrived. For a file download that would be a disaster. For a video call it's exactly right. If a packet carrying a sliver of someone's voice goes missing, getting it back half a second later is useless, because the conversation has moved on. Better to skip it and accept a tiny glitch than freeze while waiting.

Online games use UDP for the same reason. DNS lookups often do too, since the question and the answer each fit in a single packet, and if either gets lost it's quicker to just ask again.



Play TCP to see setup and a resend after a timeout. Switch to UDP to see later datagrams arrive without transport-level repair.

| What happens | TCP | UDP |
|---|---|---|
| Lost packets | Sent again | Gone |
| Order | Always restored | Not guaranteed |
| Setup | Handshake first | None |
| Good for | Web pages, email, downloads | Calls, games |

### The twist

A large share of web traffic now travels over QUIC, a newer protocol that runs on top of UDP and adds its own acknowledgments and resending. Why rebuild what TCP already does? Speed, for one. QUIC folds the connection setup and the encryption setup into fewer round trips. And with TCP, one lost packet holds up everything behind it, while QUIC lets other files keep flowing. There's a practical reason too. TCP is built into operating systems and network equipment everywhere, so changing it takes years. QUIC lives in apps and browsers, which update all the time.

### Rabbit holes

> Why does a video call get blurry or choppy instead of freezing when my connection is bad?

> What went wrong in the congestion collapse of the 1980s, and how did the fix work?

> If TCP is everywhere, why is it so hard to change?

Read online: https://learnfold.app/learn/internet/tcp-udp/