TCP vs UDP: Choosing Your Transport

HTTP says what to ask and how to answer. It does not say how the bytes physically get across a network that is shared, noisy and sometimes drops things on the floor. That job belongs to a transport protocol underneath it. Two matter in this course: TCP, which almost everything on the web uses, and UDP, which powers calls, games and DNS lookups. They make opposite promises, and choosing between them is really a question of what you can afford to lose.

Data does not cross the internet as one piece. It is chopped into small packets, and each packet is routed independently through whichever routers are available. Packets can arrive late, arrive out of order, arrive twice, or never arrive at all, usually because a router along the way was too busy and dropped them. Both TCP and UDP sit on top of this unreliable reality. They differ in what they do about it.

TCP is registered post with a signature on delivery. Before sending anything, you and the recipient agree that you are both ready. Every page is numbered. The recipient confirms what has arrived, and anything unconfirmed is sent again. At the end, the pages are put in order and handed over complete. You pay for that certainty in time: the initial agreement, the confirmations, and the resending.

UDP is posting a stack of postcards. You write the address and drop each one in the box. There is no agreement beforehand, no confirmation and no resending. Some arrive out of order and a few never arrive. What you get in return is speed and simplicity: nothing waits for anything.

• -The agreement before sending is the handshake.
• -The numbered pages are sequence numbers, so the receiver can restore the order.
• -The signature on delivery is the acknowledgement (ACK) the receiver sends back.
• -Sending a lost page again is retransmission.
• -A postcard is a UDP datagram: self-contained, sent once, with no promises.

• -Handshake: the client sends a SYN (can we talk?), the server replies SYN-ACK (yes, I am ready), and the client replies ACK (good). That is one full round trip before any real data moves. Over a link with a 100 ms round trip, you have already spent 100 ms.
• -Numbering: every chunk of data is numbered so the receiver can put things back in order.
• -Acknowledgement and resending: the receiver confirms what it got, and the sender resends anything that is not confirmed in time.
• -Flow and congestion control: TCP slows down when the network or the receiver is overwhelmed, so one sender cannot flood everyone else.

On top of this, HTTPS adds its own handshake. A first request to a new HTTPS server over TCP therefore needs about one round trip for TCP, one for TLS and one for the request itself before the first byte of the answer arrives. On a 100 ms link that is around 300 ms of pure waiting, which is why later chapters care so much about reusing connections and keeping servers close to users.

Here is the catch with perfect ordering. Say a server sends five packets, numbered 1 to 5, and packet 3 is lost. Packets 4 and 5 arrive fine, but TCP promises to hand data to the application in order, so it holds 4 and 5 back until packet 3 has been noticed missing, asked for again and has arrived. Everything behind the lost packet waits. This is called head-of-line blocking. For a file download it is harmless, since you only care about the finished file. For a live video call it is a disaster: by the time packet 3 is redelivered, the moment it belonged to has passed, and the frames behind it are late as well.

• -TCP: web pages and APIs, file transfers, email, database connections. Anything where a missing or reordered byte is a bug.
• -UDP: live video and voice calls, multiplayer game positions, metrics where losing one data point does not matter. The newest position update makes the old one worthless, so resending it is pointless.
• -DNS lookups use UDP: one small question and one small answer do not justify a handshake. If no answer arrives, the client just asks again.

A middle path now exists. QUIC, the protocol under HTTP/3, is built on UDP but adds its own reliability and encryption, and it keeps separate streams independent, so a lost packet only delays the one stream it belongs to instead of everything on the connection. It gets most of TCP's guarantees without head-of-line blocking across the whole connection. You will not pick it by hand in this course, but it is the direction the web is moving.