Skip to main content
Chapter 3 of High Performance Browser Networking · Read the chapter
UDP: User Datagram Protocol Datagram is an independent packet containing enough information to travel from source to destination. With UDP, delivery is not guaranteed, and failures are not reported.

​
Null Protocol Services

UDP usually be called Null Protocol Service because it’s almost just add source port and destination port on the IP to transfer the datagrams
  • IP just only try to transfer the datagrams, but not guarantees it will come to the destination.
  • UDP adds the header very small (8 bytes), include the source port, destination port, length of packet, and checksum.
  • UDP not guarantee:
    • The package is sucessfully delivered.
    • The packages will be in order.
    • Retry when package lost.
    • Control the connection’s status.
    • Congrestion control.
  • Each UDP datagram is a independent message, has clear boundary. When TCP transfer the data in order and retry when the package is lost.
Because it’s simply and stateless. UDP is suitable for bootstrapping other application protocols on top.

​
UDP and Network Address Translators

Assume device A wants to make a video call to device B using UDP.

​
UDP communication without NAT

Both A and B have public IP addresses:
A knows B’s address, so it sends UDP packets directly to 2.2.2.2:6000. B can send packets back to A in the same way. This works because both devices have addresses that are directly reachable over the Internet.

​
UDP communication behind NAT

Now A and B are on separate home networks:
Private addresses such as 192.168.x.x are valid only inside their local networks. A cannot send packets directly to B’s private address. When A sends a UDP packet to the Internet, NAT A creates a mapping:
However, A does not know that the Internet sees it as 1.1.1.1:40000. B has the same problem. If A sends a packet to an arbitrary port on NAT B, NAT B normally drops it because the port may not have a valid mapping, NAT B does not know which internal device should receive it, or B has not sent anything outbound to create a return path.

​
Reserved Private Network Ranges

IPv4 addresses are only 32 bits long, so there are at most about 4.29 billion unique addresses. This is not enough to give every Internet-connected device its own public address. NAT allows many devices to share one public IP address. Devices behind NAT commonly use one of these private address ranges: These addresses can be reused by different private networks, but they cannot be assigned to public hosts on the Internet.

​
Connection-State Timeouts

NAT must remember each UDP mapping so that replies reach the correct internal device. Because UDP has no handshake or connection-closing signal, NAT cannot know when a flow has ended. Instead, NAT removes inactive UDP mappings after a timeout. Long-running UDP sessions therefore send periodic bidirectional keepalive packets to preserve their mappings. Some NAT devices apply similar timeouts to TCP connections as well.

​
NAT Traversal with STUN

A public STUN server is available:
A sends a UDP request through NAT A to STUN. NAT A rewrites the source address, so STUN sees the packet as coming from 1.1.1.1:40000 and reports that address back to A. B does the same and discovers 2.2.2.2:45000. A and B exchange these addresses through a separate signaling server, then try to send UDP packets directly to each other:
STUN only discovers the public addresses and helps create NAT mappings. Once the connection succeeds, the video data travels directly between A and B, not through STUN. A restrictive NAT or firewall can still prevent this direct connection.

​
TURN when direct communication fails

When a direct connection fails, both devices establish outbound connections to a public TURN server:
TURN relays all traffic between the devices. This approach is reliable because both NATs allow replies from a server that their internal device contacted first. However, it adds latency, consumes server bandwidth, and costs more to operate.

​
ICE chooses the best path

The application does not know whether a direct connection will work, so ICE collects possible connection paths called ICE candidates:
A and B exchange their candidates through the signaling server. ICE tests the possible pairs and generally prefers:
  1. A direct connection on the same network.
  2. A direct connection using addresses discovered through STUN.
  3. A relayed connection through TURN.
ICE is not a separate server. It is the process running on both devices that gathers, tests, and selects the best available path. In short:
  • UDP sends packets without establishing a connection.
  • NAT lets multiple devices share one public IP, but hides private addresses and blocks unexpected inbound packets.
  • STUN helps a device discover its public IP and port so peers can try connecting directly.
  • TURN relays data when a direct connection cannot be established.
  • ICE tests and selects the best path: direct, STUN-assisted, or TURN-relayed.

​
Optimizing for UDP

UDP is simple and flexible, but it does not manage connections, resend lost data, put packets in order, or control network traffic. Applications using UDP must handle these problems themselves. Poorly designed UDP applications can overload the network. According to RFC 5405, UDP applications should:
  • Work under different network conditions.
  • Control sending speed and avoid network overload.
  • Slow down when packets are lost.
  • Avoid sending packets larger than the network limit.
  • Handle lost, repeated, delayed, or out-of-order packets.
  • Use checksums to detect errors.
  • Use keepalive messages only when needed.
Building a transport protocol with UDP is difficult. When possible, use an existing library that already supports traffic control and NAT traversal.