Chromium Blog: A QUIC update on Google’s experimental transport

Chromium Blog

News and developments from the open source browser project

A QUIC update on Google’s experimental transport

Friday, April 17, 2015

Last year we announced QUIC, a UDP-based transport protocol for the modern Internet. Over the last quarter, we’ve been increasing the amount of traffic to Google services that is served over QUIC and analyzing QUIC performance at scale. Results so far are positive, with the data showing that QUIC provides a real performance improvement over TCP thanks to QUIC's lower-latency connection establishment, improved congestion control, and better loss recovery.
For latency-sensitive services like web search, the largest gains come from zero-round-trip connection establishment. The standard way to do secure web browsing involves communicating over TCP + TLS, which requires 2 to 3 round trips with a server to establish a secure connection before the browser can request the actual web page. QUIC is designed so that if a client has talked to a given server before, it can can start sending data without any round trips, which makes web pages load faster. The data shows that 75% percent of connections can take advantage of QUIC’s zero-round-trip feature. Even on a well-optimized site like Google Search, where connections are often pre-established, we still see a 3% improvement in mean page load time with QUIC.

Another substantial gain for QUIC is improved congestion control and loss recovery. Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts. As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
Where do we go from here? Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers. We plan to formally propose QUIC to the IETF as an Internet standard but we have some housekeeping to do first, like changing the wire format and updating our reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC. In the coming months, we also plan to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections.
If you want to follow along or play around, feel free to check out the code and experiment with it, or join proto-quic@chromium.org as we continue to improve the Internet, one packet at a time.
Posted by SYN, SYN-ACK and ACK (also known as Alyssa Wilk, Ryan Hamilton and Ian Swett)