UDP vs TCP: Why Sometimes It's Better to Lose Data
If you've spent any time reading about networking, you know that TCP (Transmission Control Protocol) is the gold standard for moving data across the internet. It guarantees delivery. It puts packets back in order. It automatically resends missing pieces. It is a very polite, very careful delivery service.
And then there is UDP (User Datagram Protocol).
If TCP is a certified mail courier who makes you sign for your package, UDP is a paperboy who throws the newspaper at your porch while riding past on a bicycle.
UDP does not guarantee delivery. It doesn't care if the packets arrive out of order. If a packet is dropped, UDP shrugs and says, "Oh well, not my problem." It has no handshakes, no acknowledgments, and no sequence numbers.
So why on earth does UDP exist? Why would anyone ever choose a protocol that explicitly allows data to be lost?
The Cost of Reliability
To understand the value of UDP, you have to understand the cost of TCP.
All of TCP's wonderful reliability features—the three-way handshake, the sequence numbering, the acknowledgment packets (ACKs), the retransmission timers—add overhead. They consume processing power, they take up bandwidth, and most importantly, they add latency.
Let's imagine you are downloading a web page using TCP. Your computer sends a request. The server sends back packets 1, 2, 3, and 4. But packet 3 gets lost somewhere along the way.
Your computer receives 1, 2, and 4. Because it is using TCP, it cannot show you the web page yet. It sends a message back to the server: "Hey, I didn't get packet 3. Please resend." The server resends packet 3. Finally, your computer has all the pieces, reassembles them, and displays the page.
This is exactly what you want for a web page, an email, or a bank transfer. You cannot have a banking app that says, "We successfully transferred $10,000, but we lost the packet containing who we sent it to. Oh well!" You need 100% accuracy.
When Missing Data Doesn't Matter
Now let's imagine a completely different scenario: a live Zoom call.
You are having a video conference. Your webcam is capturing 30 frames every second, chopping them into packets, and sending them across the internet.
Suddenly, packet 307 (which contains the top half of your nose from a single frame) gets lost in transit.
If Zoom used TCP, the receiving computer would stop playing the video. It would send a message back: "Wait, I didn't get packet 307! Resend it!" A few hundred milliseconds later, the replacement packet arrives. But it's too late. The conversation has already moved on. Playing that missing frame half a second late would completely ruin the real-time nature of the call. The video would freeze, jitter, and stutter.
For live video and audio, it is vastly better to simply drop the missing data and keep moving. If one frame out of 30 is missing half a nose, the human eye barely even registers the glitch.
This is where UDP shines. UDP says, "I am going to blast these packets at the destination as fast as humanly possible. If some get lost, keep going."
Common Uses for UDP
Because UDP is lightweight and lightning-fast, it is the protocol of choice for any application where speed is more important than perfect accuracy:
1. Online Gaming: In a fast-paced multiplayer game like Call of Duty or Fortnite, the server is constantly sending your computer updates about where the other players are. If an update packet gets dropped, there is no point in resending it. By the time the resent packet arrives, the player has already moved somewhere else. You just need the *newest* packet immediately.
2. Voice over IP (VoIP) and Live Streaming: Zoom, Skype, Twitch, and live sports broadcasts all rely heavily on UDP to minimize latency.
3. DNS Lookups: Remember DNS, the "phonebook" of the internet? When your computer asks a DNS server for an IP address, it uses UDP. Why? Because the request is tiny (usually a single packet). Doing a full TCP three-way handshake just to ask one quick question would triple the time it takes to load a website. If the UDP request gets lost, the browser just asks again.
4. DHCP: When your computer joins a network and asks for an IP address, it uses UDP.
Wait, So Developers Can Just Choose?
Yes! When software developers write a network application, they open something called a "socket." They explicitly tell the operating system, "I want to open a TCP socket," or "I want to open a UDP socket."
The choice dictates the entire architecture of the app. If you choose TCP, the operating system handles all the reliability for you. If you choose UDP, you get raw speed, but if your application actually *needs* some level of reliability, you have to write custom code to handle it yourself.
For example, many modern games use UDP for character movement (where speed is critical), but they write custom logic on top of UDP to guarantee the delivery of important events, like a player picking up an item or chat messages.
The Future: QUIC
For decades, the internet was neatly divided: TCP for reliable data, UDP for fast data.
But recently, the engineers at Google realized that TCP's overhead was slowing down the modern web. Every time you connect to a secure website, your browser does a TCP handshake, followed by a TLS (encryption) handshake. It takes multiple round-trips before a single byte of actual website data is sent.
Their solution? They built a brand new protocol called QUIC.
QUIC is fascinating because it is actually built *on top of UDP*. It takes the raw speed and zero-handshake nature of UDP and adds reliable delivery and encryption right into the protocol itself. It achieves the reliability of TCP without the massive latency penalty of setting up a connection.
QUIC is now an official standard (often referred to as HTTP/3), and a massive percentage of global web traffic (including YouTube and Google Search) now travels over UDP-based QUIC rather than TCP.
So, while TCP is still the king of reliability, the fast, messy, "throw it and hope" paperboy protocol is quietly taking over the modern web.