Once upon a time, much of the high-value and high-volume traffic on the Internet was TCP-based. Games and other real-time applications adopted UDP early to avoid the head-of-the-line blocking problems inherent in TCP’s design. However, these applications tend to use a relatively low traffic volume.
What’s changed?
A few things (at least):
- The rise of video conferencing and remote work
- The use of UDP (QUIC) for large-scale content delivery
- The rise of QUIC as a general-purpose transport protocol that has many advantages over TCP and is at the core of HTTP3 (the web is moving to UDP)
As an example, below are the bitrates for TCP and UDP capture on my home router. This capture has all the traffic associated with the 50+ Internet-connected things in my house as well as:
- I did my normal work activity, which included:
- Web browsing to applications like Jira, HubSpot, our app etc.
- A Google Meet video call with one of my colleagues
- A YouTube video was streaming on a TV via a Chromecast
- One of the kids was playing online games on his Nintendo Switch
Blue is UDP, red is TCP.
I suspect some people will find this surprising. UDP completely dominates this typical workload. Notice the long periods of near TCP-silence
Why? YouTube uses QUIC/UDP for content delivery. Google Meet uses UDP for video and audio. It’s likely the kid’s game is hidden in the large amount of UDP traffic as well. The little red spikes are likely web browsing activity.
Note that other video conferencing applications like Zoom also use UDP.
That’s bitrate; let’s look at the packet count.
79% of packets are UDP. This isn’t your parent’s TCP-based Internet anymore.
QUIC As a General Purpose Transport Protocol
QUIC is a newish transport protocol that is based on top of UDP. It offers the same reliable delivery model of TCP and more. A simple way to think of a QUIC connection is as a bunch of TCP flows riding on top of the same UDP flow.
Describing all the goodness in QUIC is outside the scope of this article. A few interesting pieces include:
- Enables multiple simultaneous streams within a connection
- Loss in one stream does not impact delivery on the other streams (fixes TCP’s head-of-line blocking problem)
- Both reliable (stream) and unreliable (datagram) based streams are available within the same connection
- Application-level (not kernel) implementation
- Completely encrypted, not even the control information, such as the sequence number, is visible to the ISP or anyone else. This was a key design criterion.
To dig deeper, follow the rabbit trail from the Wikipedia QUIC page – https://en.wikipedia.org/wiki/QUIC. That page includes links to QUIC implementations in many languages.
Today QUIC is used extensively by Google. YouTube, Gmail, Search, and most other Google traffic use QUIC if you have a reasonably new browser.
But that’s far from all:
Finding more examples isn’t hard.
Given the many advantages of QUIC over TCP, we’ll likely see its usage continue to grow in all types of applications, from video conferencing to games and APIs.
HTTP (The Web)
Since its inception, HTTP, the protocol that underlies the web has been TCP based.
This is changing.
HTTP/3, the newest HTTP standard, is entirely based on QUIC to bring the benefits of QUIC to websites and applications.
Major CDN providers and HTTP libraries now already have full support for QUIC or are making progress. Cloudflare, for example, has extensive support (https://cloudflare-quic.com/).
It’s a brave new UDP world.
