ChromeQUIC

Introduction to Google’s QUIC Protocol

Load times have always been critical to reaching a web audience. From optimizing every image and minifying code to save several KB’s and creating sprites to reduce HTTP requests, developers are always trying to deliver information faster and . At Sysnovo, AB Testing and optimization is a part of the iterative web design and development process, so we’re always looking for ways to minimize our load times and deliver superior content. Google’s new QUIC network protocol is exactly that; a promising new way to improve network performance on the transport layer.
The traditional TCP/IP network protocol makes it very difficult to make major improvements in terms of latency. The QUIC protocol runs Transport Layer Security (TLS) over User Datagram Protocol (UDP) and reduces one-way latency and round-trip times (RTT) down to light’s physical limitations of around 5 microseconds per Kilometer. The QUIC protocol is based on the recent SPDY protocol that Google also developed, which has been adopted by the IETF’s httpbis group as the foundation for the development of HTTP 2.0 – Check out this Internet Engineering Task Force link to learn more.

Essentially, the QUIC protocol could one day replace TLS/SSL and TCP in the near future as the protocol of the web and offer near zero RTT and reduced network congestion. The impact would change the way information delivery and presentation across the web! Designers and developers would have to rethink the way they structure content and refocus their attention on the message and the delivery rather than on size and load time constraints. Imagine building rich and immersive websites that deliver entire applications in the same time that it would take to load a single page today! We look forward to the days of HTTP2 and encourage you to think about the possibilities and the opportunities that lie ahead as the world becomes more and more connected to ever-improving technology!
Here are some of the benefits:

[su_list icon=”icon: caret-right”]

  • Fast (often 0-RTT) connectivity similar to TLS Snapstart combined with TCP Fast Open
  • High security similar to TLS
  • Packet pacing to reduce packet loss
  • Packet error correction to reduce retransmission latency
  • UDP transport to avoid TCP head-of-line blocking
  • A connection identifier to reduce reconnections for mobile clients
  • A pluggable congestion control mechanism

[/su_list]

The QUIC was merged into Google Chrome and has been part of version 29. It can be turned on at chrome://flags/#enable-quic and active sessions can be seen at chrome://net-internals/#quic.

What do you think? Share some of your ideas on how the next generation of web platforms and protocols will change the way you design and develop. What do you think about Google being involved in the design of the web protocol? One of the main motivations of Google’s development of QUIC was to improve the head-of-line blocking that occurs on SPDY stream sets with TCP. Could Google’s motives be questioned? Let us know.

 

Relevant Links:

 

As always, like us on Facebook, follow us on Twitter, and join our circle on Google+