UDP: fire and forget, on purpose

UDP is what you get when you take IP and add just enough to reach a program instead of a machine: two port numbers and a checksum. No connection, no ordering, no retry. That sounds like a worse TCP. It is not. It is the right tool whenever a late answer is worth less than no answer, or when you want to build the guarantees yourself. Most of the internet's timing-sensitive traffic, and the newest version of HTTP, run on it.

The map

Read this first when short on time. Every branch is a section below.

A datagram: one message, one packet, no promises

A UDP datagram is a single message. You hand the kernel some bytes and an address, and the kernel puts them in one IP packet and sends it. That is all. The other side either gets the whole message in one read, or gets nothing.

The header is eight bytes:

Compare that with TCP's 20-byte header full of sequence numbers, ACK numbers, flags and a window. UDP has none of them because it does none of those things.

The one thing UDP gives you that TCP does not is the boundary. If you send three datagrams of 100 bytes, the receiver does three reads of 100 bytes. TCP would give it 300 bytes in whatever chunks the network felt like, and the TCP article explains why you then have to frame messages yourself. UDP frames them for you, because each one is a packet.

The theoretical maximum is 65,507 bytes of data. In practice anything above about 1,400 bytes gets split into IP fragments, which is a trap described below, so real protocols keep datagrams small.

Datagram

One self-contained message in one packet. Delivered whole or not at all.

Port

A 16-bit number identifying a program on a machine. UDP and TCP have separate port spaces.

Why anyone chooses no guarantees

UDP is chosen for three reasons, and they are all versions of the same idea: TCP's guarantees have a cost, and sometimes the cost is worse than the problem it solves.

A late packet can be worthless. In a voice call, a packet holds 20 ms of audio. If it is lost and TCP retransmits it, it arrives 200 ms later, after the packets behind it have already been played. Worse, TCP would hold those later packets back until the lost one arrived, so the whole call stutters. UDP just drops the 20 ms, the codec papers over the gap, and the call continues. The same goes for a game's position updates and a video call's frames: the newest data matters, the old data does not.

The handshake is a whole round trip. DNS needs one question and one answer. On TCP that is a handshake, a request, a reply and a close: three round trips of packets for one question. On UDP it is two packets. When a page load starts with a DNS lookup, that round trip is on the critical path, as the packet journey shows.

You want to build something TCP is not. TCP is one ordered stream with the kernel's congestion control. If you want many independent streams so one loss does not stall the others, or a handshake that also does encryption, or a connection that survives a change of IP address, you cannot get there by tuning TCP. You can get there by building on UDP, in user space, and shipping the result in your app. That is exactly what QUIC is.

And there is a fourth: UDP can talk to many machines at once. A broadcast reaches everything on the local network, which is how a laptop with no address finds a DHCP server. Multicast sends one packet that the network copies to every subscriber. TCP, being a conversation between two ends, cannot do either.

sequenceDiagram
  autonumber
  participant C as Caller
  participant R as Listener
  C->>R: audio 0 to 20 ms
  C->>R: audio 20 to 40 ms
  C-xR: audio 40 to 60 ms (lost)
  C->>R: audio 60 to 80 ms
  Note over R: plays 0 to 40, hides the gap, plays 60 to 80
  C->>R: audio 80 to 100 ms

Broadcast

A packet addressed to every machine on the local network.

Multicast

A packet addressed to a group; the network copies it to every member that subscribed.

What the sender has to do itself

Everything TCP would have done for you is now your problem, and the first surprise is that "nothing" is not always an acceptable answer.

Reliability, if you need it. A protocol that must not lose data adds sequence numbers to its datagrams, has the receiver acknowledge them, and resends what is missing. That is TCP's job done again, but you get to choose which messages matter. A game retries the "you picked up the key" message and never retries a position update. RTP numbers every packet so the receiver can notice a gap and decide whether to care.

Congestion control, always. This one is not optional. TCP slows down when the network drops packets; UDP does not, so a program that sends as fast as it can will keep sending into a link that is already overflowing, and its packets and everyone else's will be dropped. A UDP sender on the open internet has to watch its own loss and back off. Real-time protocols do this by lowering the bitrate; QUIC reimplements TCP's algorithms. A UDP flood is how you get yourself blocked by an ISP.

The API. A UDP socket is socket(AF_INET, SOCK_DGRAM). There is no listen and no accept. A server just binds a port and calls recvfrom, which returns one datagram and the address it came from. It replies with sendto to that address. One socket serves every client, because there is no connection to keep per client.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 9999))

while True:
    data, addr = sock.recvfrom(2048)     # one datagram, whole, or truncated if bigger than 2048
    sock.sendto(b"pong " + data, addr)   # reply to whoever sent it, no connection needed

Two details bite. Each recvfrom returns exactly one datagram; if your buffer is smaller than the datagram, the rest is silently discarded, not saved for the next read. And a client can call connect on a UDP socket, which does not send anything on the wire; it just fixes the peer address so plain send and recv work, and lets the kernel report ICMP errors for that peer, such as "port unreachable".

Congestion control

Slowing down when the network drops packets. TCP does it in the kernel; a UDP protocol must do it itself.

recvfrom / sendto

The UDP calls: receive one datagram with its sender's address, send one datagram to an address.

The MTU trap: keep datagrams small

A datagram bigger than the path can carry does not fail. It gets cut into IP fragments, and that is worse than failing.

