Monday, April 27, 2015

Google Looking to Increase Internet Speeds with QUIC Network

Google has been stress-testing its QUIC (Quick UPD Internet Connections) network protocol the past quarter. Right now, about half of requests from Chrome to Google servers are being set through QUIC and the company says it's leading to a greater performance improvement over TCP resulting in an increasing amount of traffic.

QUIC supports multiplexed transport over UDP while also giving security comparable to TLS/SSL. It is also cutting down on latency by relying on UDP instead of TCP. As of now the only real concern with latency-sensitive services like Google Search is how the UDP-based QUIC outperforms TCP by establishing connections with servers its already communicated with, without any hassle or extra round trips to the server. QUIC gets the better part of TCP in poor network conditions.

“The standard way to do secure web browsing involves communicating over TCP + TLS, which requires 2 to 3 round trips with a server to establish a secure connection before the browser can request the actual web page,” Google wrote in a blog post Friday.

When re-transmitting a packet, packet sequence numbers are never reused. This helps figure out which packets have been received as well as not having to worry about your internet timing out. QUIC over TCP has helped save a second off of the Google Search page load time for the slowest 1% of connections. This helps sites like YouTube, for watching videos online. Viewers have reported 30% fewer rebuffers using QUIC to watch videos.


Google also wants to ask if the Internet Engineering Task Force (IETF), with some changes like the wire format and dissociate the current plan from SPDY and moving to QUIC-over-HTTP2, will make the protocol an Internet standard. Google wants to continue increasing traffic over the protocol, with the overall outcome of entrusting it with all the traffic from Google clients to Google services.

Google is expecting good things to come from this so we'll see how it all plays out in the end.

Content originally published here

No comments: