What is UDP?
So, What Is UDP?
UDP (User Datagram Protocol) is a connectionless transport layer protocol that sends data between two devices without establishing a session first. Defined in RFC 768 back in 1980, it carries an 8-byte header, the smallest of any widely used transport protocol. UDP does not confirm delivery, retransmit lost packets, or reorder anything that arrives out of sequence. That is the whole point. Stripping out those guarantees is what makes it fast.
Key Takeaways
- UDP is connectionless. No handshake happens before data starts moving.
- The UDP header is 8 bytes, compared to 20 to 60 bytes for TCP.
- Lost or corrupted packets are discarded, never retransmitted.
- DNS, DHCP, VoIP, live video, gaming, and QUIC all run on UDP.
- Choose UDP when late data is worse than missing data.
How UDP Works
A UDP transmission has no setup phase. The sending device wraps its data in a datagram, stamps on a source port and a destination port, and hands it to the IP layer. Delivery is attempted once.
Compare that to TCP, which negotiates a three-way handshake before a single byte of real data crosses the wire. Two extra round trips of setup sounds trivial until you are streaming 50 audio frames per second across a congested link.
UDP treats every datagram as an independent unit with no memory of the ones before it.
When a corrupted datagram arrives, the receiving host checks the checksum, finds a mismatch, and drops it. Nothing is sent back. The application on top either fills the gap with its own logic or accepts the loss and moves on. A VoIP codec, for example, interpolates a missing 20-millisecond audio frame so quickly that most listeners never notice.
What Is Inside a UDP Header
Four fields, two bytes each. That is the entire header.
| Field | Size | Purpose |
|---|---|---|
| Source port | 2 bytes | Identifies the sending application. Optional in IPv4 and may be set to zero |
| Destination port | 2 bytes | Identifies which application on the receiving host should get the data |
| Length | 2 bytes | Total size of the header plus the payload, in bytes |
| Checksum | 2 bytes | Error detection across the header and data. Optional in IPv4, required in IPv6 |
The 16-bit length field caps a single datagram at 65,535 bytes. Subtract the 8-byte UDP header and the 20-byte IPv4 header and the practical payload ceiling lands at 65,507 bytes. Most real-world traffic stays far below that to avoid IP fragmentation, typically around 1,472 bytes on a standard 1,500-byte MTU network.
UDP vs TCP: The Practical Differences
Both protocols sit at the transport layer and both use port numbers. Everything after that diverges.
| Factor | UDP | TCP |
|---|---|---|
| Connection setup | None, connectionless | Three-way handshake required |
| Header size | 8 bytes | 20 to 60 bytes |
| Delivery guarantee | None | Guaranteed through acknowledgments |
| Packet ordering | Not preserved | Reassembled in the correct order |
| Retransmission | Never | Automatic for lost segments |
| Congestion control | None | Built in |
| Corrupted packets | Discarded silently | Detected and re-sent |
| Relative speed | Faster, lower overhead | Slower, higher overhead |
| Common uses | DNS, VoIP, gaming, live video, QUIC | Web pages, email, file transfer |
What this means: TCP guarantees your data arrives. UDP guarantees only that it left.
Neither is better in the abstract. A tax return upload that loses three packets is corrupt and useless. A video call that loses three packets drops a frame nobody remembers.
What UDP Is Actually Used For
Any workload where old data is worthless data.
| Application | Port | Why UDP |
|---|---|---|
| DNS lookups | 53 | Single query, single response, retry is cheaper than a handshake |
| DHCP | 67 and 68 | The client has no IP address yet, so no connection is possible |
| NTP time sync | 123 | Round trips must stay minimal for accurate clock offsets |
| SNMP monitoring | 161 | High-frequency polling across many devices |
| VoIP and video (RTP) | Varies | A late audio frame is useless, a dropped one is survivable |
| QUIC and HTTP/3 | 443 | Reliability rebuilt in userspace, without TCP head-of-line blocking |
| Online gaming | Varies | Position updates are superseded milliseconds later |
QUIC deserves a note. Google built it on top of UDP specifically to escape TCP’s constraints, then layered its own reliability and encryption above it. HTTP/3 now runs on that foundation, which puts a growing share of ordinary web traffic on UDP. The protocol is not fading into legacy status. It is carrying more of the modern internet every year.
The Limitations You Should Plan For
No delivery guarantee means the application layer inherits the problem. If your software needs certainty about what arrived, you either build that logic yourself or use TCP.
No congestion control is the bigger operational risk. TCP backs off when a network saturates. UDP keeps transmitting at the same rate regardless, so a poorly behaved UDP application can crowd out well-behaved TCP traffic on the same link.
Security teams have their own reservations. Because there is no handshake, source addresses are easy to spoof, which is why UDP-based services like DNS and NTP have been favorite vectors for reflection and amplification attacks. Rate limiting and source validation at the network edge matter more here than they do with TCP.
Why UDP Matters for Remote Desktops
Remote desktop performance is a latency problem before it is a bandwidth problem. Microsoft®’s Remote Desktop Protocol has supported a UDP transport since RDP 8.0, running alongside TCP on port 3389. Graphics and input updates travel over UDP, where a dropped frame gets replaced by the next one instead of stalling the session while TCP retransmits.
The difference shows up on lossy connections. Hotel Wi-Fi, mobile tethering, a home link shared with three other people on video calls. TCP-only sessions on those networks feel sticky because every lost packet blocks everything queued behind it.
We see this pattern constantly with distributed teams connecting to cloud desktops from unpredictable networks. Understanding which transport your session is negotiating explains a lot of otherwise mysterious lag, and it is worth checking before you assume you need more bandwidth.
Not sure whether your remote sessions are struggling with bandwidth or latency? Talk to one of our cloud experts.
UDP Frequently Asked Questions
Is UDP faster than TCP?
Yes, in most conditions. UDP skips connection setup, acknowledgments, and retransmission, so it has an 8-byte header against TCP’s 20 bytes or more and no round trips before data flows. The tradeoff is that some packets never arrive.
What is the UDP header size?
8 bytes, split into four 2-byte fields: source port, destination port, length, and checksum. TCP headers start at 20 bytes and grow with options.
Does UDP have error checking?
Partially. The checksum field detects corruption, but UDP only discards the bad datagram. It never requests a replacement. Error recovery is left to the application.
What port does UDP use?
UDP has no single port. It uses the same 0 to 65,535 range as TCP, with common assignments including 53 for DNS, 67 and 68 for DHCP, 123 for NTP, and 443 for QUIC.
Why does DNS use UDP instead of TCP?
A DNS query and its response usually fit in one small datagram each. Establishing a TCP connection would cost more time than simply repeating the query if it fails. DNS does fall back to TCP for large responses and zone transfers.
Is UDP secure?
UDP itself provides no encryption or authentication. Security comes from the layers around it, such as DTLS for datagram encryption or QUIC’s built-in TLS 1.3. Spoofed source addresses are a known weakness because no handshake verifies the sender.
Can UDP and TCP run on the same port number?
Yes. They are separate protocols with separate port spaces, so UDP 3389 and TCP 3389 are distinct endpoints and can serve different purposes on the same host.
