QUIC: What it is, and isn't

by Seth Noble |  Blog |  Aug 03, 2021

It is no secret that TCP/IP is past its prime.  The 1974 technology responsible for controlling the flow of nearly all internet data simply hasn't kept up with the last five decades of network and computing advances.  One of the best examples of this came from Google, when they revealed experiments in which just a half-second delay in providing search results caused their search traffic to drop by 20%.  That chunk of Google's search business now represents tens of billions of dollars per year, so it is no surprise that they set about finding a way shave a few fractions of a second off of that time.

QUIC, originally an acronym for "Quick UDP Internet Connections", represents Google's efforts to reduce the time it takes to establish a secure data connection between two machines.  A traditional HTTP over TLS over TCP session requires that packets make multiple round-trips across the network before any real data communication can begin.  TCP has its three-way handshake, followed by TLS negotiation, and then the HTTP request.  With typical internet latencies on the order of 100 milliseconds, these layers of chatty communication can quickly add up to that half-second.

QUIC reduces this startup delay by integrating across the transport, security and session layers to minimize the number of network round-trips and get those search results moving faster.  But since TCP is more-or-less set in stone, QUIC required a more flexible network foundation.  UDP was invented in 1980 for just this purpose: to provide a blank-slate on which developers could create their own transport protocols.  With UDP, Google has been able to build applications which communicate using a custom transport protocol that are still compatible with standard IP networks.  This has enabled Google to build QUIC into their Chrome browser and has encouraged its adoption as an IETF standard and as the foundation of HTTP/3.

Of course, there is a lot more to data transport than just connection setup.  After those first few tenths of a second, it is flow control and error recovery which determine the speed of a data transfer.  However, that's where QUIC's innovations stop.  Much like UDP itself, QUIC allows developers to create their own algorithms.  But in practice, QUIC just uses the same legacy TCP models.  According to Google, QUIC throughput is only about 5% faster than TCP and then only under ideal conditions.

Building on top of UDP provides tremendous opportunity to innovate all aspects of data transport.  That's what we have done with the Multipurpose Transaction Protocol.  MTP/IP not only optimizes initial connections, but it also achieves maximum throughput across the life of a data transfer.  As many MTP/IP users have seen in the real world, that often means moving data many times faster than TCP.

Contrary to some of the hype out there, QUIC is an incremental improvement on one aspect of data transport.  It is great to see UDP getting more attention, as this helps everyone interested in innovating new protocols.  But to gain real network transport acceleration, try a complete solution.

For more background on the problems with TCP, and the innovations needed to solve them, read my essay From Silicon To Memes.