HTTP/3 Protocol — Performance and Security Implications

Web browsers use various protocols to deliver to users what they need. The best-known internet protocol is called HTTP. And just like any other technology, it is not immune to change. Read the article to learn about the HTTP protocol's history and compare its newest versions. 

HTTP overview

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web and is used to load web pages using hypertext links. HTTP is an application-layer protocol designed to transfer information between devices and runs on top of other layers of the network protocol stack. A typical flow over HTTP involves a client machine making a request to a server, which then sends a response message. 

HTTP, as such, is a stateless protocol. It does not require information about the user session for each request. However, if this is required, it’s typically achieved by the usage of HTTP Cookies. Currently, it is mostly used with the TLS (transport layer security) protocol, which provides confidentiality, integrity, and authentication mechanisms for HTTP - it’s often called HTTPS. 

HTTPS on the HTTP protocol level is exactly the same. The underlying TLS layer protects and encrypts the data - HTTP itself is not even aware of that. HTTP is used basically everywhere on the Internet - whether it is using web browsers, mobile applications, services, or machines talking to each other utilizing various APIs (for instance, REST APIs). Everybody uses it daily, almost all the time. 

If you want to learn more about APIs, check out our article: From Kubernetes Ingress to Kubernetess Gateway API.

On the protocol level itself, it consists of various different components that are used to exchange the actual data and metadata:

• HTTP Requests Methods (i.e. GET, POST, PUT, PATCH, DELETE)
• HTTP Headers (i.e. Cookie, XFF, Host, Content-Type, Connection)
• HTTP Response Codes  - numerical value indicating the status of the request ( i.e. 404 Not Found indicating that requested resource cannot be found on the server)

History of hypertext transfer protocol

Historically hypertext transfer protocol was developed in 1989 in CERN, which is currently named HTTP/0.9. However, it never got official RFC and is practically not used anymore due to a lack of modern transmission mechanisms, headers, methods, etc. Below, a list of official HTTP initial specification RFCs has been presented, highlighting the most important new features they have introduced to HTTP: 

• HTTP/1.0 - May 1996 - RFC 1945      

  • Support of HTTP Headers
  • Explicit Versioning
  • Support of HTTP Status Codes
  • Support of Content-Type header
  • New HTTP methods - POST and HEAD instead of just GET

• HTTP/1.1 - January 1997 - RFC 2068      

  • Introduction of persistence connections - multiple requests can be sent over a single connection
  • Mandatory Host Header - important for web-proxies routing
  • New HTTP Status code of 100 - Continue
  • New HTTP methods - PUT, PATCH, DELETE, CONNECT, TRACE, and OPTIONS
  • Support of various compression and decompression methods - Gzip mostly used

• HTTP/2.0 - May 2015 -  RFC 7540      

  • Support of requests multiplexing - introduction of HTTP streams - now requests/responses can be multiplexed and are not sequential
  • Support of request prioritization - for instance, CSS files should be sent before JS files
  • Automatic Gzip compression
  • HTTP Connection reset support - connection can be immediately reset if an error occurs on the HTTP level
  • Support of server push - the server can proactively push content back to the client without an explicit request for it.
  • Support of Header Compression (HPAK) - described in RFC 7541       

• HTTP/3.0 - June 2022 - RFC 9114      

  • Usage of QUIC protocol instead dxssof TCP/TLS stack - RFC 9000       

In June 2022, IETF (Internet Engineering Task Force) HTTP Group not only published HTTP/3 RFC 9114       but also decided to refine, clean up, and rebuild the HTTP RFCs structure. Also, some things have been decoupled from the HTTP standard and moved to their own RFC. The most up-to-date HTTP-related RFCs can be found below:

• HTTP Semantics - RFC 9110      

  • HTTP's overall architecture, common terminology, and shared protocol aspects, such as request and response message/doc/rfc9111s, methods, status codes, header and trailer fields, message content, representation data, content codings, and much more.

• HTTP Caching - RFC 9111      

  • HTTP caches and related header fields to control the behavior of response caching.

• HTTP/1.1 - RFC 9112      

• HTTP/2.0 - RFC 9113      

• QPAC - RFC 9204       

The most important HTTP-related RFC structure has been presented below:

Very quickly after the initial HTTP/1.0 release, users discovered that it was missing a lot of potential features and some optimizations could be made. Just half a year after the initial release, HTTP/1.1 was released to address those. Then it took 18 years to develop a new official HTTP/2 standard, mainly to address performance concerns and issues. 

However, during HTTP/2 deployment, it has been observed that heavy reliance on TCP (transmission control protocol) and TLS protocols (description of both are out-of-scope of this article) are becoming problematic to achieve even better performance and yet provide the same security level as TLS1.3 protocol. That's why in June 2022, after 7 years, the HTTP/3 protocol was introduced.

There are some minor tweaks in the hypertext transfer protocol itself. The biggest major change is dropping support for TCP/TLS stack and replacing it with a new internet protocol - the QUIC transport protocol.

