The User Datagram Protocol (UDP), first described in 1980 by RFC 768, offers a minimal set of functionality: there is no guarantee of message delivery, no guarantee of message order, no congestion avoidance, and no tracking of connection state. In fact, UDP is often referred to as the null protocol, because it offers little functionality not already included in the IP layer.
UDP Datagrams
UDP is structured as datagrams. The choice of the word datagram is deliberate, and meant to convey the unreliability of UDP-based traffic.
Datagrams provide a connectionless communication service across a packet-switched network. The delivery, arrival time, and order of arrival of datagrams need not be guaranteed by the network.
RFC 786 describes the basic UDP datagram: a source and destination port, length, and checksum. When IP delivers a UDP datagram, the host checks the port number and delivers the data to the corresponding application. In this way, UDP provides simple multiplexing over IP to allow a host to send and receive data on multiple distinct ports.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
Despite the simplicity of UDP, it is surprisingly difficult to use correctly in the wild due to the vagaries of Internet infrastructure.
Delivering UDP
UDP is a simple, stateless protocol. While this simplicity is great for minimal applications, it presents problems of reliability. In particular, it is difficult to deliver UDP packets through Network Address Translator (NAT) devices. To see why, let’s recap what NAT devices actually do.
As the Internet grew in popularity, it became impossible to allocate a unique IP address to every host. The NAT specification was introduced to address this problem by allowing a device on the edge of a network to advertise a globally unique public IP address for external hosts to connect to, and mapping that to internal IP addresses that are unique only to the internal network. This allows the same local IP address space to be reused among many different networks.
NAT devices work by maintaining a routing table for TCP-based connections by following TCPs connection (and teardown) protocol. When an application establishes a TCP connection, a new NAT routing entry is created, and when that TCP connection is torn down, the NAT routing entry can be deleted. Unfortunately, this process is not simple for UDP datagrams — UDP has no connection protocol and no state, making it difficult to maintain a correct routing table in NAT devices. To work correctly, any NAT device between two hosts must be manually configured to port forward UDP traffic to reach devices internal to the network, or follow one of three protocols have been developed to solve this problem: STUN, TURN, and ICE.
STUN — Session Traversal Utilities for NAT
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal.
STUN is one protocol for dealing with NAT devices that handle UDP traffic. STUN doesn’t handle NAT. Rather, it is a tool that NAT can use to determine the IP address and port allocated to an application. To use STUN, a client must connect to a STUN server that aids in discovering the client’s coordinates. The following figure, from RFC 5389 shows a sample deployment of STUN.
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
In this figure, the STUN client is behind two NAT devices that broker communication through private networks. The STUN server resides in the public Internet. To facilitate communication of UDP through NAT devices, STUN clients make a binding request to STUN servers. The binding request made to the STUN server traverses any NAT devices. The NAT devices will modify the source IP and port of the packet, and when the STUN server receives the request it will appear as though the request is from the NAT device. The STUN server returns the response to the client with a copy of the NAT device’s address. The STUN client receiving this response inspects this data to determine the coordinates that the NAT advertises for client requests. Now, the client application using STUN knows its public IP address and port and can use this data when sending requests to peers. Peers can respond to the correct IP address.
TURN — Traversal Using Relays around NAT
This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay.
TURN, like STUN, requires a publicly addressable server. Whereas a STUN server aids a client in discovering its IP and port, a TURN server acts as a bridge between any NAT devices and clients using UDP. In this configuration, clients communicate with the TURN server only. The following figure, from RFC 5766, shows a deployment of a TURN server and the IP address and port combinations advertised to peers at each stage of communication.
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
In this figure, the TURN client and the TURN server are separated by a NAT, with the client on the private side and the server on the public side. The client knows the address of the TURN server through DNS or configuration and sends traffic to the server, the TURN server is then responsible for routing the traffic to the peer on behalf of the client.
ICE — Interactive Connectivity Establishment
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
ICE is designed to establish communication sessions for UDP traffic using the best possible tunnel it can find: a direct connection if possible, STUN if there is a failure with direct connect, and TURN as a last resort.
The basic idea behind ICE is that a client may have a number of different IP addresses, depending on how it connects to the Internet: the address of the directly attached network device, an address assigned by a NAT device, or an address assigned by a TURN server. Each of these addresses has the potential to communicate with peers on the Internet, but it can be difficult to establish which of these addresses is the correct one to use and which won’t work. ICE is responsible for discovering which pair of addresses should be used for communicating between peers by systematically trying all possible communication pairs until it finds one that works.
Designing with UDP
Although the limited feature set of UDP seems appealing, the Internet still requires some form of congestion control to keep stable. Typically, this means that UDP-based protocols still must implement some form of congestion control, retry and backoff, and your protocol will need to work well with any NAT devices or other infrastructure that already exists on the Internet. In short, UDP is not a panacea that can improve performance as a drop-in replacement for TCP. If you choose to build your own protocol on top of UDP, you will have to implement at least some of the features missing from TCP RFC 5405 provides some more guidance on safely designing applications using UDP.
More References
This article provides an introduction to UDP, and should provided a good overview for someone wanting to learn more about the protocol. If you want to learn more, there are several great resources to choose from:
- RFC 768 — User Datagram Protocol
- RFC 1631 — The IP Network Address Translator (NAT)
- RFC 5245 — Interactive Connectivity Establishment (ICE)
- RFC 5389 — Session Traversal Utilities for NAT (STUN)
- RFC 5405 — Unicast UDP Usage Guidelines for Application Designers
- RFC 5766 — Traversal Using Relays around NAT (TURN)