TCP and UDP: registered delivery versus no receipt required
Welcome back to our Packet Highway, commonly known as the Internet!
Life at the Quiet Network Estate is almost back under control. The DHCP office hands out licence plates. The NAT gatekeeper finally found his notebook, only to register it as lost property by mistake. The fridge still doesn't know where its milk is.
Meanwhile, two delivery companies have opened on the estate. Both promise to deliver information. Both own vehicles. Both use the same highway.
And that's pretty much where the similarities end.
Two companies, two worlds
The first is called TCP.
A sign on the door reads:
“Deliveries in the correct order. Missing items replaced. Receipts compulsory.”
At reception sits an elegant gentleman in a suit. He has a binder, a rubber stamp and a telephone that he uses to confirm he received the previous telephone call.
The second company is UDP.
Its sign says:
“Fast. Simple. No unnecessary questions.”
The reception desk is empty. A notice hangs on the wall:
“IF YOU CAN READ THIS NOTICE, THE COURIER HAS ALREADY LEFT.”
One customer decides to try both companies. He goes to TCP first.
— Hello. I'd like to send a message.
— Certainly. First we need to establish a connection.
— BUT WE'RE ALREADY TALKING!
— Socially, yes. Officially, no.
— THEN WHAT MUST I DO?!
— Please begin the greeting procedure.
— GOOD MORNING!
— Good morning. I acknowledge your greeting and send my own.
— I ACKNOWLEDGE YOUR GREETING!
— Excellent. Connection established.
— CAN I SEND THE PARCEL NOW?!
— Of course.
— FOR HEAVEN'S SAKE!
Meet TCP (Transmission Control Protocol), which provides a reliable, ordered stream of bytes between two endpoints.
The whole greeting ceremony is called the three-way handshake.
SYN, SYN-ACK and ACK, or saying hello three times
At TCP headquarters, every greeting has its own form.
— SYN: I'd like to start a conversation!
— SYN-ACK: I hear you, and I'm ready too!
— ACK: I acknowledge that you acknowledged my greeting!
— Can we begin?
— Now we can.
— COULDN'T WE HAVE DONE THAT IMMEDIATELY?!
— Then we wouldn't know whether the other side was ready.
— BUT THEY ANSWERED THE PHONE!
— Please don't confuse private conversations with official procedure.
TCP also uses sequence numbers, negotiates connection parameters and establishes connection state at both endpoints. It's not just politeness: both sides need to agree they're ready to exchange data.
UDP, the courier nobody can stop
Tired of the ceremonies, our customer visits the competition.
— Hello, I'd like to send a parcel to Kraków.
— ALREADY SENT!
— BUT I HAVEN'T GIVEN IT TO YOU YET!
— THEN GIVE ME THE NEXT ONE!
— WHAT ABOUT THE ADDRESS?!
— HAVE YOU GOT AN ADDRESS?!
— Yes!
— THEN HAND IT OVER!
— Delivery confirmation?
— WE DON'T DO THAT!
— WHAT IF THE PARCEL GETS LOST?!
— TOO BAD!
— WHAT IF IT ARRIVES AFTER THE NEXT ONE?!
— THEN IT ARRIVES LATER!
— WHAT IF IT NEVER ARRIVES?!
— THEN IT DOESN'T!
— ARE YOU INSANE?!
— NO, SIR. UDP! 🤣
UDP (User Datagram Protocol) is connectionless. It sends datagrams without first establishing a connection and doesn't itself provide acknowledgements, retransmission or ordered delivery.
But wait! UDP isn't a broken TCP. It is a company with a different job description. Not every job needs all that ceremony.
Parcel number three arrives before number two
TCP accepts a large document for delivery, divides the data into parts and sends them onto the highway.
The first part arrives. The second gets stuck in traffic. The third arrives early.
The receiver opens the door.
— Hello, parcel number three!
— Where's number two?
— Don't know.
— Then wait.
— BUT I'M ALREADY HERE!
— I can't pass the contents on in the correct order yet.
— THEN CALL THE SENDER!
— We're already signalling that through acknowledgements.
Back at headquarters:
— BOSS! THE RECEIVER GOT LATER DATA BUT AN EARLIER PART IS MISSING!
— CHECK THE ACKNOWLEDGEMENTS!
— IT KEEPS ACKNOWLEDGING THE EARLIER NUMBER!
— RETRANSMIT WHEN THE CONDITIONS CALL FOR IT!
— AND PARCEL THREE?!
— IT CAN WAIT IN THE BUFFER!
In TCP, sequence numbers describe byte positions in the data stream, not literally numbered courier parcels.
TCP detects missing data and retransmits what hasn't been acknowledged. A receiver can buffer out-of-order data while presenting an ordered stream to the application.
— SO PARCEL THREE IS HERE, BUT I MUST WAIT FOR NUMBER TWO?!
— Correct.
— CAN I AT LEAST LOOK INSIDE?!
— Not through the normal ordered stream passed to the application.
— I JUST WANTED A PANCAKE RECIPE!
— Please wait for the missing section about the eggs.
— BUT I ALREADY HAVE THE SECTION ABOUT THE FRYING PAN!
— Without eggs, the procedure requires further waiting.
UDP and live broadcasting
Meanwhile UDP is carrying a football match.
The commentator shouts:
— THE PLAYER PASSES THE BALL!
One datagram leaves.
— HE SHOOTS!
Another leaves.
— GOOOOOAL!
The third leaves. The first arrives. The third arrives. The second is lost in traffic.
The viewer hears:
— THE PLAYER PASSES THE BALL!
— GOOOOOAL!
— WHEN DID HE SHOOT?!
The UDP manager shrugs.
— Don't know. We haven't got that part.
— THEN SEND IT AGAIN!
— By the time it arrives, the match will have moved on.
— BUT I MISSED THE SHOT!
— Perhaps you'll catch the next one.
That's why many real-time applications prefer tolerating small losses to waiting for old data to be delivered again.
It doesn't mean every audio or video service uses UDP, or that applications can't build their own recovery mechanisms.
UDP lets applications decide what to do when something doesn't arrive.
— SO YOU'RE NOT IRRESPONSIBLE AFTER ALL?!
— I'm responsible for what I promised.
— WHICH WAS?!
— To send it.
— THAT'S ALL?!
— That's all.
Port numbers, or which office gets the parcel
On our highway an IP address identifies the destination building. But several offices may share it.
Inside are a web server, a mail server and some mysterious equipment nobody remembers installing.
The courier arrives.
— Hello, delivery!
— For whom?
— This address.
— That's the whole building.
— THEN TAKE IT!
— WHICH OFFICE?!
— DON'T KNOW!
— PORT NUMBER?!
— WHAT SORT OF PORT?!
— NETWORK PORT!
— THEN JUST SAY THE OFFICE HAS A NUMBER!
Some familiar service ports:
| Port | Common use |
|---|---|
| TCP 80 | HTTP |
| TCP 443 | HTTPS |
| TCP 22 | SSH |
| TCP 25 | SMTP |
| UDP 53 | DNS — some queries |
| UDP 123 | NTP |
Importantly, TCP and UDP have separate port-number spaces. TCP port 53 and UDP port 53 aren't one shared protocol counter.
— SO THERE CAN BE A TCP 53 AND UDP 53?!
— Yes.
— AND THEY WON'T ARGUE?!
— Not about the number.
— THEN WHY DID THE NAT CLERK HAVE SO MANY PROBLEMS?!
— Because somebody always arrives at his desk without the full paperwork.
In our NAT and masquerading story we met the gatekeeper who writes addresses and ports in his famous notebook. Now we know why he must also distinguish protocols.
The receive window, or how many parcels can be in flight
A new customer arrives at TCP.
— I've got ten thousand parcels.
— Very good.
— SEND THEM ALL!
— Not at once.
— WHY NOT?!
— The receiver needs room to accept them.
— HOW MUCH ROOM?!
— They've advertised their available capacity.
— THEN SEND THAT MUCH!
— That's what we're doing.
TCP uses a receive window for flow control. The receiver tells the sender how much additional data can fit into its buffer.
— WHAT IF THE RECEIVER'S WAREHOUSE IS FULL?!
— They report that there's no space.
— AND THEN?!
— We reduce sending.
— BUT I WANT TO SEND!
— Wait until there's somewhere to unload.
— ARE YOU A COURIER COMPANY OR A LEFT-LUGGAGE OFFICE?!
— Depends on the warehouse.
There's another limit, too. Even if the warehouse is enormous, the highway itself can be jammed.
The highway is jammed and TCP gets out a calculator
A junction manager calls TCP headquarters.
— Hello. We've got a traffic jam.
— How bad?
— Very.
— Are parcels getting lost?
— They're starting to.
The TCP manager frowns.
— Then we need to slow down.
— BUT WE'VE GOT A THOUSAND MORE PARCELS!
— All the more reason not to send them at once.
TCP includes congestion control.
The amount of data in flight is limited by mechanisms including the receiver's window and the sender's congestion control.
— SO THE RECEIVER TELLS YOU HOW MUCH IT CAN HOLD?
— Yes.
— AND THE HIGHWAY TELLS YOU HOW MUCH IT CAN CARRY?
— Not literally. The sender estimates conditions from network signals and connection behaviour.
— DO YOU HAVE AN ALGORITHM?!
— Certainly.
— WHICH ONE?!
— Depends on the implementation and configuration.
— “IT DEPENDS” AGAIN?!
— Welcome to computing.
Mechanisms such as CUBIC and BBR take different approaches to controlling the sending rate.
But we won't open a separate department of motorway mathematics today. The manager has suffered enough.
UDP can have rules too!
A customer comes to UDP with a complaint.
— I HEAR YOU SEND PARCELS WITHOUT CHECKING!
— Ordinary UDP doesn't guarantee delivery.
— SO YOU'RE USELESS!
— Not necessarily.
— WHAT IF I WANT DELIVERY CONTROL?!
— You can build it into your application.
— MYSELF?!
— Yes.
— THEN WHAT DO I NEED YOU FOR?!
— Simple datagram transport without TCP's compulsory connection setup and mechanisms.
— BUT I WANT FAST AND RELIABLE!
— Build the mechanisms you need on top of UDP.
— FOR EXAMPLE?!
— QUIC.
— WHAT'S THAT?!
— A transport protocol built over UDP that can provide reliability, encryption and independent streams.
— SO UDP CAN BE RELIABLE?!
— Not on its own. Protocols above it can.
— WHY DIDN'T YOU SAY SO BEFORE?!
— You didn't ask for the deluxe delivery package.
— THEN I WANT DELUXE!
— Application department, next building.
— WHERE?!
— NEXT BUILDING!
— OH, FOR GOODNESS' SAKE!
UDP should not be equated solely with unreliable live streaming. Many different technologies use it and implement whichever transport features they need.
Closing the connection: TCP won't leave without saying goodbye
After a long day the TCP customer finishes the conversation.
— Thank you, that's all.
— Understood. Would you like to finish sending?
— Yes.
— Then please send FIN.
— SEND WHAT?!
— A notice that you've finished sending.
— I JUST SAID I'M FINISHED!
— Please use the protocol.
— FIN!
— ACK. Received.
— CAN I LEAVE NOW?!
— The other side may still have data to send.
— BUT I DON'T WANT ANYTHING ELSE!
— Please wait for them to finish.
A moment later:
— FIN.
— ACK.
— AND NOW?!
— Now we can close the exchange.
— FINALLY!
— Remember the possible TIME_WAIT state.
— THE WHAT?!
— It helps prevent old segments from being confused with a new connection.
— BUT I'VE ALREADY SAID GOODBYE!
— Procedure is still in progress.
— I'LL GROW OLD HERE!
Each side of TCP can finish sending independently, so orderly shutdown commonly involves FIN and ACK in both directions.
There is also RST, a connection reset. A very different way to end a conversation.
— Hello, I just wanted to...
— RST!
SLAM!
— HELLO?!
— ...
— SO MUCH FOR TCP BEING POLITE! 🤣
And how does UDP finish?
— Thank you, that's everything!
Silence.
— Hello?!
Silence.
— MR COURIER?!
From somewhere far away:
— I'M ALREADY IN KRAKÓW!
— WHAT ABOUT GOODBYE?!
— NOT IN OUR PROCEDURES!
UDP has no built-in connection setup or shutdown like TCP. If an application needs greetings, goodbyes or session termination, it must implement them itself.
What do our delivery companies really do?
TCP and UDP operate over IP. IP addresses and forwards packets between networks, while TCP and UDP offer different ways for applications to communicate.
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection setup required | Connectionless |
| Acknowledgements | Yes | Not built into UDP |
| Retransmission | When needed | Not built into UDP |
| Data order | Ordered byte stream | No guaranteed order |
| Message boundaries | Byte stream | Preserves datagram boundaries |
| Flow control | Yes | Not built into UDP |
| Congestion control | Built in | Depends on higher-level application or protocol |
| Examples | SSH, SMTP, traditional HTTP/1.1 and HTTP/2 | DNS, NTP, many live applications, QUIC |
There's no single winner.
TCP is a good choice when an application requires a reliable, ordered stream of data.
UDP is useful for datagrams where the application decides what additional mechanisms it needs.
Real applications may use either approach.
And when parcels get stuck in traffic, revisit routing and our Packet Highway, where we've already met queues, delays and missing cars.
To explore more of our Packet Highway, take a look at IP addresses, DHCP, DNS.
Meanwhile at the Quiet Network Estate...
The fridge pulls up at the parcel collection point.
— Hello. I'm expecting milk.
The TCP courier checks the paperwork.
— Order number?
— 153.
— Shipment number?
— 154.
— Proof of dispatch?
— Haven't got it.
— Then I can't release it.
— BUT THE MILK IS ALREADY HERE!
— Yes, but an earlier acknowledgement is missing.
— THEN FIND IT!
— Retransmission has been initiated.
A UDP driver arrives from the other direction.
— MILK?!
— YES!
— HERE!
He throws a carton out the window and drives away.
The fridge opens it. It's kefir.
— HELLO?! THAT'S NOT MILK!
UDP shouts from the distance:
— DID THE PARCEL ARRIVE?!
— YES, BUT IT'S THE WRONG ONE!
— NOT MY LAYER!
The fridge looks at TCP.
— What are you doing?
— Waiting for acknowledgement.
— OF WHAT?!
— That you received the kefir.
— BUT THAT WAS UDP!
— Oh. My apologies.
A moment of silence.
— Could you at least deliver my milk?
— Of course.
— WHEN?!
— First we establish a connection.
— ...
— SYN?
— YOU CAN PUT THAT SYN IN YOUR FILING CABINET!!!
The DHCP clerk pokes his head out of the office.
— STOP SHOUTING! WE'RE TRYING TO HANG UP THE LAUNDRY!
The NAT gatekeeper happens to be passing.
— Who signed for it?
— NOBODY!
— I'll write that in my notebook.
— WILL YOU PLEASE CLOSE THAT NOTEBOOK!!! 🤣🤣
Next time we'll see why some cars drive around in circles until their junction allowance runs out. Meet TTL and the official whose only answer is “Limit exhausted. NEXT!”
TCP acknowledged receipt of the complaint. UDP probably did too. We didn't ask.