Why? TCP protocol optimization and extensions for session establishment/round-trip reductions had a very slow adoption rate on the Internet scale, and it was never guaranteed that intermediate devices would understand particular TCP optimization/extension and, for instance, won’t decide to drop the traffic. For instance, TCP Fast Open (TFO) was introduced initially in 2012, and even at the end of 2022, not all vendors support it. Now let’s compare HTTP/2 with HTTP/3 protocols.

HTTP/2 vs. HTTP/3

Let’s start comparison by presenting a diagram comparing both protocols on high-level:

Fig.2: HTTP/2 and HTTP/3 stacks comparisonSource: Internet has just changed      

Now let’s discuss the differences:

• No changes on Layer 3 - IP stack remains the same; both IPv4 and IPv6 are supported

• At Layer 4-6, we see major differences:

  • UDP (User Datagram Protocol) replaced TCP protocol for packet forwarding (as most devices understand UDP)

  • QUIC:

    • replaced TCP for all TCP protocol capabilities like being connection-oriented, providing congestion control and avoidance, flow-control mechanisms, etc.
    • Integrates with TLS1.3 protocol and is responsible for encrypting/decrypting traffic

  • TLS layer is getting integrated with QUIC and provides key negotiation, authentication, and session resumption capabilities.

  • Stream Multiplexing mechanism is also moved from the HTTP layer to the QUIC layer

• At the HTTP layer more efficient QPACK header compression algorithm is being used, which can utilize QUIC protocol capabilities

• Most of the HTTP-level stack remains intact as it’s decoupled with HTTP Semantics RFC

As you can see, the biggest difference between HTTP/2 and HTTP/3 is the use of QUIC over UDP instead of TCP as a transport mechanism where the QUIC protocol integrates not only TCP typical functionality but also integrates TLS to provide security and stream multiplexing as well. It's worth mentioning that in QUIC implementation, usage of TLS is mandatory - so there is no plain-text HTTP anymore with HTTP/3. 

HTTP/3 vs. HTTP/2 - Performance considerations

• Head-of-Line Blocking removal

By moving stream multiplexing away from the HTTP layer and putting it on the QUIC transport layer, HOL Blocking situations might be less frequent - however, the mechanism has to be well implemented and doesn't work well all the time, especially in cases of burst traffic loss. It very much depends on particular multiplexing implementation on a web browser - Cloudflare has produced a nice video showing different browsing implementing different methods on HTTP/2 protocol, and differences can be drastic, as you can see here      .

HTTP/3 should make the process a little bit easier during a traffic loss situation by leveraging the QUIC protocol.

• 0-RTT session setup

The diagram below compares HTTP/2 with HTTP/3 by showing round-trip-times for an example flow between client and server:

Now with the TLS1.3 feature called 0-RTT Session Resumption, if we recently have talked with a particular web server, we can re-use the keys automatically and start transferring actual data with the initial session setup. For TCP, it will reduce RTT to 2, and for QUIC implementation just to one - below diagram shows the difference in best case scenario for TCP and QUIC:

Although we are benefiting from only saving one RTT when comparing TCP with QUIC, however, this might give huge advantages for satellite and long-distance connections

• Connection Migration

As QUIC protocol uses new fields called source and destination Circuit IDs (CIDs), it's now much easier to migrate from one connection to another without dropping the file transfer - for instance, connection can be easily migrated from Wi-Fi to 5G, and we can still re-use existing QUIC sessions. 

To sum up performance considerations - typically in modern urban areas - benefits from migrating from TCP+HTTP/2 over to QUIC+ HTTP/3 might not be so huge. However, less ideal connection conditions will become QUIC+HTTP/3 should behave better and provide better performance and reliability.

One more thing worth adding is TCP implementation stack typically occurs on an Operating System kernel which slows down the development and adoption of new TCP extensions and mechanisms a lot - now, with QUIC, that will be much more robust as it is user-space implementation.

Surely with time, more and more QUIC functionality will be moved to the OS level to make performance even better. Also smartNIC cards will be introduced off-loading some or all of QUIC functionality to the hardware level.

HTTP/2 vs HTTP/3 - Security considerations

There are two major security considerations with HTTP/3 vs HTTP/2:

• End-user-perspective:

From the end-user perspective, usage of HTTP/3 should be much more secure by default. Only TLS1.3 secure communication is supported at the moment - there is no plain-text implementation of HTTP/3 as QUIC doesn't allow it. All major web browsers support HTTP/3. Also, in HTTP/3, much less information is exposed into the network headers as opposed to HTTP/2 (which makes firewall implementations much trickier, but we will talk about that just in a minute).

Also, no real changes are required from an end-user perspective - all heavy lifting has to be done on the web servers side to support HTTP/3, and many companies already do, like Google and Facebook. Google services were using HTTP/2 over QUIC actually (if used with Chrome-based web browsers) even before RFC was finalized, so it was called http/2-over-quic and became just HTTP/3. 

• Man-in-the-middle perspective (Firewall TLS proxy)

