Google, as is its wont, is always trying to make the World Wide Web go faster. To that end, Google in 2009 unveiled SPDY, a networking protocol that reduces latency and is now being built into HTTP 2.0. SPDY is now supported by Chrome, Firefox, Opera, and the upcoming Internet Explorer 11.

But SPDY isn't enough. Yesterday, Google released a boatload of information about its next protocol, one that could reshape how the Web routes traffic. QUIC—standing for Quick UDP Internet Connections—was created to reduce the number of round trips data makes as it traverses the Internet in order to load stuff into your browser.

Although it is still in its early stages, Google is going to start testing the protocol on a "small percentage" of Chrome users who use the development or canary versions of the browser—the experimental versions that often contain features not stable enough for everyone. QUIC has been built into these test versions of Chrome and into Google's servers. The client and server implementations are open source, just as Chromium is.

"Users shouldn't notice any difference—except hopefully a faster load time," Google's Jim Roskind wrote in a blog post.

Roskind apparently goes by the title of "RTT Reduction Ranger" at Google, referring to "round trip time." Roskind wrote that round trip time, "which is ultimately bounded by the speed of light—is not decreasing, and will remain high on mobile networks for the foreseeable future." QUIC, he writes, "runs a stream multiplexing protocol over a new flavor of Transport Layer Security (TLS) on top of UDP instead of TCP. QUIC combines a carefully selected collection of techniques to reduce the number of round trips we need as we surf the Internet."

An FAQ and an in-depth design document provide more information than most people would want to know about QUIC. Besides running multiplexed connections over UDP, QUIC was "designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency," the FAQ states.

"QUIC will employ bandwidth estimation in each direction into congestion avoidance, and then pace packet transmissions evenly to reduce packet loss," Google says. "It will also use packet-level error correction codes to reduce the need to retransmit lost packet data. QUIC aligns cryptographic block boundaries with packet boundaries so that packet loss impact is further contained."

Google had to design QUIC carefully to avoid it becoming a nice theoretical system with no applicability to the real world. That's why Google is using UDP instead of building a protocol made entirely of new technologies. "Middle boxes on the Internet today will generally block traffic unless it is TCP or UDP traffic," Google said. "Since we couldn’t significantly modify TCP, we had to use UDP. UDP is used today by many game systems, as well as VoIP and streaming video, so its use seems plausible."

Ultimately, Google's goal is not necessarily to replace the Web's current protocols but to bring improvements to how TCP is used with SPDY. SPDY already provides multiplexed connections over SSL, but it runs across TCP, causing some latency issues.

Whereas TCP uses a three-step process (or a "handshake") to negotiate connections between Web users and servers, UDP is handshake-less. UDP sends packets out the door without any error checking, improving speed while reducing reliability. QUIC attempts to provide the speed advantages of UDP while making data delivery more reliable.

From Google's QUIC FAQ:

Why can’t you just evolve and improve TCP under SPDY? That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.

A major problem with SPDY over TCP today is that "[a] single lost packet in an underlying TCP connection stalls all of the multiplexed SPDY streams over that connection," Google said. "With UDP, QUIC can support out-of-order delivery, so that a lost packet will typically impact (stall) at most one stream."

TCP and TLS/SSL also typically "require one or more round trip times (RTTs) during connection establishment," Google said. "We’re hopeful that QUIC can commonly reduce connection costs toward zero RTTs. (i.e., send hello, and then send data request without waiting)."

Google doesn't know just how much faster QUIC will make Web surfing, because in-house tests often differ significantly from real-world network conditions. That's why testing with actual Web users is crucial. The question of how much QUIC is able to reduce latency in the real World Wide Web is what "we are investigating at the moment, and why we are experimenting with various features and techniques in Chromium," Google said. "It is too early to share any preliminary results—stay tuned."