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.
(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.