QUIC - Faster Content Delivery on Layer 4
After HTTP/2, the next come up is QUIC, a new transport network protocol. At the beginning this protocol was designed by Jim Roskind at Google. It was publicly released in 2013 after the implementation and experimentation in 2012. Originally being an acronym for Quick UDP Internet Connections, the Internet Engineering Task Force (IETF) has stated it’s the name of the protocol and not an acronym.
Google has been working for quite some time to speed up network protocols in order to optimize network response times. Now that HTTP/2 has been fulfilling its task of speeding up how HTTP uses TCP and has become the basis for fast TLS connections, QUIC goes one step further by aiming to completely replace TCP.
Before becoming an Internet standard, the mapping of HTTP over QUIC was renamed to HTTP/3 in November 2018 by IETF members after a request by Mark Nottingham, the Chair of the IETF HTTP and QUIC Working Groups. This will be the third major version of the HTTP protocol that allows data to be exchanged on the World Wide Web and will succeed HTTP/2. It will take full advantage of the significant performance benefits that QUIC offers.
Fast UDP with QUIC
TCP and TLS usually require one or more round trip times (RTT) during their connection establishment. An RTT is the total time it takes for a request to go from the starting point to the destination and then back to the starting point. Google is hopeful that QUIC can reduce connection costs towards zero RTTs.
TCP ensures that all packets arrive in order, but does so in a somewhat cumbersome manner, which slows down data transmission on the Internet. By contrast, QUIC is based on UDP, which is used for streaming data (hence the initial name Quick UDP Internet Connections). Unique sequence numbers ensure that no data packet get lost. The other most important component used is the TLS encryption protocol, which has mostly appeared in conjunction with TCP until now. While no corners are cut with regard to security, doing away with handshakes and multiplex transmissions enables faster transmission, even compared to other UDP-based protocols, reportedly.
From Google's QUIC FAQ:
Why can't you just evolve and improve TCP under SPDY? That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
QUIC has been supported by Chrome since version 29. According to Google, about half of all requests from Chrome to Google web servers are served over QUIC. It can be enabled in Chrome by going to
chrome://flags/#enable-quic in the browser address bar.
It can be enabled in Opera by going to
opera://flags/#enable-quic in the browser address bar.
QUIC and HTTP/3
Google has found that 75% of all requests are served faster over QUIC and that TCP based websites and content that is streamed will greatly benefit from it. Especially video services like YouTube, where users report 30% fewer rebuffers when watching videos over QUIC. With such big changes it will take time for QUIC to become the most commonly used transfer protocol. At the time of writing this only 2.4% of websites use QUIC.
As a next step, HTTP-over-QUIC has been proposed to the IETF and has been approved as HTTP/3. If the standard establishes itself and other servers implement it, the most frequently used transport network protocol used today, TCP, may be replaced on the web.
Google Chrome Canary is the first browser to support HTTP/3 and since version 7.66 curl also supports it. Support for this new HTTP protocol will be coming later in 2019 to Firefox Nightly. As exerimiation continues and improvements are made you will see the support of HTTP/3 grow.
The QUIC protocol has been a large work in progress and has made serious advancements in the last few years. This has led to the beginning of the next HTTP protocol, HTTP/3. As the number of people that have access to the Internet is continually growing adopting HTTP/3 will help bring performance improvements.
We don’t have an exact date yet on when our network will support HTTP/3, but we have already started to engineer possible integration scenarios and will keep you updated as we make progress.