All major next-generation firewalls  use a technique called TLS Proxy in order to be able to decrypt the TLS traffic - basically, the firewall becomes a man-in-the-middle device which is acting as a proxy - below image has been presented to illustrate this.

Fig.5: Firewall traditional TLS Proxy SolutionSource: PaloAlto Networks      

This approach doesn't work anymore with the QUIC protocol. There is no vendor supporting decrypting of QUIC protocol at the time of writing of this article, and there are many challenges - all NGFWs inspection modules have to be re-written to be able to support such features, which will certainly take a lot of time.

The additional issue is at the moment, there is no real way to effectively track such a connection - in theory, Destination Circuit ID sounds like a good choice; however, a client can change its Source Circuit ID at will during the active connection. On the other hand, on the Layer 4 level, it looks like regular User Datagram Protocol (UDP) packets with dynamic src-port and dst-port of 443. Opening such traffic could lead to initiating UDP punch-hole attacks via the firewall.

Here you can find an article about How to drop a packet in Linux in more ways than one.

To sum up, at the moment, the only recommendation from firewall vendors is to block quic protocol if you are not feeling secure using it (not being able to decrypt it):

• Either by using destination port udp/443 or via application signatures for quic - depends on the firewall vendor.

Fortunately enough, if quic connection cannot be established, then fallback to HTTP/2 over TCP will happen automatically, which then can be decrypted and inspected by firewalls. 

HTTP/2 vs HTTP/3 Usage Statistics

According to the Web Technologies Surveys, as of November 2022, around 42% of web traffic is HTTP/2 - HTTP/2 Usage Statistics       . However, since November 2021, the usage of it has been declining a little bit. 

Usage of HTTP/3 protocol, on the other hand, has been increasing since 2021 and reached 26% in November 2022 - also according to Web Technologies Surveys - HTTP/3 Usage Statistics      . 

Issues with QUIC and HTTP/3

As always, with new protocols, there are some drawbacks - with HTTP/3, it's certainly intermediate firewalls content inspection and decryption mechanisms which are incompatible with QUIC. As of the time of writing this article, there is no firewall vendor which supports HTTP/3 decryption and inspection. Organizations can decide to choose from two options:

• Allow usage of QUIC and be aware that if certain websites use HTTP/3 they will lose the ability to decrypt and inspect that traffic
• Block QUIC protocol on the firewall, either on the UDP level or application-id level (depending on the vendor) - that will cause all clients’ requests to fall back to regular HTTP/2 over the TCP layer.

Summary

First, as discussed in the “In history of HTTP protocol” section, HTTP/3 was needed mainly to introduce a more robust, flexible and modern transport-layer protocol - QUIC. QUIC protocol does not have to be used just with HTTP - there are new initiatives to use it with other protocols, such as DNS and SSH. 

The second major point is performance gains - if compared to the best possible implementation of HTTP/2+TCP+TLS1.3 (with 0-RTT), HTTP/3 still has one round-trip-time (RTT) advantage. On modern, fast, urbanized networks, that might not sound like a lot, but definitely, it's an improvement. Over slower networks and in traffic burst situations, it might save a couple of hundred milliseconds from loading a page/resource. Connection migration is also another benefit allowing especially mobile users to change connection methods and still be able to continue to download files or sustain existing connections.

Thirdly, QUIC is still very early in its development phase - Version 1 is focused on getting basic transport and security protocol done - more advanced features are yet to come and it will only get better and faster over time. As existing implementations are developed in user space instead of the OS-level kernel space, the development of new advanced features should be much quicker and easier to adopt, but also some of the QUIC features are already being moved to the OS kernel space, and also there are developments in moving QUIC features into the NIC as well - for example, QUIC Offloading onto NIC       so we can expect some QUIC accelerated hardware soon. 

Read our series about developing custom network functionality in SONiC.

Another important thing is that HTTP/3 is already widely deployed and used on the Internet. Biggest tech companies like Google, Meta, Microsoft, Akamai, Cloudflare, Fastly, F5, and Ericsson are already heavily using it and are providing most of the services over QUIC protocol as per IETF - QUIC Industry      . 

It is also easy to “turn it on” if you use any CDN network like Cloudflare or Fastly - both offering a convenient “flip the switch” option to enable HTTP/3. Also, more and more HTTP server implementations are supporting HTTP/3 like Apache, NGINX or node-js but not by default.

To sum up, using HTTP/3 as soon as possible might not be crucial at the moment. However, it would certainly be beneficial to get familiar with it and the implications it brings. Over time usage of HTTP/3 will certainly increase, and new features will be introduced. If you provide any services which can already greatly benefit from using HTTP/3, there is no reason not to do it. 

Further Reading

Below you will find a list of additional resources if you would like to do more in-depth learning of QUIC and HTTP/3:

HTTP/3 Explained - Daniel Stenberg      

HTTP/2 In Action - Barry Pollard      

CloudFlare Blog - Articles covering QUIC topics      

IIJ Blog - In-depth technical blog about QUIC