Why WebRTC Prioritizes UDP Over TCP for Media

WebRTC (Web Real-Time Communication) is designed to enable sub-second, real-time audio and video streaming directly between browsers. To achieve the ultra-low latency required for live conversation, WebRTC inherently favors User Datagram Protocol (UDP) over Transmission Control Protocol (TCP) for media transport. This article explains the technical reasons why UDP is the ideal choice for real-time media and why TCP’s design is fundamentally incompatible with live streaming.

The Need for Speed: Latency vs. Reliability

In real-time communication, latency is the single most critical factor. For a natural conversation, end-to-end latency must remain below 200 milliseconds.

TCP is designed for absolute reliability. It guarantees that every packet of data arrives in the exact order it was sent. If a packet is lost during transit, TCP pauses the entire data stream and waits for the missing packet to be retransmitted—a phenomenon known as head-of-line blocking. For web browsing or file downloads, this delay is acceptable. For a live video call, however, waiting even half a second for a retransmitted packet causes the video to freeze and audio to drop, ruining the real-time experience.

Why UDP Fits Real-Time Media

UDP operates on a “fire-and-forget” model. It sends packets to the destination without establishing a formal connection, waiting for acknowledgments, or retransmitting lost packets. This connectionless nature makes UDP significantly faster and more lightweight than TCP.

• No Retransmission Delays: If a packet is lost in a UDP stream, WebRTC simply skips it. A temporary drop in audio or video quality is barely noticeable to a human user, whereas a freeze caused by TCP retransmission is highly disruptive. In WebRTC, old data is useless data.
• No Head-of-Line Blocking: Because UDP does not enforce packet ordering at the transport layer, a delayed or lost packet does not stop subsequent packets from being processed immediately.
• Lower Overhead: UDP headers are much smaller than TCP headers (8 bytes versus 20 bytes), reducing the bandwidth overhead for every packet sent.

Intelligent Application-Layer Control

By choosing UDP, WebRTC shifts the responsibility of managing network conditions from the operating system’s network stack (where TCP operates) to the application layer. WebRTC implements sophisticated algorithms to handle network issues without sacrificing latency:

• Real-time Transport Control Protocol (RTCP): WebRTC uses RTCP to monitor network statistics, such as jitter, packet loss, and round-trip time.
• Bandwidth Estimation and Congestion Control: Instead of TCP’s aggressive throttling, WebRTC uses algorithms like Google Congestion Control (GCC) to dynamically adjust video resolution and bitrate based on real-time network conditions.
• Packet Loss Concealment (PLC): WebRTC codecs (such as Opus for audio) can reconstruct missing audio packets using predictive algorithms, ensuring smooth audio even on lossy networks.

The TCP Fallback: ICE and TURN

While UDP is the prioritized transport protocol, WebRTC requires a fallback mechanism to ensure connections can still be made behind restrictive corporate firewalls or NATs that block UDP traffic.

WebRTC utilizes the Interactive Connectivity Establishment (ICE) framework to find the best connection path. If a direct UDP connection is impossible, WebRTC will attempt to route the media through a TURN (Traversal Using Relays around NAT) server using UDP. If that also fails, WebRTC will fall back to TCP, or TLS-encrypted TCP, as a last resort. While this fallback introduces higher latency, it ensures that a connection can always be established regardless of network restrictions.