SoylentNews is people
SoylentNews
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: 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.