TCP vs UDP: Choosing Your Transport
You'll learn to
- -Explain the difference between a connection-oriented and connectionless protocol
- -Know when to reach for UDP instead of the "default" TCP
HTTP rides on top of another layer that actually moves the bytes across the network: almost always TCP (Transmission Control Protocol). TCP is connection-oriented and reliable: before any data moves, the two sides perform a handshake, and TCP guarantees that data arrives in order and re-sends anything that gets lost. This reliability isn't free: it costs a round trip for the handshake and adds overhead for tracking acknowledgments.
UDP (User Datagram Protocol) is the opposite trade: no handshake, no guaranteed delivery, no guaranteed order. A UDP packet is fired off and the sender moves on; if it's lost, nobody automatically resends it. That sounds strictly worse until you consider workloads where a late packet is worse than a lost one: a live video call frame that arrives 2 seconds late is useless anyway, so why pay the cost of retransmitting it? DNS also uses UDP for its lookups, since a single small request/response pair doesn't need TCP's connection overhead.
- -TCP: web APIs, file transfer, anything where correctness matters more than raw speed.
- -UDP: live video/voice, multiplayer games, DNS lookups, metrics that can afford to drop a few points.
- -QUIC (which HTTP/3 is built on) is a newer protocol that gets UDP's speed with TCP-like reliability, and is worth knowing exists even if you won't configure it directly in this lab.
You won't need to pick TCP vs. UDP explicitly in the HLD Lab's canvas, but this trade-off resurfaces conceptually in the Real-Time Systems module when you choose between WebSockets, long polling, and server-sent events.
You're designing a live multiplayer game. TCP or UDP for position updates?
"TCP, because it's reliable and I don't want to lose data."
"UDP. A player position update from 200ms ago is worthless the moment a newer one exists, because TCP would insist on redelivering and re-ordering the stale packet first, adding lag for correctness nobody needs. I'd only reach for TCP-like reliability for things that truly can't be dropped, like a purchase confirmation."