You may have never heard of it, but if you are a Chrome users, 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 UPD 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 QUICÂ net-internals flag.