Is QUIC the Transport Layer Real-Time Apps Have Been Waiting For?

If you've spent any time building real-time applications on the web, you've probably run into the same uncomfortable truth: the Internet stack wasn't really designed for those kinds of experiences.

We use it for video conferencing, live collaboration, cloud gaming, telemetry, market data feeds, remote desktops, and countless other latency-sensitive applications. Yet the protocols that carry most of this traffic were designed decades ago, for a world where reliability mattered more than immediacy.

TCP: reliable, but rigid

TCP has been one of the most successful protocols ever created and remains the foundation of a huge portion of Internet traffic. The issue for real-time is that TCP makes a very deliberate trade-off: every byte must be delivered reliably and in order. If a packet is lost, everything behind it must wait. For loading a web page, or other non-real-time contents, that's exactly what you want. For an interactive application where data becomes stale almost immediately, it can become a significant source of latency.

UDP: fast, but bare

This overzealous insistence on reliability is one of the reasons why the real-time media world gravitated toward UDP long ago. In a voice or video call, a packet that arrives half a second late is often worthless. The user would rather lose a frame or hear a brief audio glitch than wait for old information to arrive. UDP embraces this model by keeping the transport layer simple and avoiding retransmission requirements, allowing applications to prioritize timeliness over perfect delivery.

Of course, that simplicity comes at a cost. Once you decide to build on UDP, you quickly discover that all the capabilities TCP provided for free still need to exist somewhere. Reliability, congestion control, encryption, flow control, connection management... none of these problems disappear.

WebRTC: solving it, at a cost

We've spent enough years working with WebRTC to know exactly what that means.

WebRTC makes real-time intercommunication possible between browsers and mobile devices. But anyone who has built production systems on top of it also knows how much machinery is hiding underneath the surface. Over the years, the ecosystem accumulated a substantial collection of technologies designed to make UDP suitable for large-scale real-time communication. And if you've ever spent hours chasing connectivity problems, comparing ICE candidates, inspecting STUN responses, or trying to understand why two endpoints can communicate with everyone except each other, you know that "real-time communication" often turns into "real-time debugging."

The industry therefore finds itself in an interesting position: TCP is reliable but sometimes too rigid, UDP is flexible but leaves too much responsibility to applications, and WebRTC solves many of those problems, but at the cost of considerable complexity.

Enter QUIC

This is where QUIC might enter the picture.

Rather than asking applications to choose between TCP and a collection of UDP-based building blocks, QUIC attempts to provide a modern transport layer that combines the strengths of both approaches. It runs on top of UDP but includes features that developers previously had to obtain elsewhere: built-in encryption, stream multiplexing, modern congestion control, connection migration, and transport semantics designed for today's Internet rather than the one of several decades ago.

Perhaps most importantly, QUIC removes one of the biggest frustrations inherited from TCP: multiple streams can coexist within the same connection without a lost packet in one stream blocking progress in all the others. That seemingly simple change addresses a problem network engineers have been working around for years.

Our take: what comes next

What makes QUIC particularly exciting is the possibility that it could become the foundation for the next generation of real-time application transports. Technologies such as WebTransport are already exploring that direction, exposing capabilities that allow applications to benefit much more directly from QUIC's transport model. While the ecosystem is still evolving, it's not difficult to imagine a future where developers reach for QUIC-based transports instead of immediately defaulting to either TCP or WebRTC.

Whether QUIC ultimately becomes a true successor for many WebRTC use cases remains to be seen, but we'll certainly be following its evolution and the industry's adoption of QUIC.