10 min read
Every time you watch a live stream, make a video call, or play an online game, your device sends and receives data at high speed. That data travels using User Datagram Protocol (UDP), a transport layer protocol designed for one thing: speed.
Unlike TCP, UDP does not check whether packets arrive or arrive in order. It sends data and moves on. That sounds like a flaw, but for real-time applications, it is exactly what you need. A dropped frame in a video call is far better than a two-second freeze while the connection waits for a retransmit.
So how does the User Datagram Protocol actually work, and why do engineers choose it over TCP for certain workloads?
What is User Datagram Protocol (UDP)?Link to heading
User Datagram Protocol (UDP) is a communication protocol built for speed. It powers time-sensitive tasks like video playback, DNS lookups, and live streaming by skipping the formal connection setup that other protocols require. That shortcut makes data transfer fast, but it also means packets can get lost in transit and opens the door to threats like DDoS attacks.
How does UDP work?Link to heading
UDP transfers data between two computers on a network by sending packets, called datagrams, directly to the target. It does not establish a connection first, does not number the packets, and does not verify whether they arrived. The process is lean by design: send the data and move on.
TCP vs. UDPLink to heading
UDP is faster than TCP, but it trades reliability for that speed. TCP starts every communication with a handshake, an automated back-and-forth between two computers that confirms both sides are ready before any data moves. UDP skips this step entirely. One computer simply starts sending data to the other without any prior agreement.
TCP also tracks packet order and confirms delivery. If a packet goes missing due to network congestion, TCP requests it again. UDP has none of this. No ordering, no confirmation, no retransmit.
That gap creates a clear advantage in performance. Because UDP does not wait for handshakes or delivery confirmations, it moves data significantly faster than TCP.
The tradeoff is reliability. A lost UDP datagram stays lost. Applications that run on UDP have to handle errors, missing packets, and duplicates on their own. Worth noting: packet loss is not really a UDP flaw. Most network routers do not track packet order or confirm delivery by design, because the memory overhead would be impractical. TCP fills that gap when an application needs it. User Datagram Protocol simply does not ask for it.
>>> Learn more: HTTP/3 vs HTTP/2: Which one should you use for your site?
What is UDP used for?Link to heading
UDP works best when speed matters more than perfection. Voice and video traffic are the clearest examples. Both are time-sensitive and built to absorb some data loss without breaking the experience. VoIP services, for instance, run on UDP because a slightly choppy call is far more acceptable than a perfectly clear one that lags two seconds behind.
Online gaming follows the same logic: a missed packet is better than a delayed one that freezes the match.
DNS servers also run on UDP. They need to respond fast, handle large volumes of small queries, and keep overhead low. UDP fits all three requirements without compromise.
How is UDP used in DDoS attacks?Link to heading
Packet loss and missing delivery confirmations are manageable in most UDP use cases. The bigger risk is how attackers exploit the protocol's connectionless design. Because UDP requires no handshake, an attacker can send traffic to a target server without the server ever agreeing to communicate. That makes User Datagram Protocol a reliable tool for volumetric attacks.
A UDP flood attack works by sending a high volume of datagrams to random ports on the target machine. The target has no way to ignore these without checking each one first. For every datagram that hits a closed port, the server generates an ICMP "port unreachable" response. At scale, this response cycle consumes CPU, memory, and bandwidth until the server can no longer process legitimate traffic. The result is a denial of service for real users.
Organizations have several options for defending against UDP flood attacks. Rate-limiting ICMP responses reduces the server's workload, though it can also block valid traffic as a side effect. A more effective approach routes incoming UDP traffic through a distributed network of data centers.
By spreading the load across multiple nodes, no single origin server takes the full force of the attack. This method absorbs the volume without sacrificing availability for legitimate requests.
Advantages of UDPLink to heading
Ultra-low latency for real-time applicationsLink to heading
User Datagram Protocol does not set up a connection before sending data. It skips the handshake, skips the acknowledgment, and sends packets straight to the destination. That process cuts the delay that TCP introduces at the start of every session.
For real-time applications, that difference matters. A video call cannot pause and wait for a missing frame to retransmit. A live stream cannot buffer every packet before playing. Online games need input data to arrive in milliseconds, not seconds. UDP makes all of this possible because it moves data without stopping to confirm each step.
Reduced bandwidth overheadLink to heading
Every TCP packet carries extra data: sequence numbers, acknowledgment flags, window size, and other fields that support reliable delivery. UDP headers contain only four fields: source port, destination port, length, and checksum. That is 8 bytes total, compared to a minimum of 20 bytes for TCP.
For applications that send thousands of small packets per second, that overhead gap adds up. DNS queries, for example, are short requests that need fast responses. Sending each one through TCP would waste bandwidth on setup and header data. UDP keeps those transfers lean and fast.
Broadcast and multicast supportLink to heading
TCP is a one-to-one protocol. Every connection links exactly two endpoints, which means sending the same data to multiple recipients requires multiple separate connections.
User Datagram Protocol supports broadcast and multicast natively. A single UDP packet can reach every device on a local network segment, or a defined group of receivers across the internet, in one transmission. This makes UDP the standard choice for protocols like DHCP, which needs to reach all devices on a network during address assignment, and for live video distribution where one source feeds thousands of viewers at the same time.
Simplicity and developer controlLink to heading
UDP is a thin protocol. It delivers packets and nothing else. That simplicity gives developers full control over how their application handles delivery, ordering, and error recovery.
A developer building a real-time game can choose to drop late packets entirely rather than process them out of order. A developer building a video codec can implement custom error correction tuned to that specific format. With TCP, those decisions are made by the protocol itself. With UDP, the application layer makes them, which means the logic can be optimized for the exact use case rather than a general one.
Disadvantages of UDPLink to heading
No guaranteed delivery or orderingLink to heading
User Datagram Protocol sends packets and does not follow up. There is no acknowledgment from the receiver, no confirmation that data arrived, and no mechanism to detect when a packet goes missing. If a datagram is lost in transit, the sender has no way to know.
TCP solves this by numbering every packet and requiring the receiver to confirm each one. UDP has no equivalent. For applications where every byte must arrive intact, such as file transfers, database queries, or web page loading, this makes UDP a poor fit. Those use cases require TCP's reliability guarantees.
Susceptibility to packet lossLink to heading
Network congestion, router drops, and transmission errors all cause packet loss. TCP handles this through retransmission: when a packet does not arrive, the sender sends it again. UDP does not retransmit. A lost packet is gone.
Applications built on UDP have to decide what to do in that situation. Some ignore the loss entirely. Others implement their own recovery logic at the application layer. Either way, the protocol itself provides no safety net. For applications where data integrity is critical, packet loss under User Datagram Protocol is a real operational risk.
No built-in congestion controlLink to heading
TCP monitors network conditions and adjusts its transmission rate when it detects congestion. If the network is overwhelmed, TCP slows down to reduce pressure on the path between sender and receiver. This keeps traffic flowing without collapsing the connection.
UDP sends at a constant rate regardless of network conditions. If the network is congested, UDP traffic contributes to that congestion rather than backing off. At high volumes, this behavior can overwhelm routers, drop packets across multiple flows, and degrade performance for other traffic on the same network. This is also why UDP is the protocol of choice in DDoS flood attacks: it generates volume without any built-in throttle.
ConclusionLink to heading
User Datagram Protocol is a deliberate tradeoff. It gives up delivery guarantees, packet ordering, and congestion control in exchange for raw speed and low overhead. That tradeoff is the right call for a wide range of applications: DNS lookups, VoIP calls, live video, online gaming, and any workload where a late packet is worse than a lost one.
The limitations are real. But for applications built around real-time performance, those limitations are acceptable costs.
>>> Is your WordPress website prepared for UDP flood attacks and other network-based threats? Activate W7SFW today to block malicious traffic before it reaches your server.