A situation
You are on a video call, and a few packets are lost on your Wi-Fi link. The picture blurs for a moment, then carries on. Nothing freezes, and nobody waits. That is UDP doing its job. If the call used TCP, it would stop and wait for the lost data to be sent again, and by then that moment of the call would already be over.
What it is
UDP (User Datagram Protocol) is the simpler of the two main transport protocols. It is connectionless: there is no handshake, no connection state and no closing exchange. Each message, called a datagram, is sent on its own. UDP does not number datagrams, confirm them or resend them. This is called best-effort delivery.
| Field | Job |
|---|---|
| Source port | The sending application; replies are sent back to this port |
| Destination port | The receiving application, for example 53 for DNS |
| Length | Size of the header plus data, in bytes; at least 8 |
| Checksum | Detects damaged datagrams; optional in IPv4, required in IPv6 |
So UDP keeps only one job of the transport layer: port numbers, so that the data reaches the right application. Everything else is left to the application, if it needs it at all.
- 1. Every 20 ms phone A sends a small UDP datagram containing a slice of sound.
- 2. One is lost on the WAN. UDP does not notice that it is missing, and nothing asks for it again.
- 3. The next one plays. Phone B hides the 20 ms gap and keeps playing. A late resend would be worse than a tiny gap.
Why applications choose UDP
| Application | Why UDP suits it |
|---|---|
| Voice and video calls | Late data is useless; skipping is better than waiting |
| Online games | Only the newest position matters |
| DNS | One small question, one small answer; the client simply asks again if it is lost |
| DHCP | The client has no IP address yet and must send broadcasts |
| NTP, SNMP, syslog | Small, regular messages; one lost message does little harm |
| Streaming to many receivers | Multicast needs UDP, because TCP cannot hold a handshake with every receiver |
Some applications want reliability but not TCP's exact rules, so they build their own on top of UDP. QUIC, used by HTTP/3 on UDP port 443, is the best-known example: it provides its own encryption, retransmission and ordering.
Why it works this way
Less work means less delay. There is no handshake, so the first datagram already carries real data. There is no waiting for ACKs, and no stall when one datagram is lost. The small header also saves bandwidth: a voice packet may carry only 20 to 160 bytes of sound, so saving 12 bytes on every packet adds up. The cost is that the application must deal with loss, duplicates and out-of-order data itself.
How to verify it
show ip traffic includes UDP counters for traffic sent to and from the router itself. The output below is based on Cisco documentation, not captured from a lab device, and shows only the UDP part.
R1#show ip traffic | section UDP UDP statistics: Rcvd: 4093 total, 0 checksum errors, 312 no port, 0 finput Sent: 2240 total, 0 forwarded broadcasts
Check yourself
You compare a DNS query in a packet capture with a TCP segment. How big is the UDP header in the DNS query?
A UDP datagram carrying part of a voice call is lost on a WAN link. What does UDP do?
You are writing a firewall rule that allows only UDP traffic to a web server. Which of these services would still work?