HTTP/3 and QUIC: what do they mean for the Web?

Ramón Saquete

Written by Ramón Saquete

In 2015 we announced the publication of the HTTP/2 standard. Only 5 years later we can already analyse the next implementation of the HTTP/3 and the QUIC protocol it’s built on. According to what Google says, it will improve performance between 8% and 15%.

HTTP/2 brought performance improvements with it, and the ability for the server to send unrequested files through server push, although it’s still hard to find hosting services allowing the latter.

HTTP/3 comes with improvements in terms of performance, which will have more impact on servers with higher latency, and on connections of lower quality 🚀Click To Tweet

Provided that it took 15 years to go from the HTTP/1.1 to the HTTP/2 standard definition, and only 5 or 6 years to go from HTTP/2 to HTTP/3, HTTP/2 doesn’t have enough time to entirely replace HTTP/1.1, meaning that those lagging behind will upgrade directly to HTTP/3. Among those we can include none other than Googlebot itself, which continues to index with HTTP/1.1 only, when it should have taken advantage of HTTP/2’s speed whenever the crawled website’s server allowed it.

The main reason why it should make this change is that many websites discarded the domain sharding optimisation technique, which is counterproductive with HTTP/2 and HTTP/3, but did make sense under HTTP/1.1.

In the following chart we can see that use of HTTP/2 still hasn’t reached 50%, its current growth being of approximately 10% per year:

Current HTTP/2 use chart
Current HTTP/2 usage statistics (source: W3Techs)

What is QUIC?

QUIC is an acronym for Quick UPD Internet Connections protocol, and it’s much more important than HTTP/3, as it breaks away from the Internet foundation by reinventing the TPC/IP layered architecture model, assuming all TCP transport layer functions, and TLS security layer functions. This is a radical change, because ever since Internet was invented in the 70s-80s, the only transport protocols have always been TCP and UDP.

For QUIC to be implemented without having to change all Internet network devices, it bases itself on the UPD transport protocol, although this doesn’t prevent the yet-unresolved QUIC traffic regulation problems, and they are precisely the main reason that this protocol remains in an experimental phase still. So, despite using UDP, many routers and firewalls will have to adapt to the new protocol.

How does it work?

Visually, the pile of protocols would look just as depicted in the image below, where we’ve assigned colours to each protocol’s different functions. This way we can see how QUIC takes on the following functions:

  • Security layer functions: it guarantees that no one modifies or sees the data, neither the identity of the company providing the service.
  • TCP transport layer functions: detection and correction of errors and congestion control.
  • Transport functions included in HTTP/2: HTTP/2 came with multiplexing functions and flow prioritisation, which are transport functions. With QUIC taking on these tasks, they’re removed from the HTTP/2, giving way to HTTP/3.
HTTP/1.1 HTTP/2 and HTTP/3 protocol pile
HTTP/1.1 HTTP/2 and HTTP/3 protocol pile

TCP is a connection-oriented protocol, making sure that data arrives to its destination error-free. UDP, on the other hand, is a transport protocol used for fast communication, without establishing connection, through which data can arrive with errors. The latter is used for video transmission, where receiving the live image is more important than the fact that a video frame may arrive partially corrupted. On a website, however, we need reliable data. So QUIC carries out TCP’s functions that UDP does not. Moreover, it does so in a more efficient manner, while getting reliable and secure data much faster. UDP’s function is to simply break down the information into packages, called datagrams.

In principle, QUIC is only going to be used with the HTTP/3 application protocol, but it is likely that other future application protocols will rely on QUIC.

Given that, in practice, HTTP/2 is obliged to work over TLS, it cannot be used if a website isn’t HTTPS. Same thing applies to HTTP/3, which is obliged to work over QUIC, and cannot be used on a website without HTTPS either.

Speed improvement with HTTP/3 and QUIC won’t be as remarkable as with the HTTP/1.1 to HTTP/2 upgrade, but it will be obvious in situations where transmission errors are commonplace, for example, with weak or unstable connections. This is very important, considering that mobile devices are the users’ preferred method of browsing, and we don’t always have the best network conditions. Let’s see its characteristics in detail:

