Lesson
UDP: Datagrams and Ports
Learning objective
Read UDP datagrams, trace port-based delivery, and diagnose replies, ICMP errors, and silence without assuming reliability.
Learning objective
Read UDP datagrams and ports, follow a packet to an application, and explain what a reply, ICMP error, or silence can and cannot prove.
Why UDP exists
IP gets a packet to a host. UDP adds source and destination ports so an application can send a distinct message, or datagram, to an application on another host. UDP does not first establish a TCP-style connection.
Ports and sockets
The destination port helps the receiving host find the right socket; the source port identifies where a reply may go. Clients often use temporary ephemeral source ports. A socket is an operating-system endpoint, not a physical plug. Protocol and the endpoint addresses/ports distinguish conversations.
UDP header and datagrams
Swipe sideways to see all fields
| Source port · 16 bits | Destination port · 16 bits | ||||||||||
| Length · 16 bits | Checksum · 16 bits | ||||||||||
| Application data · variable | |||||||||||
The UDP header carries source port, destination port, length, and checksum. It is compact because UDP does not carry TCP sequence numbers, ACKs, a receive window, or connection flags. Each datagram has a message boundary; receiving one datagram does not imply another arrived.
What UDP does and does not provide
UDP does not itself guarantee delivery, ordering, retransmission, or flow control. An application can build those behaviors above UDP if it needs them. A small header does not mean every UDP application is always faster than every TCP application.
Interactive UDP port delivery
Follow a datagram through header inspection and socket lookup. Compare a listening DNS service, two ephemeral clients, and a destination without a listener.
UDP Port Delivery
Step 1 of 4: Transport unit arrives
UDP carries source and destination ports inside the IP packet.
Transport tuple: UDP 192.0.2.10:49152 → 198.51.100.20:53
| Field | Value |
|---|---|
| Source port | 49152 |
| Destination port | 53 |
| Length | 40 bytes |
| Checksum | valid |
Socket lookup pending
DNS and DHCP examples
DNS commonly uses UDP port 53 for queries, though it can also use TCP. DHCP uses UDP ports 67 and 68 while a client obtains configuration. These are examples, not a rule that every application using UDP behaves the same way.
Errors and silence
A datagram to a closed UDP port may cause ICMP Port Unreachable. Filtering, application behavior, loss, routing, and return-path problems can instead leave the sender observing silence. Silence alone does not prove a port is closed.
Choosing UDP
Choose a transport based on the application's delivery contract. UDP is useful when independent messages and application-controlled timing or recovery matter. TCP's reliable ordered byte stream serves a different contract. Neither is automatically the faster or safer choice on every path.
Inspect UDP evidence
Use a udp capture filter, then narrow to the expected source and destination ports. Compare the UDP length and checksum, the application request, any response, and any related ICMP error. On Linux, inspect listening sockets with ss -ulpen; on Windows, use Get-NetUDPEndpoint or netstat -ano.
Basic Wireshark check
Display filter: udp || icmp
Capture one UDP request. Record the endpoint tuple, datagram length, matching application evidence, a response or ICMP message if present, and what remains unknown if there is silence.
Guided UDP diagnosis
An absent reply is only absence of observed reply evidence. Check whether the request reached the host, a matching socket existed, the application processed it, a response left, and the response had a return path.
Interview scenario
Show answer and reasoning
Troubleshoot UDP methodically
- Confirm the address, transport protocol, source port, and destination port.
- Check the receiving socket and application logs.
- Capture the request, response, and any ICMP error in both directions.
- Check firewall policy and forward and return routes.
- Compare with a known-good request before deciding what silence means.