- UDP does as little as a transport protocol can do. Aside from the multiplexing and demultiplexing function and some light error checking, it adds nothing to IP (the network protocol).
- UDP takes messages from the application process, attaches source and destination pot number fields for the multiplexing/demultiplexing service, adds two other small fields, and passes the resulting segment to the network layer.
- The network layer encapsulates the transport-layer segment into an IP datagram and makes a best-effort attempt to deliver the segment to the receiving host.
- If the segments arrives at the receiving host, UDP uses the destination port number to deliver the segment’s data to the correct application process.
- With UDP there’s no handshaking between sending and receiving transport-layer entities before sending a segment, which is why UDP is said to be connectionless.
Example: DNS
- DNS is an application-layer protocol that typically uses UDP.
- When your computer needs to turn a website name (e.g. google.com) into an IP address, the DNS application sends a request message using UDP asking for Google’s IP address.
- UDP takes the message, gives it a header with the destination port number (port 53, the standard port for DNS servers), and immediately passes it down to the network layer to be sent across the internet.
- As UDP is fast, it gets the answer back in milliseconds without the extra overhead of establishing a full TCP connection first.
Why build an application over UDP rather than TCP, which provides a reliable data transfer? There are a few reasons:
- Finer control over what data is sent and when
- UDP immediately sends data to the network layer as soon as it’s packaged into a segment.
- TCP prioritises reliability over speed, so will often implement congestion control (intentionally slowing down the transmission rate to avoid crashing the network) and will continue trying to send data until it has been received, regardless of how long that takes.
- This is bad in live video calls or multiplayer games where you need a continuous stream of fresh data, you’re not too worried if a single video frame or microsecond of audio is lost, and delay is terrible (e.g. conversation lag).
- By using UDP, real-time apps get a fast, “no-frills” delivery line. If developers need a tiny bit of reliability (like making sure a player’s button press gets through), they can program that specific check directly into their own app code rather than using TCP’s heavy, slow rules.