QUIC protocol characteristics

  • Multiplexing and better error management: just as HTTP/2 allowed to send all web files multiplexed into one unique TCP connection, HTTP/3 permits sending various multiplexed files over QUIC, with one connection per file. With HTTP/2, a single error in a package discarded the remaining packages until the server retransferred the package with the error. With HTTP/3 and QUIC, however, packages can still be received, even if one of them is received with an error in it. This defect, which at times made HTTP/2 slower than HTTP/1.1 with a high error rate, doesn’t happen with HTTP/3.
  • QUIC prevents TCP’s slow boot, and controls network congestion better: the TCP protocol uses a sliding window algorithm to control the amount of data sent, avoiding network saturation. This algorithm initially increases the amount of data sent little by little, so the first bytes download slower. QUIC uses a more intelligent algorithm, without this slow boot.
  • QUIC uses the HTTP/2 priority mechanism, permitting us to have various flows with different priorities.
  • Less turnaround cycles and better network usage. As opposed to TCP, the server doesn’t need to wait to get package delivery confirmation from the client to send the next ones in line. When establishing an encrypted connection, it only requires one turnaround cycle, as apposed to TCP + TLS , which may require up to 3. Moreover, to establish several connections after establishing the first one, QUIC only needs a oneway trip. Because packages require less movement, the latency won’t affect them as much, so using a CDN will have a smaller room for improvement.
  • QUIC requires less CPU,  which results in some battery savings for mobile devices.
  • QUIC allows connection migrations: this permits reusing them when you get disconnected from a network and connect to another one. For example, when skipping from 4G to Wi-FI or from one Wi-Fi to another.

QUIC’s brief history

QUIC started to be developed by Jim Roskind from Google in 2012. At first, it used a proprietary encrypting solution and was made to work with a different HTTP/2 version that wasn’t the official one only. However, when it was presented as a draft in 2015 to IETF (the Internet Engineering Task Force defines Internet standards) and it started to be developed by a work team within it, its encryption was changed to the one used by TLS 1.3, and in theory it should now admit any application protocol. For that reason, the original version is now called gQUIC.

Throughout QUIC’s development, the specification has been called HTTP/2 over QUIC, even though in reality it wasn’t HTTP/2, but a different version of the protocol, which, besides delegating multiplexing to QUIC, redefines its syntax. And thus, ultimately it was renamed to HTTP/3, term often used to refer to the new HTTP protocol, as well as to QUIC.

Current use of HTTP/3

With regard to web services, Google implements it on YouTube, Gmail and the search engine. On Facebook it is only partially implemented.

With regard to hosting services: in that sense, the first ones to offer HTTP/3 are Cloud Flare’s CDN (in beta) and SiteGround hosting.

Internet browsers currently supporting it are Chromium, Firefox, Opera and Chrome. However, given that it is an experimental protocol, it isn’t activated by default in some of them.

For HTTP/3 to work both the client and the server need to have it enabled, and they need to have a compatible implementation of the protocol. Let’s remember that it’s experimental, and the specification is a draft that can change. This means that it wouldn’t be so weird if some client-server implementations weren’t compatible with each other.

How do I know if a website uses HTTP/3?

To check whether a website is using HTTP/3 you can resort to any of these online tools: HTTP/3 Test or HTTP/3 Check.

HTTP/3 check
HTTP/3 usage test

It can also be checked through browsers already supporting it.

HTTP/3 can be enabled in Chrome through chrome://flags/#enable-quic, in Opera through opera://flags/#enable-quic and in Firefox writing in the address bar about:config and then activating the network.http.http3.enabled property. Then, we will restart the browser and see in the network tab whether the client and the server are using the same HTTP/3 protocol version. The following screenshot of Firefox provides an example of it:

HTTP/3 check in Mozilla Firefox

 

Conclusion

HTTP/3 and QUIC are going to reduce the time we have to wait for websites to load, and when it finally becomes standardised, implementing it will become a priority to have it implemented, in order to provide our users with a good performance, as opposed to our competition. But, for the time being, we will have to wait until its implementation issues are solved, and until browsers and web services carry the definitive version.

Bibliography

Ramón Saquete
Autor: Ramón Saquete
Web developer at Human Level Communications online marketing agency. He's an expert in WPO, PHP development and MySQL databases.

Leave a comment

Your email address will not be published. Required fields are marked *