UDP is becoming the baseline for modern protocols. It is not just fast but a good fit for specific cases when paired with the right protocols and application design. This article details where UDP fits better, where it falls short, and why it is used as the basis for modern protocols despite its limited built-in reliability.
What is UDP? Is it a replacement for TCP?
UDP is a fast, connectionless protocol operating at the transport layer. It follows the “fire-and-forget” strategy where the data is sent with the best effort, but no guarantee, and no way to verify its delivery and delivery in order.
While the speed of UDP makes it a good choice for some use cases (as discussed later), its lack of reliability makes TCP the preferred choice for others.
|
Factors |
TCP | UDP |
|---|---|---|
| Speed and reliability | TCP builds a connection before data transmission, waits for acknowledgment of received packets before sending the next ones, and retransmits lost packets. All these properties of TCP make it reliable, but also slow in speed. | The connectionless nature of UDP and the lack of built-in retransmission and reordering make it faster but less reliable than TCP. |
| Support for multicasting and broadcasting |
TCP is built fundamentally for point-to-point communication. Each established connection is between two endpoints; hence, it does not support multicasting/broadcasting. |
UDP does not enforce a one-to-one connection model. This allows UDP to support multicasting and broadcasting, where a single datagram sent to a multicast or broadcast IP address is delivered to multiple receivers simultaneously. |
| Packet reordering | TCP supports reordering and delivers the packets in the same order they were sent. | UDP does not guarantee the ordered delivery of packets. The application has to handle packet ordering by itself. |
| Flow and congestion control | TCP is responsible for confirmed delivery of data and has built-in flow and congestion control, which helps minimize the rate of packet loss. | UDP sends data blindly without caring for its delivery. It has no built-in flow or congestion control. |
Factoring in all the characteristics of UDP, it is not a direct replacement for TCP due to its shortcomings. But if combined with other technologies and application-level controls like order handling and flow control, it can become an alternative for workloads where TCP’s overhead costs more than the reliability it provides.
How UDP Gets Away with Being So Fast?
As stated previously, UDP is fast. But what actually makes it fast? This section covers the different factors that contribute to the speed of UDP.
- Connectionless delivery: Unlike TCP, UDP does not establish a connection to the end target. Packets are sent blindly to the target, with no means of knowing whether they reached successfully. Not having to wait for acknowledgments of received packets improves UDP's performance considerably.
- Low latency and minimal overhead: Not having to wait for the acknowledgments of received packets makes the sending of next ones immediate, which results in low latency. Unlike TCP headers, the UDP header is just 8 bytes, adding minimal overhead to the data and hence improving speed.
- No built-in retransmission or ordering: UDP doesn't retransmit lost packets or reorder arriving ones, which, as a result, increases UDP’s speed.
- Broadcast and multicast support: When transmitting data to multiple targets, UDP does not have to create a separate connection with each one of them. It just starts sending data without any prior connection, which results in increased speed.
Where You’re Probably Already Using UDP
There are cases where you are already using UDP without realizing it. Some of those cases are:
Live video and audio streaming
When on a live video/audio stream, speed is the priority over reliability. In TCP, loss of one packet will stall the whole stream, which is worse than a small glitch caused by that lost packet.
UDP just ignores the lost packet and moves on with the received ones, and hence, avoids the head-of-line (HOL) blocking experienced in the case of TCP. In TCP, having to send an acknowledgment for each received packet also adds significant overhead, which is completely excluded in UDP.
Voice calls and conferencing
Voice is even less tolerant of delay than the video as the conversation moves on. If there is a delay in the delivery of one packet, it is better to continue with the rest than to wait and hang the conversation in between.
UDP for speed, combined with Real-time Transport Protocol (RTP) for sequencing and timestamping packets, is usually the standard for voice and conferencing calls. Jitter buffers at the receiver side use the timestamps and sequence numbers to reconstruct the correct packet order. Packet Loss Concealment (PLC) is also implemented on the application level to conceal the effects of lost packets.
On extremely unstable and weak networks, UDP can become a liability if packet loss exceeds the threshold that application-level concealment can handle. As a result, the audio becomes fragmented and unintelligible.
DNS and service discovery
DNS queries are small, one-packet requests, usually around 512 bytes. Establishing a 3-way handshake TCP connection for such a small query consumes more time and bandwidth than the query itself.
UDP performs the same DNS query but reduces the overhead by manyfold due to its connectionless nature.
DNS also implements a fallback to TCP when a UDP response is too large for the negotiated payload size and is truncated. The server signals this by setting the Truncation (TC) bit in the response, which prompts the client to retry the query over TCP for the full response.
Online gaming and real-time state updates
Online games rely on real-time status updates of the players. If a packet containing a player position update is lost, the next arriving packet covers that loss with a newer update. Waiting for the lost packet is irrelevant in such a case.
UDP supports such situations by not being bogged down by the lost packet and moving on to the next one.
But UDP lacks in cases where the lost data is not redundant (For example, when processing in-game purchases), and the next arriving packet does not make up for the lost one. Such cases require guaranteed delivery, which is where UDP falls short.
IoT and sensor telemetry
The data sent by IoT devices like sensors is frequent and naturally redundant. A missed temperature reading from a sensor usually does not matter if the next one arrives in the next minute. IoT devices also run on limited hardware and battery power. The lightweight and minimal-overhead nature of UDP makes it a preferred choice for power conservation in IoT devices.
But if you are sending a critical, one-time instruction to the IoT device, there is no guarantee that the instruction will reach the device. If lost, it can cause potential consequences.
Market data and multicast delivery
Financial markets run on speed, pushing pricing updates to thousands of subscribers simultaneously. If an update needs to be delivered to 1000 subscribers, TCP would require 1000 individual connections with each one of them, creating an enormous overhead.
UDP multicast solves this problem by sending a single stream to a multicast group network, and then multicast-enabled routers forward it to the subscribers. This also supports scalability, as an increase in the subscriber list does not increase the exchange workload for the sender.
Specialized high-speed file transfer systems
File transfers need reliability, and TCP provides it, but the problem is that TCP's congestion control backs off aggressively when a packet loss is detected. On high-bandwidth, high-latency links like research networks, this behavior leaves enormous capacity unused.
Protocols built on UDP, like UDP-based Data Transfer Protocol (UDT), solve this problem by implementing their own congestion control mechanisms and reliability layer on top of UDP. Such protocols are designed to fill the pipe aggressively and back off only when loss is indicative of actual network stress.
Why do modern protocols prefer UDP?
The internet has been running on TCP, but its reliability-first approach is becoming a hurdle for modern speed requirements. Another reason is that UDP has little to no built-in behaviour and acts as a blank slate. Modern protocols use that to build their own transport behaviour. Multiplexed protocols also suffer from HOL when run over TCP.
QUIC and HTTP/3
Both HTTP/1.1 and HTTP/2 relies on TCP and suffer from HOL blocking at different levels. Quick UDP Internet Connection (QUIC), which is the base of HTTP/3, solves this problem by using UDP to multiplex the multiple streams of data independently. If a packet gets lost in one stream, it does not affect the others, increasing the resource loading speed significantly.
WebRTC and real-time media
WebRTC powers real-time communication in browsers and applications. It uses UDP instead of TCP due to HOL blocking experienced in TCP, and for low-latency communication.
To deal with some features missing in UDP, like packet reordering and congestion control, WebRTC implements a layered stack of technologies built on top of UDP. It uses RTP to detect gaps and handle packet reordering. For congestion control, WebRTC uses its own algorithms that continuously estimate available bandwidth and communicate with the encoder to adjust the quality accordingly.
VPN and tunneling protocols
Traditional VPNs like OpenVPN commonly default to UDP but also support TCP. TCP is used as a fallback on restrictive networks that block UDP. The problem appears when tunneling TCP inside TCP. In a TCP tunnel inside a TCP connection, both TCP layers try to manage congestion simultaneously, which leads to a death spiral of retransmissions.
UDP tunneling solves this problem by letting the inner TCP connection handle its own reliability without any interference from the outer UDP tunnel.
Modern VPN and tunneling protocols like Wireguard use UDP and handle encryption and authentication itself, which is layered on top of UDP.
How Is UDP Made Reliable?
UDP is not built for reliability, but it can be made reliable by implementing different technology stacks. The most significant example of this is QUIC, the protocol underlying HTTP/3, which is based on UDP but provides reliability. QUIC does this by implementing reliability mechanisms at the application layer instead of relying on the transport layer for it.
Handling Data Loss
QUIC refines and reimplements TCP's reliability mechanisms (acknowledgements, retransmission, and reordering buffers) directly over UDP while addressing TCP's known limitations in the process.
QUIC assigns each datagram a unique packet number. These packet numbers are used to detect any gaps or lost packets. The receiver acknowledges the packets it has received, and the sender uses any gaps in these acknowledgements to detect loss and retransmit only the missing packets.
The sender retransmits the missing data with a different and unique packet number. That different packet number is used to distinguish between the retransmission and the original delayed packet, solving the retransmission ambiguity problem of TCP.
QUIC also maintains a buffer for each stream for reordering the out-of-order packets. As these buffers are maintained independently for each stream, any gap in one stream does not stall another.
Some implementations of QUIC also support Forward Error Correction (FEC), a proactive approach built on top of QUIC, where retransmission latency is not tolerable. In FEC, instead of waiting for the lost packet to be reported and resent, the sender sends additional repair packets along with the original data. If there is a packet loss in the transmission, the receiver can reconstruct the lost packet using the repair packet.
Managing Flow
Sending data over UDP without any pacing can flood the network. To encounter this, QUIC implements its own congestion control mechanism on the application layer.
QUIC’s implementations commonly use CUBIC or Bottleneck Bandwidth and Round-trip propagation time (BBR) as a congestion control algorithm. CUBIC adjusts the sending rate based on packet loss, scaling aggressively when the network is healthy and backing off when loss is detected. While BBR continuously monitors the delivery rate and the Round-Trip Time (RTT) to estimate the available bandwidth, it then paces the sending rate according to that.
QUIC also implements flow control on two different levels. On the stream level, it limits the sending rate as much as the receiver has indicated it can buffer. On the connection level, it sets a limit on how much data can be sent across all streams combined.
Identity and Protection
QUIC handles session management using connection IDs embedded in each datagram. These connection IDs help indicate that a packet belongs to a particular ongoing stream. Connection IDs also help in maintaining connections when the client switches networks and the IP address changes.
QUIC integrates TLS 1.3 into the protocol, making encryption a core component of the connection. It not only encrypts data but also some of the headers, keeping connection metadata hidden from outside observers. However, a few header fields, like the destination connection ID and packet type flags, remain visible so that routers can correctly forward traffic.
Together, these mechanisms make QUIC over UDP a robust protocol. However, while QUIC and HTTP/3 are gaining traction across the web, HTTP/1.1 and HTTP/2 over TCP remain widely used. Additionally, if UDP is blocked on a network, clients fall back to TCP, ensuring the connection remains functional even on restrictive networks.
