10 Jul 2013, 23:35

Google to reinvent how the web works one step further

Before going into details about this news, a reminder/introduction :

  • Web content is accessible using the HTTP protocol. So when you type "http://www.steinmetz.fr" in your browser, you ask it to use the http protocol and load the content from www.steinmetz.fr.
  • HTTP protocoal version is 1.1
  • The "HTTP" layer is on top another protocol which is called "TCP" for "Transmission Control Protocol". It aims to provide a safe and reliable trasnfer protocol over IP. The issue of TCP is that it will generate latency due to the control checking it provides.
  • IP has another protocol which does less error checing and transport validation and thus has a lower operation overhead and reduced latency. It's called UDP.

I encourage you to read the wikipedia articles on TCP & UDP to get more details , it's really a quick summary I made.

Back to 2009, Google announce the SPDY as an experimental protocoal for a faster web. It aims to be an improved version of the HTTP protocol by reducing page load time. It's mostly done using compression and multiplexing (several http request per tcp session instead of one). As of July 2012, SPDY is a de facto standard and Google is looking for an official standardisation as SPDY will be used as basis for the HTTP/2.0 project. It is currently implemented in most modern browsers (Internet Explorer will have it in IE11). On sever side, SPDY is already implemented also in Apache and Nginx web servers at least. 

End of June this year, Google announced QUIC which stands for Quick UDP Internet Connections. It aims to reduce the latency which is the main issue nowadays for web. Main QUIC highlights:

  • Secure by using a similar mechanism to TLS
  • Fast (often 0-RTT) connectivity  (RTT for Round Trip Time is the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received). It will use some checksum / identifying mechanism instead
  • 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

At the end, it aims to provide a reliable and secure transport layer as TCP does but without its latency and congestion.

As explained in the FAQ, even if SPDY reduced latency, the issue was still that if a HTTP connection stalled, it would stall the whole process. With QUIC relying on UDP, it would be less true as packets will come in any order and then be formed whereas for TCP they arrive in series. 

Coming version of Google Chrome will have the QUIC protocol enabled so that Google Developpers will have some feedback about how it works for real when users access Google servers as part of them are QUIC compliant.

Let's see how it would move forward, if it works and if they manage to make it a standard for a QUICker web ;-)