Load a web page and every byte of it has to arrive, in the right order, or the page breaks. Miss a packet of a video call and the call doesn't break — the picture stutters, maybe freezes on a face for a fraction of a second, and then carries on. Those two situations get their reliability from two different transport protocols making opposite bets about what to do when something goes wrong, and almost everything about how the modern internet feels — reliable here, glitchy there, never both at once for the same app — comes down to which of the two an application chose.
Two protocols, two different promises
TCP promises delivery: every packet you send arrives at the other end, in the order you sent it, or the connection tells you something failed. It does this with acknowledgments and retransmission — the receiver confirms each packet it gets, and if the sender doesn't hear that confirmation in time, it sends the packet again. If a packet goes missing, TCP won't hand any of the packets that arrived after it to the application until the missing one is filled in, because handing over out-of-order data would break whatever's depending on it arriving in sequence. That guarantee is exactly right for a web page, an email, a file download — data where a missing byte in the middle corrupts everything downstream of it, and it's worth a pause to get it right.
UDP promises almost nothing. It sends packets and moves on — no acknowledgment, no retransmission, no guaranteed order, and no notification if one never arrives. A packet that's lost is simply gone, and the application finds out only by noticing something's missing, if it notices at all. That sounds like a worse protocol until you ask what a video call actually wants from a dropped packet: not "wait and retry," but "skip it and keep going," because a video frame from half a second ago, retransmitted and delivered late, is worse than useless once several fresher frames have already arrived behind it. Real-time voice and video is built on UDP specifically because TCP's core promise — never show me anything out of order, ever — is the wrong promise for a stream where "late" and "wrong" mean the same thing.
What "built on UDP" actually looks like in practice
A dropped packet in a call surfaces as a glitch — a blocky frame, a half-second of garbled audio, a brief freeze — rather than a stalled connection, because nothing downstream is waiting for that specific packet to arrive before showing you the next one. The stream just keeps playing with a gap in it. That's the trade video-calling protocols are explicitly built to make: accept visible, audible imperfection in exchange for never freezing the whole call waiting on one lost piece of a conversation that's already moved on.
What we're still unsure about
"UDP just drops things and TCP just delivers them" is the textbook contrast, and production video systems don't actually run on plain UDP with nothing added — they layer their own error correction, selective retransmission for the packets that matter most, and adaptive bitrate on top of UDP's bare unreliability, building back some of TCP's guarantees exactly where the application needs them and skipping the rest where it doesn't. The clean two-protocol story in this post is the right mental model for why the two behave differently. It understates how much custom engineering sits on top of UDP before it becomes an actual video call.
This sits inside Transport Layer (TCP vs. UDP), one of seven topics in Networking, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.