Google gooses Chrome with network speed-boost idea: 'QUIC'

On the heels of its SPDY success for goosing Web communications standards, Google is tinkering with an even lower-level protocol with a project called QUIC.

To see if the technology meets its potential without causing new problems, Google has built QUIC into developer versions of Chrome and enabled it for a fraction of users. The hope is that it will cut the round-trip time of the back-and-forth communications between computers on the Internet, according to a blog item posted Thursday by Google engineer Jim Roskind.

"If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards," Roskind said.

SPDY is now well on its way to revising the HTTP standard, which governs how Web browsers communicate with the Web servers that house Web pages. Even Microsoft, an early skeptic, is on board with IE 11.

Google has a powerful interest in a faster Internet. Lower delays mean Web pages and services respond faster, and that generally means people use the Internet more. That means, of course, that they use Google services more, especially search and its attendant search advertising. With a popular browser and popular Web sites, Google has the ability to run experiments that involve both ends of the network.

Unlike SPDY, QUIC actually stands for something: Quick UDP Internet Connections. It offers an alternative to TCP (Transmission Control Protocol) one of the most fundamental parts of how data is transferred across the Internet.

TCP's job is to make sure packets routed across the Internet really are delivered. It offers reliability, but at a price. Another fixture of Internet data transfer, UDP (User Datagram Protocol) is faster but doesn't offer TCP's error-checking reliability. QUIC is based on UDP but offers its own error-correction technology, Roskind said.

Google couldn't build a whole new protocol, because network equipment on the Internet generally blocks any traffic that's not UDP or TCP, Google said. Thus, it recrafted UDP to get something that works on today's Internet.

In addition, QUIC offers an encryption mechanism for security similar to the TLS standard used in encrypting Web site communications.

Google built encryption into SPDY, too, something that caused indigestion for some companies running content delivery networks (CDNs) accustomed to serving as useful middlemen between origin servers and people's browsers. But Google believes it's necessary. "As we learned with SPDY and other protocols, if we don't encrypt the traffic, then middle boxes are guaranteed to (wittingly, or unwittingly) corrupt the transmissions when they try to 'helpfully' filter or 'improve' the traffic," Google's QUIC FAQ said.

Next comes the testing, Roskind said:

Early tests of UDP connectivity have been promising, but we have learned from past experience that real-world network conditions often differ considerably. Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY. Users shouldn't notice any difference -- except hopefully a faster load time. If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards.

Another difference compared with ordinary UDP is that QUIC attempts to keep networks from getting overwhelmed with traffic. "QUIC employs congestion controls, just as it employs automatic retransmission to support reliable transport. QUIC will attempt to be fair with competing TCP traffic," the FAQ said.

For more information, interested people can check the QUIC design document.