Chromium Blog has published an update on Quick UDP Internet Connections (QUIC). QUIC is a UDP-based transport layer network protocol which began testing in the Google Chrome browser in 2013. One of the goals of QUIC is to reduce latency compared to TCP by making fewer round trips between clients and servers. It also handles multiplexing and packet loss better.
QUIC clients store information about QUIC-enabled servers that have been connected to previously, allowing a secure connection to be established immediately (zero-round-trip). Google claims this can enable significant reductions in page load times:
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.
Google plans to propose QUIC to the Internet Engineering Task Force as an Internet standard, just as it has done with SPDY, which is being superseded by the HTTP/2 standard.
Related Stories
In an ever-evolving world where every technology gets a transition sooner or later, Hypertext Transfer Protocol (HTTP) seemed the exception: it went on unchanged for fifteen years. Too much time for Google, who started developing its own alternative: SPDY. As time would have it, SPDY became the cornerstone for the work on the new HTTP/2, and now that this new standard is so close as to be in IETF Last Call state, Google is happy to say Hello HTTP/2, Goodbye SPDY, move in to the new standard, and drop SPDY support on Google Chrome in about a year.
This news is available in Ars Technica and Slashdot too.
curl hacker Daniel Stenberg has announced that his online booklet, HTTP/3 Explained, is available for download from GitHub. The booklet will remain a work in progress as neither the protocol specifications themselves nor any working implmementation are even remotely ready at this moment.
The book describes what HTTP/3 and its underlying transport protocol QUIC are, why they exist, what features they have and how they work. The book is meant to be readable and understandable for most people with a rudimentary level of network knowledge or better.
These protocols are not done yet, there aren't even any implementation of these protocols in the main browsers yet! The book will be updated and extended along the way when things change, implementations mature and the protocols settle.
Earlier on SN:
The Next Version of HTTP Won't be Using TCP (2018)
Google Touts QUIC Protocol (2015)
Google isn't the company that we should have handed the Web over to
Back in 2009, Google introduced SPDY, a proprietary replacement for HTTP that addressed what Google saw as certain performance issues with existing HTTP/1.1. Google wasn't exactly wrong in its assessments, but SPDY was something of a unilateral act, with Google responsible for the design and functionality. SPDY was adopted by other browsers and Web servers over the next few years, and Google's protocol became widespread.
[...] The same story is repeating with HTTP/3. In 2012, Google announced a new experimental protocol, QUIC, intended again to address performance issues with existing HTTP/1.1 and HTTP/2. Google deployed QUIC, and Chrome would use QUIC when communicating with Google properties. Again, QUIC became the basis for IETF's HTTP development, and HTTP/3 uses a derivative of QUIC that's modified from and incompatible with Google's initial work.
It's not just HTTP that Google has repeatedly worked to replace. Google AMP ("Accelerated Mobile Pages") is a cut-down HTML combined with Google-supplied JavaScript designed to make mobile Web content load faster. This year, Google said that it would try to build AMP with Web standards and introduced a new governance model that gave the project much wider industry oversight.
A person claiming to be a former Microsoft Edge developer has written about a tactic Google supposedly used to harm the competing browser's performance:
A person claiming to be a former Edge developer has today described one such action. For no obvious reason, Google changed YouTube to add a hidden, empty HTML element that overlaid each video. This element disabled Edge's fastest, most efficient hardware accelerated video decoding. It hurt Edge's battery-life performance and took it below Chrome's. The change didn't improve Chrome's performance and didn't appear to serve any real purpose; it just hurt Edge, allowing Google to claim that Chrome's battery life was actually superior to Edge's. Microsoft asked Google if the company could remove the element, to no avail.
The latest version of Edge addresses the YouTube issue and reinstated Edge's performance. But when the company talks of having to do extra work to ensure EdgeHTML is compatible with the Web, this is the kind of thing that Microsoft has been forced to do.
See also: Ex Edge developer blames Google tricks in part for move to Chromium
Related: HTTP/2 on its Way In, SPDY on its Way Out
Google Touts QUIC Protocol
Google Attempting to Standardize Features of Accelerated Mobile Pages (AMP)
Google AMP Can Go To Hell
The Next Version of HTTP Won't be Using TCP
HTTP/3 Explained: A Work in Progress
Microsoft Reportedly Building a Chromium-Based Web Browser to Replace Edge, and "Windows Lite" OS
Mozilla CEO Warns Microsoft's Switch to Chromium Will Give More Control of the Web to Google
(Score: 0, Troll) by Anonymous Coward on Monday April 20 2015, @12:45AM
"QUIC clients store information about QUIC-enabled servers that have been connected to previously, allowing a secure connection to be established immediately (zero-round-trip)."
So the client remembers and reuses. Since it is in the channel, it can also report aback about of the other sites you been to. No need for Super-Cookie or other functions to track you. Now the protocol will track you instead.
(Score: 0) by Anonymous Coward on Monday April 20 2015, @12:57AM
Only if you keep the 'connection' open. At which point it would I guess start at 0 again? Or were you speculating too?
(Score: 0, Interesting) by Anonymous Coward on Monday April 20 2015, @02:20AM
trying to read between the lines.
Google would like better and faster connections. Means more traffic per server, since the some of existing overhead gone, hence saves money.
But at the same time, having a man-in-the-middle will help their ad business, since client appears to be located after the decryption. Yes, we could cut down the cross site little web-bugs to track us, so less traffic would be coming to our clients or cookies being sent, so our personal pipes will be less full, so better speed.
But it is like using Google Chrome - please log in, tell me who you are. There, they have full browser. This sounds like being in every other browser too.
(Score: 3, Interesting) by Non Sequor on Monday April 20 2015, @03:04AM
If you look at the arc of all of Google's work in web standards and platforms using those standards, Google's end game seems to be making native apps have no advantage over web apps for a typical user. I figure that since they profit as a middle man on the web, they must see anything that results in more stuff being done with web browsers as growing their market.
From that perspective, Android was originally backed by Google for the purpose of driving out crappy web browsers on most phones at the time it was introduced. Chrome is a testbed for standards work to make new APIs for their web app,development, and also originally to put pressure on other browsers to improve javascript performance. The work on reducing latency relates to findings from A-B testing that users are highly sensitive to page load times and are much more likely to leave if they encounter even marginally slower page loads.
Write your congressman. Tell him he sucks.
(Score: 2) by kaszz on Tuesday April 21 2015, @09:30PM
I think the web has become bloated and overloaded on purposes. It's not a slim solution anymore. So let's keep the web-octopus out of the core protocol arena so we actually do useful things on the web. Corporations can't be trusted!
(Score: 0, Interesting) by Anonymous Coward on Monday April 20 2015, @02:22AM
Now the protocol will track you instead.
Exactly.
They are probably planning on slowing down the internet to a crawl. Dialup speeds would he hard to come by, and 300 baud would be considered fast.
A question to ask here would be: who would this benefit most? Google, Big Brother, or the slowest 1% of users. And why would someone care about the slowest of connections? Why do we need another standard that hasn't been through anything yet?
protocol which began testing in the Google Chrome browser in 2013
Which is why I will never use Chrome browser. It installs itself into every corner of the system and is hard to get rid of: Adds itself to "Task Scheduler" in Windows for "updates". $Diety knows what updates it might be infecting the system with.
(Score: 1, Insightful) by Anonymous Coward on Monday April 20 2015, @02:58AM
Huh? QUIC uses a synchronisation cookie. What's all this "channel reporting back" fluff?
(Score: 1, Informative) by Anonymous Coward on Monday April 20 2015, @01:38PM
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment [wikipedia.org]
Pay attention to the segment sequence number.
In these sorts of protocols you have some sort of tracking id. It is done so you can properly ACK packet segments.
Notice how they use random ids in TCP. They used to use sequential then a formula that could be guessed. But people could 'guess' the number and then create spoofing at the transmission level.
My guess is their speedup comes from not having to go out to the random code and reduction of duplicate processing. Unfortunately random ids come at a higher cost on both ends.
(Score: 4, Informative) by toygeek on Monday April 20 2015, @01:21AM
https://mosh.mit.edu/ [mit.edu]
From their site: "Unlike SSH, mosh's UDP-based protocol handles packet loss gracefully, and sets the frame rate based on network conditions"
I have a lousy 1.5mbps connection sometimes with a lot of latency, and Mosh works beautifully. I would love to see the same improvements brought to browsing.
There is no Sig. Okay, maybe a short one. http://miscdotgeek.com
(Score: 3, Informative) by gnuman on Monday April 20 2015, @04:09PM
Mosh is an interactive shell. Use of UDP is a good thing there, like for interactive games. You avoid problems with retransmissions/reordering of packets.
But that means you DO NOT use it for bulk traffic, like HTTP. For watching non-interactive videos. That is the antithesis of correct network behavior. UDP like that kills transparent proxies and kills other UDP protocols - SIP (RTP), UDP.
UDP is not suppose to be used for bulk transfers. If you saturate your bandwidth with some retarded UDP based video stream, all you end up doing is DOSing your own ability to receive other UDP packets, like SIP or DNS. And unlike TCP, you can't prevent UDP from saturating your incoming pipe on ingres.
Users report 30% fewer rebuffers when watching videos over QUIC.
And how about another user that wanted to use normal internet services at the same time on that network?
Saturating your connection with UDP protocol is essentially giving other network users a middle finger. I don't want to do DPI to differentiate QUIC from the rest of UDP.0
If Google wants to make a new protocol - fine. But reserve your own number for the protocol, and not just repurpose UDP.