UDP is faster than TCP because it doesn’t guarantee delivery, which sounds like a bug, but it’s actually its most powerful feature for certain applications.
Let’s see UDP in action. Imagine a live video stream. The server is sending out packets of video data.
Server (sending UDP):
Packet 1 (timestamp 100ms, frame A) -> Client
Packet 2 (timestamp 120ms, frame B) -> Client
Packet 3 (timestamp 140ms, frame C) -> Client (lost in transit)
Packet 4 (timestamp 160ms, frame D) -> Client
The client receives packets 1, 2, and 4. Packet 3 is gone. If this were TCP, the client would wait for packet 3, causing a noticeable pause or stutter in the video. With UDP, the client just plays frames A, B, and D. It missed frame C, but the show goes on, albeit with a tiny visual glitch. The slight imperfection is a price worth paying for real-time responsiveness.
This is the core difference: TCP is like sending a registered letter. You get confirmation it arrived, and if it doesn’t, you resend. It’s reliable but slower. UDP is like shouting a message across a crowded room. Some people might not hear you, but if you’re loud enough and fast enough, most will, and the message gets across quickly.
TCP (Transmission Control Protocol) is designed for reliability. When you send data over TCP, it establishes a connection, breaks your data into segments, numbers them, and sends them. The receiver acknowledges each segment. If an acknowledgment isn’t received, the sender retransmits. It also handles flow control (making sure the sender doesn’t overwhelm the receiver) and congestion control (slowing down when the network is busy). This makes it ideal for things like web browsing (HTTP/HTTPS), email (SMTP), and file transfer (FTP), where losing even a tiny bit of data would corrupt the entire file or page.
UDP (User Datagram Protocol) is the opposite. It’s a "fire and forget" protocol. It just sends datagrams (packets) to the destination without establishing a connection or waiting for acknowledgments. There’s no guarantee the packets will arrive, arrive in order, or arrive without duplication. This lack of overhead makes it incredibly fast. It’s perfect for applications where speed is paramount and occasional data loss is acceptable, such as live streaming, online gaming, and DNS lookups.
Consider DNS. When your computer looks up the IP address for google.com, it sends a UDP request. If the UDP packet gets lost, your computer simply sends another one. The whole process takes milliseconds. If DNS used TCP, it would involve a connection handshake, data transfer, and teardown for every single lookup, which would be noticeably slower and overkill for such a small amount of data.
The "connection" in TCP isn’t a physical cable; it’s a logical state maintained by both the sender and receiver. This state includes sequence numbers, acknowledgment numbers, window sizes, and timers. The initial handshake, often called the "three-way handshake" (SYN, SYN-ACK, ACK), establishes this state and agrees on initial sequence numbers. The teardown also involves a handshake to ensure all data has been sent and acknowledged.
UDP, by contrast, has no such state. It’s connectionless. A UDP packet contains a source port, a destination port, a length, and the data. That’s it. The operating system’s network stack on the sender side just hands the datagram to the network interface card, and it’s off. The receiver’s network stack, if it receives the datagram, checks the destination port and delivers it to the application listening on that port.
When you’re configuring network applications or troubleshooting, understanding which protocol is in use is crucial. For instance, a game server might use UDP for player positions to ensure real-time updates, but use TCP for critical game state synchronization or chat messages where reliability is essential. Many protocols actually use both. For example, QUIC, the protocol behind HTTP/3, runs over UDP but implements its own reliability, ordering, and congestion control mechanisms on top, aiming to get the best of both worlds.
The most surprising thing about UDP’s unreliability is how often it’s deliberately chosen because it’s unreliable. Developers will build custom error correction or retransmission logic into their application layer when they need specific guarantees that TCP doesn’t provide, or when they need finer control over latency. This is common in high-frequency trading systems, where even a single lost packet can be catastrophic, but the specific recovery mechanism needs to be tailored to the financial transaction’s criticality.
The next logical step is understanding how protocols like QUIC leverage UDP to build faster, more reliable communication layers.