New QUIC protocol promises faster Web apps
The QUIC protocol may or may not become a standard, but either way, use of the protocol could provide a performance boost for Web and mobile apps.
Google laid the groundwork for the latest improvements to the HTTP protocol that has dominated Web applications and RESTful APIs for the past 20 years. This work resulted in the release of the HTTP/2 standard now being pushed across the Web. Now, Google is working on a newer protocol called Quick UDP Internet Connection (QUIC) that uses UDP instead of TCP. Although it's still in early development, some improvements baked into the QUIC protocol could be brought into the main HTTP protocol in the future.
Raghu Venkat, CPO and co-founder of Instart Logic, said, "HTTP/2 is attempting to solve many of the latency problems by multiplexing, compressing headers, server-push, etc., but it is still running on top of the legacy TCP standard. Google is now working on a new experimental protocol called QUIC, which leverages UDP to reduce application startup time and the latency inherent in wireless connections."
With QUIC the likely standard protocol for mobile applications, companies that are betting on short-term proprietary protocols will be a distant memory.
Raghu Venkat,
CPO and co-founder, Instart Logic
The significance of UDP
TCP has been the dominant Internet protocol for decades, but faces shortcomings related to latency and congestion. Venkat argues that more needs to be done for lossy wireless networks. Ultimately, the QUIC protocol seeks to provide a real-time performance improvement over TCP with lower latency connections, improved congestion control and better loss recovery.
Peter Danzig, CEO of Panier Analytics, a new Internet of Things smart grid service, said that there was a lot of excitement about using UDP in the early days of streaming media. Both Microsoft and Real had UDP-based products, but these applications did a poor job at implementing congestion control. As a result, most modern applications have been built to support TCP for its congestion control and flow control capabilities.
It has been hard to get the code right for doing congestion control with UDP. The QUIC protocol overcomes the limitations of UDP by implementing features needed for the HTTP connection in the application layer. QUIC also supports TCP in case users are behind a firewall and it is not possible to send UDP packets.
QUIC provides a quicker start time
One of the benefits of the QUIC protocol is that it eliminates the three roundtrip requests required for TCP combined with Transport Layer Security (TLS). The first time a QUIC client connects to a server, the client must perform a one-round-trip handshake to set up the secure connection, but thereafter, the credentials are cached so future round trips are not required.
Danzig said, "The notion of QUIC is that you can cash a lot of these sockets to avoid extra handshakes. You don't eliminate sockets, but you can use principles for designing an architecture that can cache hundreds of sockets. At Akamai [Technologies, where Danzig was the vice president of technology], we were doing hundreds of thousands of sockets and it was not a big challenge, but it hasn't been widely used by other developers."
Making up for lost packets
When a packet is lost using HTTP/1.1 or 2, the application can stall waiting for a critical missing packet. QUIC does a better job of sending missing packets in conjunction with new packets, with a shorter delay.
The server and routers need to know which packets to transport. Another feature of TCP is that the data appears in the same order that it was sent. With QUIC, the Web server can send parts of the webpage out of order in such a way that congestion control is being done right, and if some of that data gets lost, it can be resent because it takes advantage of the best practices baked into TCP.
Support for multiple-page content means the server can better send a page with both style sheets and queries being computed. QUIC allows content to come to the browser out of order and in a way that is not slowed down by congestion losses.
Pay it forward
QUIC is especially well-suited for mobile applications, Danzig said. Modern wireless networks introduce a new and separate problem that isn't well addressed by the congestion control features built in to TCP. The problem is that TCP quickly decreases and slowly increases the rate if too many packets are lost.
In the last-mile wireless connection, the loss is frequently caused by wireless interference or a poor connection. In these cases, it makes more sense to use forward error correction to send redundant packets to replace lost ones in advance. This allows the client application to reassemble lost packets using this redundant data rather than waiting for a new packet to be requested and sent back from the server.
TCP has difficulty distinguishing between cases when the last hop is going over a weak wireless signal and when the connection is suffering router congestion. As a result, TCP just slows down when it detects lost packets from a weak signal, which does not efficiently address the fundamental problem. In contrast, QUIC tries to increase the forward error correction redundancy to account for the weak link.
Quickly evolving into mobile standard
In early experiments, Google has already seen QUIC outshine TCP by shaving a full second off the Google Search page load times for the slowest 1% of connections. YouTube also has seen a remarkable improvement with 30% fewer rebuffers when watching videos over QUIC.
Even if QUIC itself does not materialize into a standard, implementation of the protocol could provide a much-needed performance boost for both Web and mobile applications. Today, roughly half of all requests served over Google Chrome are using the QUIC protocol and it will eventually be the default transport protocol for the browser, accessing both mobile apps and properties.
QUIC also holds promise for reducing the startup time and congestion control elements in setting up and processing RESTful API calls. This means QUIC could improve server-to-server communications and server-to-client communications built on top of REST or other protocols that use HTTP today. Ilya Grigorik, senior engineer at Google involved with QUIC said, "Wherever HTTP is used, QUIC applies."
It is only a matter of time before QUIC is available as an iOS and Android SDK and as the default protocol for mobile applications. Venkat said, "As the implementation inefficiencies of the QUIC protocol improves, in theory, this should provide a substantial boost to the high latency, lossy wireless last mile networks where round trip matters. With QUIC the likely standard protocol for mobile applications, companies that are betting on short-term proprietary protocols will be a distant memory."
