QUIC vs TCP/UDP: Rethinking Transport for WebRTC Media

If you read our earlier post on what QUIC is and why it matters for real-time video, you already have the pitch: QUIC is a modern, UDP-based transport with encryption, multiplexed streams, and a fast handshake built in. This post goes one level deeper — three of QUIC's transport-layer properties in more technical detail, and an honest answer to the question that actually matters if you run a WebRTC-based media pipeline: what does any of this buy you today?

(Hero image: a real QUIC connection captured and visualized with qvis, Robin Marx's open-source QUIC/HTTP-3 debugging tool.)

Where QUIC actually sits

One of the easiest mistakes to make when approaching QUIC is to think of it as either a replacement for TCP or simply "UDP with extra features." In reality, it sits somewhere between the two.

TCP is responsible for reliable transport, flow control, congestion control, and loss recovery. TLS then sits on top of TCP to provide encryption, and the application only ever interacts with the resulting secure byte stream — two separate layers, negotiated separately, each with their own round trips. QUIC reorganizes these responsibilities into a single layer that runs directly on UDP: TLS 1.3 is built into the handshake itself instead of being layered on afterward, and reliability, flow control, and loss recovery become QUIC's job rather than TCP's.

Source: SEC Consult, "Better don't be too QUIC(K)".

That reorganization isn't just architectural tidiness; it's also where QUIC's fastest real-world win comes from. TCP+TLS needs two to three round trips before a client can send its first request; a QUIC client that has already talked to a server before can send data immediately, with zero round trips. When Google enabled QUIC on its HTTPS load balancers in 2018, that handshake saving alone was enough to measurably shorten Google Search's page-load time — 8% on average globally, and up to 13% in high-latency regions. That's a web-traffic benchmark, not a WebRTC one, but it's real evidence that the handshake savings QUIC promises aren't just theoretical.

Source: Google Cloud Blog, "Introducing QUIC support for HTTPS load balancing" (2018).

Multiplexing without head-of-line blocking

We covered this at a high level before: QUIC keeps independent streams inside a single connection, and a lost packet on one stream doesn't stall the others. For a WebRTC media pipeline specifically, this needs a caveat: head-of-line blocking was never really WebRTC's problem in the first place. RTP already runs over UDP, not TCP, so the media path itself never had TCP's head-of-line blocking to begin with.

Where it does bite is the fallback path: when a strict firewall blocks UDP outright, WebRTC falls back to relaying media through a TURN server over TCP (commonly on port 443, to blend in with ordinary HTTPS traffic). That fallback is exactly where TCP's head-of-line blocking shows up in a real deployment, and it's a genuine tradeoff, not a hypothetical one. QUIC doesn't solve this particular problem, though — QUIC is still UDP under the hood, so a network that blocks UDP blocks QUIC just as effectively as it blocks RTP. Multiplexing without head-of-line blocking is a real property, but it isn't a fix for the "our network only allows TCP" scenario that TURN-over-TCP exists for.

Congestion control: pluggable by design

RFC 9002 specifies a baseline congestion controller modeled on TCP NewReno, but QUIC's loss-detection signals are deliberately generic — an implementation is free to swap in something else entirely, and most real QUIC stacks do, typically CUBIC or BBR.

WebRTC already has its own answer to this problem: RTP's companion protocol, RTCP, carries the feedback (packet loss, jitter, round-trip time) that a sender-side congestion controller like Google Congestion Control uses to adjust bitrate in real time. So congestion control isn't a capability WebRTC media is missing today; it's more that QUIC folds transport and congestion control into a single layer, instead of RTCP feedback sitting on top of a "dumb" UDP socket. Whether that consolidation is worth it depends on whether you're building the congestion-control logic yourself or relying on an existing, already-tuned WebRTC stack — for most teams using OpenVidu, it's the latter, so this is one area where QUIC's advantage is more architectural than immediately practical.

Connection migration: the one WebRTC genuinely doesn't have

This is the property that matters most in practice. RFC 9000 defines connection migration around Connection IDs: a QUIC connection is identified by an ID negotiated at the handshake, not by the client's IP address and port. When those change — switching from Wi-Fi to mobile data, for instance — the client can keep using the same connection on the new network path. It validates that new path first (a PATH_CHALLENGE/PATH_RESPONSE exchange) before committing to it, and in the current version of QUIC, only the client can initiate a migration.

WebRTC's real-world equivalent is an ICE restart: the application has to detect the network change, generate new ICE candidates, and renegotiate through its own signaling channel — a round trip through your signaling server, not something the transport layer handles for you, and it briefly disrupts media while it happens. Connection migration is genuinely transport-native; an ICE restart is something every WebRTC application has to build and handle itself.

Conclusion

QUIC's significance isn't that it replaces TCP or makes UDP obsolete; in practice, it sits somewhere between the two. From TCP it inherits reliability, congestion control, flow control, and connection management. From UDP it inherits flexibility, low overhead, and freedom from a strictly ordered transport model.

For WebRTC engineers, that combination is what makes QUIC interesting — not because it's ready to replace RTP-based media transport, but because it represents a modern transport architecture designed around the realities of mobile networks, encrypted traffic, and latency-sensitive applications.