UDP and Real-Time Protocols

While TCP offers reliability, it comes at the cost of latency and complexity. User Datagram Protocol (UDP) represents the 'fire-and-forget' philosophy of the transport layer. For senior engineers, understanding UDP is less about knowing it's 'unreliable' and more about knowing when timeliness allows for lossiness, or when you need to build your own reliability layer (like QUIC).

1. The UDP Header: Radical Simplicity

The UDP header is only 8 bytes, compared to TCP's minimum of 20 bytes. This reduced overhead is critical for high-bandwidth, small-packet flows (like gaming or voice).

• Source Port (16 bits): Optional in requests.
• Destination Port (16 bits): Routing target.
• Length (16 bits): Length of header + data.
• Checksum (16 bits): Error detection (mandatory in IPv6).

2. The 'Connectionless' Paradigm

UDP maintains no state on the server. There is no Three-Way Handshake, no Fin-Wait, and no retransmission buffer. This makes UDP servers highly scalable regarding memory usage, but pushes complexity (ordering, reliability) to the application layer.

3. Modern Use Cases & QUIC

Historically, UDP was for DNS and Video. Today, it powers the web via QUIC (HTTP/3). TCP suffers from Head-of-Line (HoL) Blocking: if packet 1 is lost, packet 2 waits, even if they are unrelated. QUIC uses UDP to implement independent streams; packet loss in one stream doesn't block others.

4. RTP and RTCP

For streaming media, raw UDP isn't enough; you need timestamps for synchronization. RTP (Real-time Transport Protocol) defines a standard packet format for delivering audio and video over IP. RTCP (Real-time Control Protocol) runs alongside it to provide feedback on Quality of Service (QoS), such as jitter and packet loss statistics, allowing the sender to adjust bitrate dynamically.