You may have never heard of it, but if you are a Chrome user, chances are you’ve used Google’s QUIC protocol already. As Google disclosed this week, about half of all requests from Chrome to Google’s servers are now served over QUIC.
So what’s the big deal here? QUIC is Google’s experimental, low-latency Internet transportation protocol over UDP, a protocol that is often used by gaming, streaming media and VoIP services. The name ‘QUIC’ stands for Quick UDP Internet Connection.
UDP’s (and QUIC’s) counterpart in the protocol world is basically TCP (which in combination with the Internet Protocol (IP) makes up the core communication language of the Internet). UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. This means that the sending server isn’t constantly talking to the receiving server to check if packages arrived and if they arrived in the right order, for example. That’s why UDP is great for gaming services. For these services, you want low overhead to reduce latency and if the server didn’t receive your latest mouse movement, there’s no need to spend a second or two to fix that because the action has already moved on. You wouldn’t want to use it to request a website, though, because you couldn’t guarantee that all the data would make it.
With QUIC, Google aims to combine some of the best features of UDP and TCP with modern security tools.
On a typical secure TCP connection, it typically takes two or three round-trips before the browser can actually start receiving data. Using QUIC, a browser can immediately start talking to a server it has talked to before. QUIC also introduces a couple of new features like congestion control and automatic re-transmission, making it more reliable that pure UDP.
With SPDY, which later became the basis for the HTTP/2 standard, Google already developed another alternative protocol that had many of the same goals as QUIC, but HTTP/2 still runs over TCP and still runs into some of the same latency cost.
It’s reasonable to ask why Google doesn’t just work on improving TCP instead then. The problem here, the company points out, is that TCP support is often built directly into operating system kernels — and that’s not something Google has any control over. “QUIC allows us to test and experiment with new ideas, and to get results sooner,” the team writes in explaining its decision. “We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.” Given how many Windows XP installs are still out there, it’s obviously not something that will happen overnight.
If Google designed a whole new protocol, then all of the machines that make up the backbone of the Internet would also have to understand it — but they already understand UDP.
Google says that it has seen about a three percent improvement in mean page load times with QUIC on Google Search. That doesn’t sound like a lot, but you have to remember that Google Search is already about as optimized as possible. Other sites — and especially latency-heavy web apps — will likely see better improvements. Users who connect to YouTube over QUIC report about 30 percent fewer rebuffers when watching videos and because of QUIC’s improved congestion control and loss recover over UDP, users on some of the slowest connection also see improved page load times with QUIC.
Google says it plans to propose HTTP2-over-QUIC to the IETF as a new Internet standard in the future.
In some ways, this mirrors Google’s work with SPDY. There, too, the company first prototyped the protocol using Chrome and its own servers and then later proposed it as the basis of the new version of HTTP.
If you want to see if your connection to Chrome uses QUIC, by the way, here is a browser extension that can tell you and you can find all the details about Chrome’s QUIC usage under the net-internals flag (chrome://net-internals/#quic).
Comment