Conceptly
โ† All Concepts
๐Ÿš€

UDP

ProtocolConnectionless transport that favors low latency over retransmission

UDP (User Datagram Protocol) is a transport-layer protocol that sends packets immediately without establishing a connection first. It minimizes ordering, retransmission, and flow-control overhead, so it's commonly used when a little loss matters less than keeping latency low.

โ–ถArchitecture Diagram

๐Ÿ”„ Process

Dashed line animations indicate the flow direction of data or requests

Why do you need it?

In voice calls or game input streams, getting a packet late can be worse than losing it. If every transmission has to wait for connection setup, ACKs, and retransmission, latency piles up until audio and gameplay fall out of sync. There needs to be a transport mode that accepts a bit of loss in exchange for speed.

Why did this approach emerge?

Early internet workloads centered on reliable file transfer and remote access, so TCP dominated. As voice, video, and interactive systems grew, it became clear that late packets could be less useful than missing ones. UDP became the lightweight transport foundation for those real-time patterns, with application-level recovery added only where needed.

How does it work inside?

UDP sends datagrams immediately without building a connection first. The receiver does not have to acknowledge each packet, and the transport layer does not automatically retransmit lost data. That keeps headers and state small, reducing latency, but it means the application has to deal with loss and reordering on its own.

What is it often confused with?

TCP and UDP are both transport-layer protocols, but they optimize for different outcomes. TCP raises accuracy through connection setup, retransmission, and ordering guarantees, while UDP lowers latency by skipping most of that machinery. If all data must arrive intact, TCP fits better; if timeliness matters more than perfection, UDP fits better.

When should you use it?

UDP fits real-time voice/video, game state updates, and short request-response exchanges such as DNS. It does not fit workloads where ordering and completeness are essential, such as file transfer or payment processing. If recovery is still needed, the application has to add it explicitly above UDP.

Real-time voice and video -- when avoiding delay matters more than perfect deliveryOnline game state updates -- continuously sending position and input with low latencyDNS queries -- exchanging short requests and responses quicklyMonitoring and telemetry -- collecting events where freshness matters more than completeness