Taking advantage of modern protocols like HTTP3 (formerly HTT2 + QUIC)
In this article we’ll get you to know the latest web server protocols that really matter today when it comes to speed. It’s absolutely mind-boggling what Google Teams have developed and see it adopted by the top 19 Alexa’s websites. This single connection protocol is called QUIC and it bypasses all TCP limitations that we are facing today.
Jump to content:
How QUICK is QUIC?
Where does QUIC fit in?
Who has already deployed it?
Best for people on the move
What does it mean for SEO?
Pros & Cons
Requirements for UDP Connections (QUIC)
Requirements to unleash the power of HTTP/2
A bit of background
First, there was HTTP, then HTTP/2 and now HTTP/2 over the QUIC protocol, also called HTTP/3. This document will explore the available HTTP Clients and Servers that support HTTP/2 and the ‘not so’ experimental QUIC protocol.
The Hypertext Transfer Protocol (HTTP) was invented in 1991. Up until 2015 there was little to no evolution. In 2015, the HTTP/2 protocol was defined as the standard. HTTP/2 is much more efficient that its ancestors.
There are arguably no drawbacks to making the switch to HTTP/2. All major browsers support version 2 of the protocol and those that don’t will fall back to HTTP/1.1
However, one big limitation is the Transmission Control Protocol (TCP). Due to its connection-oriented nature, there’s no getting around the time it takes to open and close the connection. In other words, just enabling HTTP/2 on a server is not enough to bypass the TCP limitations and take full advantage of HTTP/2.
Google wanted to find a way around this, and in 2012 set out to develop a protocol that runs on top of User Datagram Protocol (UDP), which is connectionless protocol. The protocol is called Quick UDP Internet Connections, or QUIC.
It’s absolutely mind-boggling what the Google team developing the QUIC protocol have done.
- Single Connection. Only one connection to the server is used to load a website, and that connection remains open as long as the website is open. This reduces the number of round trips needed to set up multiple TCP connections.
- Multiplexing. Multiple requests are allowed at the same time, on the same connection. Previously, with HTTP/1.1, each transfer would have to wait for other transfers to complete.
- Server Push. Additional resources can be sent to a client for future use.
- Prioritisation. Requests are assigned dependency levels that the server can use to deliver higher priority resources faster.
- Binary. Makes HTTP/2 easier for a server to analyse, more compact and less error-prone. No additional time is wasted translating information from text to binary, which is the computer’s native language.
- Header Compression. HTTP/2 uses HPACK compressions, which reduces overhead. Many headers were sent with the same values in every request in HTTP/1.1.
So, QUIC combines the speed and possibilities of the UDP protocol with the reliability of a TCP protocol.
How QUICK is QUIC?
HTTP/3 (or QUIC on top of HTTP/2) implements various TCP features, but without the limitations, such as the round-trip time (RTT) for connection setup, flow control and congestion avoidance. With UDP’s connectionless orientation, RTT is zero since UDP just starts sending data when it needs to, rather than talking to the other side to ensure it’s available to talk.
So how much faster is QUIC? It depends of the type of website (Video websites are the worst), but Google itself published a paper about QUIC performance on their own search pages. They looked at the time it took from the point where a user enters a search term up until all the search-result content is generated, referring to this time as ‘search latency’.
Based on the data collected over a billion samples, Google saw search latency reduced by 8% across desktop devices, and a 16.7% decrease in search latency for the 99th percentile.
Where does QUIC fit in?
It simply replaces TCP with UDP. On top of QUIC is a smaller HTTP/2 API which is used to communicate with remote servers. The reason it’s smaller is because the multiplexing and connection management is already handled by QUIC. What’s left is an interpretation of the HTTP protocol.
Who has already deployed it?
9 of Alexa’s Top 19 websites support HTTP/2 or SPDY (older than QUIC). These benefits are even more apparent for Voice (VoIP) or Video services like YouTube. It’s been revealed that users report 30% fewer rebuffers when watching videos over QUIC. Have you ever tried to watch the same video through VIMEO?
HTTP/2 Adoption in the world:
At the time of this article, there was only 161,000 domains hosted on QUIC-capable infrastructure, and of those, only 15,000 presented valid certificates over QUIC. Not bad for something that is yet to become an official internet standard. More and more information can now be found about this new protocol and web server developers seem to have completed the QUIC integration this year, given the long list of hosting providers supporting it. It is also announced to be fully integrated in Apache already but not Nginx yet (or at least not from our research).
The graph below, shows the increasing number of IPv4 addresses that are capable of speaking QUIC (as observed by Jan Ruth):
Best for people ‘On the Move’
Another exciting opportunity with UDP is that you are no longer dependent on the source IP of the connection. Since more and more users today browse the web on the move, connections aren’t stable.
This is why keeping a stable connection on a mobile device is so hard, because users are constantly switching between WIFI, 4G, 3G/LTE or Edge.
also called HTTP/3 has implemented its own identifier for unique connections called the Connection UUID. It’s possible to go from WIFI to 3G/LTE and still keep the connection. The perfect solution for those commuting by train or just walking to their car!
What does it mean for SEO?
According to Google, “70% of mobile network connections globally will occur at 3G or slower speeds through 2020″. Speed, speed, and more speed to provide a better user experience across the globe and eratic connections. As time goes on, and people learn the limits of the new protocols, users should see increased speeds on HTTP/3. If you look at the network coverage of your webite through Chrome Dev Tools, you’ll immediately see that all Google solutions today utilize the HTTP/3 protocol (Lightspeed!) which is an advantage compared to rTap (Response Tap) that continues to use the HTTP/1.1 protocol as December 2021.
As with so many website improvements nowadays, the SEO impact will be felt indirectly. Google does not factor HTTP/3 readiness into its algorithms, but it does reward sites that provide a slick user experience. That includes page load speed, even more since last summer’s Google algorithm updates. Mobile has been the focal point of efforts to increase speed recently and, undoubtedly, mobile performance will be improved by the shift to HTTP/3.
In June 2009, Google admitted that they always viewed speed as a competitive advantage and asked site designers to think twice about adding a feature that hurts performance. As very few designers listened them, we believe that they had no choice but to develop their own technologies to speed up the web, like AMP and UDP.
Pros & Cons of HTTP/2 + QUIC
- Nothing faster than QUIC yet invented, although 2 other protocols tried. HTTP/3 is the future.
- Measurably improve end-user perceived latency over HTTP/1.1 using TCP
- Mature technology with enough documentation available.
- No more unnatural web dev practices (compression, inlining, etc.)
- Retain the semantics of HTTP/1.1, fall back available for old web browsers
- Stable connection for people on the move, recovers from packet loss much faster than TCP
- And we’ve skipped an ENORMOUS number of other benefits
- HTTP/3 may or may not require code refresh to take full advantage of it (read further below)
- While a large majority of hosting providers today can enable HTTP/2, the QUIC and UDP protocol may be new to your hosting provider and/or to your IT Team, who may come back with security concerns at first. It may require you to host a web server in house or use an expensive CDN like http2.akamai.com (to avoid writing your own congestion control and retransmission policies)
- As with every new technology, troubleshooting becomes a bit more difficult. (E.g. – not being able to see plaintext, without TLS encryption keys) but building and testing a new web server could be a good test and learn exercise for the Development Team.
Requirements for UDP Connections (QUIC)
TCP is routinely implemented in the kernel (core area of your server) which can mean that the Development Team are reluctant to deploy major changes. For QUIC implementation, depending on the server, there are some different ways to implements changes fairly easily, for example:
Open Source Servers
As of December 2017, 97.5% of websites using QUIC are running LiteSpeed Web Server.
Many hosting providers today start to support HTTP/3 (Quick UDP Internet Connections). If your website is hosted then it worth asking them to switch to HTTP/2 plus UDP. However, you may get a negative answer for the UDP part as that requires them to upgrade their infrastructure to this new technology. It may be best to switch to a new web hosting provider that offers this technology.
Find and compare a host that offer LiteSpeed Web Server (HTTP/3) here: https://www.whoishostingthis.com/compare/litespeed/
Although Microsoft IIS support for HTTP/2 has been introduced from IIS 10.0, Windows 10 and Windows Server 2016 it hasn’t yet enabled any library for Google’s QUIC transport protocol.
In Windows Server 2008 and Windows Server 2008 R2, RD Gateway supports only the RPC over HTTP transport. This is the only transport used when a client makes an RDP connection via RD Gateway from inside or outside the corporate network.
In contrast, RD Gateway in Windows Server 2012 supports three types of transports: RPC over HTTP, HTTP, and UDP. But UDP for Media transport (apparently).
Unfortunately, Harvest couldn’t find any MS official statement made for the QUIC protocol so far. IT Teams could still have a look at the following links that are rather old but provide some libraries for implementing the QUIC protocol in a .NET environment.
Or, build a reverse proxy infrastructure in docker to add compatibility to the web server:
What if your website is behind a Content Delivery Network (CDN)?
If your server enabled HTTP/2 and you use a CDN you should also enable HTTP/2 support via your CDN control panel. Not all providers have it enabled by default.
Cloudflare (a famous CDN) are set to deliver their first version of the QUIC by the end of 2018.
Akamai enabled QUIC on Media products starting in March 2018, now they are expanding support to many more types of products. Click here to sign up for their QUIC Tech Preview program
Security with UDP connections
The connection-oriented methods of TCP make security much easier to implement in that protocol in UDP. However, there are encryption standards available for UDP. The main option that directly aims at security UDP is the Datagram Transport Layer Security protocol or DTLS. The main difference between DTSL and TLS is that DTLS uses UDP and TLS uses TCP. It is used across web browsing, mail, instant messaging and VoIP. DTSL is one of the security protocols used for the WebRTC technology along with SRTP.
Another option for UDP users is to rely on a security system that was designed to work at the Internet Layer. IPSec includes authentication methods and also encrypts packets to protect them from wiretapping snoopers. It offers just as much security as the popular TLS, but is less widely implemented. Kerberos and the Kerberized Internet Negotiation of Keys (KINK) are two elements of a security system that is usually just called Kerberos. An exciting facility of Kerberos is that it allows you the option of employing AES encryption to protect your UDP transfers. AES is probably the most secure cipher in common usage today and it is the recommended security method for the world’s best VPN privacy protection systems
[box type=”shadow”] Download and read our documentation about Security Considerations for UDP Connections [/box]
Requirements to unleash the power of HTTP/2 and HTTP/3
Most webservers such as Apache HTTPD, NGINX etc. come with support for HTTP/2 today. One thing to bear in mind is that Apache does not yet allow for mod_php to work with HTTP/2. You can make use of FastCGI but this means that Apache will be the slowest webserver available on the market. NGINX seems to act as a better choice of webserver for HTTP/2, however, it doesn’t offer any solution yet for UDP Connections (QUIC) integration.
HTTP/2 supports various features without limitations. That means that the website’s code doesn’t necessarily need a rewrite. However, since QUIC only use one single connection to enable parallelism, a website built with multiple workarounds to increase speed will actually degrade performance of your freshly deployed HTTP/2 infrastructure. Four things to consider “optimising” when switching to HTTP/2:
• The Uncombine
• The Unsharding
With only one connection per host that is allowed with HTTP/2, domain sharding can hurt a developer’s attempt to improve performance. So if there was used previously, an upgrade to HTTP/2 means that the domains must be unsharded.
• The Uninlining
Inlining scripts directly into the HTML was another way to reduce the number of connections and round-trips to the server. With HTTP/2, this is no longer needed with only one TCP connection.
• The Unspriting
Similar to concatenation, it’s no longer necessary to bundle up your site’s images into a single sprite sheet.
[box type=”shadow”] Download our file to get further details on what needs to be changed in your code to take full advantage of the HTTP/2 protocol. [/box]
HTTP/2 adoption by vendors has been almost universal. In the browser space, all major browsers currently support the new protocol over TLS only. It’s been an exciting couple of years for the web, with the widespread adoption of HTTP/2 and Let’s Encrypt. Not only is the web becoming faster and more secure, but it’s easier than ever for developers and site owners to implement performance and security best practices. Global support is more than 80 percent at the time of writing.
But only enabling only HTTP/2 doesn’t seem to do the magic. It’s like fitting a Kia Brisa with 22” performance tyres. Obvious performance won’t come naturally unless the head of line blocking of TCP protocols is avoided.
QUIC (HTTP/3) represents a brave new world for server performance. Multiplexing-over-UDP idea has hit the standards track, but is mostly ignored.
Although it seems that system admins are still learning how it works, we have started to see a lot more documentation on QUIC in the last year, so adventurous system admins will reap the benefits of HTTP/3 as we accept the challenges that it presents.
Google Video to show the benefits:
Akamai HTTP/2 Speed Demo: https://http2.akamai.com/demo
– HTTP/2 Standard: https://tools.ietf.org/html/rfc7540
– HTTP/2 Working Group: https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html
– QUIC Standard: https://tools.ietf.org/html/draft-ietf-quic-transport-09
– QUIC Working Group: https://datatracker.ietf.org/wg/quic/about/
HTTP/2 Useful Resources:
HTTP/2 + QUIC Useful Resources:
Huge repository of addresses from CISCO experts who liked this technology: