Networking and Protocols

UDP

Connectionless transport that sends independent datagrams with minimal overhead.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

UDP (User Datagram Protocol) is a transport protocol that delivers discrete messages called datagrams. Unlike TCP, it does not create a connection or maintain a stream. The unit you send is the unit the receiver gets, assuming it arrives at all.

Key points
  • Each UDP packet is a message. If it is lost, UDP does not retry.
  • Used when low latency matters or when higher layers handle reliability.
  • Often paired with protocols like DNS, VoIP, streaming, and QUIC.

How it works in broad strokes

  1. An application creates a datagram and chooses a destination IP address and port.
  2. UDP adds a small header with source port, destination port, length, and checksum.
  3. IP routes the packet like any other IP packet. Routers do not keep per flow state for UDP by default.
  4. The receiver's OS uses the destination port to deliver the datagram to the right socket.
  5. If the packet is lost or arrives out of order, UDP does nothing. Any recovery is the application's job.
  6. Many networks use NAT, so the first outbound packet often creates a temporary mapping that allows replies back in.

Concrete example

A DNS resolver sends a small UDP query to port 53. If the reply is lost, the resolver simply retries the query, often to a different server, instead of relying on UDP to repair the loss.

Why it matters

Sometimes reliability is not the priority. Real time audio, video, and games prefer timely data over perfect data, and many protocols already have their own retry and ordering rules. UDP exists to provide ports and basic integrity checking without the weight of a full connection.

Security angle

  • UDP is easy to spoof, which enables reflection and amplification attacks when protocols reply with larger responses than the request.
  • Because there is no handshake, servers must be careful about allocating state or doing heavy crypto based on a single packet.
  • Use authentication at a higher layer when identity matters, for example DTLS or application level signatures.

Common pitfalls

  • Assuming UDP is always faster. Loss and retransmission at the application layer can make it slower overall.
  • Sending large datagrams. Fragmentation increases loss impact and is often blocked.
  • Forgetting that UDP still needs congestion awareness. High rate UDP can congest links and harm everything.
  • NAT and firewall timeouts can silently break long lived UDP flows.
  • Misdiagnosing packet loss as a server bug when it is really path loss.

DEEP DIVE

▾

What a UDP send really does

When an application sends with UDP, it hands the operating system one message and a destination: IP address and port. UDP wraps that message in a small header and gives it to IP. There is no handshake, no connection state, and no promise that the message arrives. If it arrives, it arrives as a whole datagram, so message boundaries are preserved unlike TCP's byte stream.

Because there is no built in recovery, UDP can be lower latency. There is no waiting for acknowledgements before sending more, and there is no head of line blocking caused by a lost packet. That is why real time media, gaming, and modern transports like QUIC often choose UDP as a substrate.

UDP still has ports, which are how a host demultiplexes incoming datagrams to the right application. It also has a checksum, which helps detect corruption. In practice, the checksum is not a reliability feature, it is a safety net that lets a receiver discard bad data instead of passing it upward.

Typical flow: request, response, done

A common UDP pattern is a single request and a single response. DNS is the classic example. The client sends a query to port 53 and waits briefly. If the response arrives, great. If not, the client retransmits, possibly to another resolver. The application handles the retry logic because UDP itself will not.

Because retries happen at the application layer, you often see unique identifiers inside the payload. The identifier lets the client match a response to the correct request and ignore duplicates. This is one reason beginners sometimes think UDP is unordered. In reality, ordering is simply not provided, so the application must decide whether ordering matters at all.

NAT and firewall behavior also shapes real usage. Outbound UDP usually creates temporary state in a NAT device. If the application goes quiet for too long, that state can expire and inbound responses will be dropped. That is why many UDP based protocols include keepalives even if the application itself is idle.

Size, fragmentation, and why small packets win

A UDP datagram can be large on paper, but the network path has a maximum transmission unit. If a datagram does not fit, IP fragmentation may occur, and losing one fragment loses the whole datagram. Many networks and middleboxes handle fragments poorly, so large UDP payloads are more fragile than they look.

Practical UDP protocols keep payloads small enough to fit in a single IP packet on common paths. If they need to move more data, they send multiple datagrams and add their own sequencing and reassembly rules. This is essentially rebuilding some of what TCP does, but tailored to the application's needs.

If you ever see a protocol switch from UDP to TCP for large responses, it is usually a sign that fragmentation was considered too risky. DNS does this, and other protocols make similar choices depending on deployment realities.

Building reliability on top of UDP

If an application needs reliability, it can add acknowledgements and retransmissions. The usual trick is to acknowledge specific message numbers, resend after a timeout, and tolerate duplicates. This can be simpler than TCP if the application does not need a continuous stream and can treat each message independently.

If an application needs congestion control, it can implement rate limiting and backoff based on observed loss and delay. QUIC is a major example: it uses UDP packets, but it implements streams, acknowledgements, encryption, and congestion control in user space, which allows faster evolution than kernel based TCP in many environments.

The key is choosing what you actually need. Many UDP protocols accept some loss because it is less harmful than delay. A voice call prefers to drop an old packet rather than wait for a retransmission, while a file transfer wants all bytes and can afford delay.