flowchart TD
  A["send 4,000 bytes in one datagram"] --> B["IP splits it into 3 fragments of about 1,480 bytes"]
  B --> C{"All three arrive?"}
  C -- yes --> D["Receiver reassembles, delivers 4,000 bytes"]
  C -- no --> E["Receiver waits, gives up after 30 s, delivers nothing"]
  E --> F["3 packets of bandwidth spent, 0 bytes delivered"]

An Ethernet frame holds 1,500 bytes. Take away 20 for IP and 8 for UDP and a datagram of 1,472 bytes fits in one packet. Anything larger is split into fragments by the sending kernel, or by a router on the way if some link is narrower. Fragments are reassembled only at the destination. If any one of them is lost, the whole datagram is lost. Many firewalls drop fragments outright because they cannot see the port numbers in the second and later pieces. And some paths, VPNs and tunnels especially, have an MTU well below 1,500, so a 1,472-byte datagram that was fine on your desk fragments in the field.

The rule every serious UDP protocol follows: keep datagrams at or below about 1,200 bytes, which fits through nearly every path on the internet without fragmentation, and use several datagrams for anything bigger. QUIC requires the path to carry 1,200 bytes and refuses to run otherwise. DNS historically capped answers at 512 bytes and switched to TCP for anything larger; modern resolvers advertise 1,232 as their limit for the same reason.

Fragmentation

IP splitting one datagram into several packets because it exceeds a link's MTU. Reassembled only at the destination.

MTU

Maximum transmission unit: the largest packet a link carries. 1,500 on Ethernet, less through tunnels.

NAT and firewalls: no connection, but still a state

UDP has no connection, but every NAT and firewall on the path pretends it does, because that is the only way they can let replies back in. Understanding that fake state explains most "UDP works here but not there" problems.

When your first datagram leaves the home router, the router creates a mapping, exactly as it does for TCP in the packet journey: your private address and port become its public address and a chosen port. A reply to that public port is translated back. The difference is how the router decides the "connection" is over. TCP has FIN; UDP has nothing, so the router uses a timer, typically 30 seconds to a couple of minutes of silence, and then forgets the mapping. The next reply is dropped, and the far end thinks you vanished.

So every long-lived UDP protocol sends keepalives, small packets every 15 to 25 seconds, just to keep the mapping alive. WireGuard has a setting for it. Video calls do it automatically.

The same mapping makes peer-to-peer connections possible. If two laptops behind two home routers both send a datagram to each other's public address and port at the same time, each router sees an outgoing packet, creates a mapping, and then lets the other's packet in. This is hole punching. To do it they first need to learn their own public address and port, which a STUN server tells them by simply reporting where the packet came from. When it fails, because a router picks a new port for every destination, the call goes through a relay instead.

sequenceDiagram
  autonumber
  participant A as Laptop A
  participant NA as NAT A
  participant NB as NAT B
  participant B as Laptop B
  A->>NA: datagram to B's public address
  Note over NA: mapping created, packet forwarded
  B->>NB: datagram to A's public address
  Note over NB: mapping created, packet forwarded
  NA->>NB: A's packet arrives, NAT B now has a mapping, lets it in
  NB->>NA: B's packet arrives, NAT A has a mapping, lets it in
  Note over A,B: direct path open, keepalives every 20 s

Finally, some networks block UDP altogether: hotel Wi-Fi, some corporate networks, some mobile carriers. Every UDP-based application needs a plan for that day, which usually means falling back to TCP. Browsers try HTTP/3 and quietly use HTTP/2 over TCP if the UDP packets do not come back.

NAT mapping

The router's note that public port X belongs to private address and port Y. Created on the first outgoing packet, expired after idle time.

Keepalive

A small packet sent regularly to stop a NAT mapping from expiring.

STUN

A server that tells a client what public address and port its packets appear to come from.

Hole punching

Two machines behind NATs sending to each other at once so both routers open a mapping.

Where UDP lives

Most of the internet's plumbing runs on UDP. These are the ports and protocols worth recognising on sight.

The pattern in the table: UDP wins when the message is small and self-contained, when timing matters more than completeness, when one machine talks to many, or when the protocol on top wants to own its transport. TCP wins when you want a stream of bytes delivered correctly and do not want to think about it.

The dangers: amplification and floods

Two properties of UDP make it the internet's favourite attack tool: the source address is not verified, and there is no handshake to prove the sender is who it says.

With TCP, an attacker who fakes a source address never completes the handshake, so no data flows. With UDP, a single spoofed datagram gets a full reply, sent to the faked address. If the reply is bigger than the question, the attacker has an amplifier: a 60-byte DNS query with a spoofed source can produce a 4,000-byte answer aimed at the victim. Thousands of open resolvers and NTP servers answering thousands of such queries per second is how the largest denial-of-service attacks of the 2010s were built. The defences are on the server side: rate limit responses, refuse to answer strangers, and keep replies small until the client proves it can receive them.

The other danger is simpler. UDP has no backpressure. A sender can emit datagrams faster than the receiver's socket buffer drains, and the kernel silently drops the overflow; netstat -su shows the count under receive errors. A burst from a fast producer to a slow consumer loses data with no error on either side.

Amplification attack

Sending small spoofed requests to servers that send large replies to the victim's address.

Spoofing

Sending a packet with a false source address. Possible with UDP because nothing checks it.

Recap