UDP Applications

TCP and UDP in application design

Choosing TCP or UDP determines which delivery properties the application receives from the transport layer. TCP establishes a connection and provides an ordered, reliable byte stream with acknowledgments and retransmissions. File transfer, HTML delivery, and email depend on those properties because missing or reordered bytes would change the result.

The User Datagram Protocol (UDP) sends independent messages without establishing an end-to-end connection. It does not provide delivery, ordering, or duplicate protection, and its header adds little control information. Applications choose UDP when they can define their own loss handling and when an old message is less useful than a newer one.

These real-time applications assign a deadline to each piece of media or state. A video frame that misses its playback time, or an old player position, usually has little value. The receiver can conceal a loss, interpolate a sample, or skip an update and continue with newer data. An application using UDP on the Internet must also control its sending rate because UDP itself has no congestion-control mechanism.

IP can discard, duplicate, or reorder datagrams before they reach the destination. UDP exposes a received datagram to the socket selected by its destination port and reports the source address and source port to the application. The checksum can detect many transmission errors, but it does not tell the sender how to repair a missing message.

Application protocols also choose message sizes and pacing. A datagram larger than the path can carry may be fragmented or discarded, and a burst of UDP traffic can compete unfairly with other flows. A real deployment therefore combines deadline-aware loss handling with a message-size limit, retry rules where needed, and a rate that responds to congestion.

Real-time voice and video communication (VoIP, video conferencing)

Voice and video systems such as Skype, Zoom, Google Meet, and Discord often use RTP or WebRTC media paths over UDP. They can use other transports when network policy prevents UDP, so the choice depends on the media protocol and deployment.

TCP retransmission and interactive media

Interactive audio and video can tolerate a short loss more easily than a late repair. Speech codecs can conceal a missing sample, and video decoders can continue with a later frame. A reliable byte stream that waits for an earlier segment can delay data that was scheduled for playback.

TCP retransmits missing bytes and preserves their order. That behavior is useful for a complete file, but it can create head-of-line delay for an interactive media stream. The application still has to deliver each audio or video unit before its playback deadline, so a late repair can be discarded by the media layer.

How UDP supports real-time communication

UDP lets the media application choose how to trade loss, delay, and repair. A VoIP sender encodes speech into small units and places them in UDP datagrams, while the receiver decides how to handle units that arrive late or out of order.

• Lower protocol delay: UDP has no transport connection setup and does not retransmit a lost datagram. The path still determines propagation and queueing delay, but the transport does not wait for an earlier message before exposing a later one to the application.
• Application-layer control: The media stack handles loss with concealment, interpolation, selective repair, or a skipped unit. A lost voice datagram therefore need not stop the rest of the stream while a transport waits for retransmission.
• Handling Jitter: Real-time applications on UDP often implement a jitter buffer on the receiving end. The buffer delays playback by a configured amount so that packets arriving within that window can be released according to the media clock. Packets arriving after the deadline are usually concealed or discarded.

RTP (Real-time Transport Protocol) is commonly carried over UDP. Its payload type, sequence number, and timestamp let the receiver identify media, detect loss, and schedule playback. RTP does not itself guarantee delivery or quality of service.

Live media streaming

Live sports and interactive broadcasts, including a stream on Twitch, have a delay budget. RTP-based media paths can use UDP when the application accepts loss and handles timing itself. Browser delivery through HLS or DASH uses HTTP, which can run over TCP or over QUIC with HTTP/3.

Playback deadlines in live media

A frame that is already late cannot improve the current playback position. With a reliable byte stream, recovery of an earlier segment can delay later bytes and increase live latency. A media protocol that accepts loss can continue with a later frame instead.

A UDP media path can skip a lost frame and display the next decodable frame. The result may be a short visual gap or decoder artifact, while the playback clock stays closer to the live event. This behavior is a property of the media protocol and its loss-recovery policy, not a guarantee supplied by UDP.

On-demand video, such as standard YouTube or Netflix playback, has a different objective. The client can buffer segments and request them again, so services commonly use HTTP over TCP or HTTP/3 over QUIC. A few seconds of initial buffering can be preferable to a visible gap in the stored program.

Online gaming and state updates

Fast-paced online games, including first-person shooters and racing games, often send frequent state updates with UDP. Other games use TCP or a reliable transport when their protocol needs ordered delivery. In gaming, latency is often estimated with a round-trip time measurement called ping. It is one of several metrics that affect interaction, alongside loss, jitter, server processing, and the update rate.

Reliability choices for game state

A game server continually synchronizes the game state, including player positions, actions, and projectile trajectories. It sends a stream of small updates whose usefulness decreases as their state becomes old.

Suppose a competitive shooter loses an update that records a shot. With TCP, ordered delivery can delay later state until the missing bytes arrive. The event may then describe an outdated world position. A datagram protocol lets the game receive a newer state and apply its own rule for events that require confirmation.

The game can send frequent updates and apply the newest valid position it receives. If a one-time event needs delivery, the game can add sequence numbers, acknowledgments, and retransmission for that event while leaving routine state updates lossy. UDP supplies the datagrams; the application supplies these semantics and its congestion-control policy.

Other UDP-based protocols

UDP is also used by infrastructure protocols that exchange short messages or need to operate before a host has complete address configuration. Each protocol defines its own retry, integrity, and congestion behavior.

Application-layer reliability over UDP

UDP does not decide how an application handles loss. A protocol built above UDP can add sequence numbers, acknowledgments, retransmission timers, and congestion control when its messages need those properties.

An online game can confirm a one-time event while sending player positions as replaceable updates. This gives each message type its own delivery rule instead of applying one rule to the whole stream. The application still has to implement these mechanisms correctly and respect congestion-control requirements on the Internet.

QUICis an example of a transport protocol built on UDP. It provides reliable streams, loss recovery, flow control, congestion control, and a TLS-based handshake while retaining UDP's datagram interface to the network. HTTP/3 uses QUIC as its transport. For example, a game can retransmit chat messages while treating player positions as replaceable updates. The application can therefore select different delivery rules for media, control messages, and bulk data within one design.