Select the G-Core Platform

G-Core Cloud and Edge Platform
Go to G-Core Cloud →
  • Edge Delivery (CDN)
  • DNS with failover
  • Global Cloud Instances
  • Managed Kubernetes
  • AI Infrastructure
  • Edge Security (DDOS+WAF)
  • FaaS
  • Streaming
  • Object Storage
  • ImageStack (Optimize and Resize)
  • Edge Compute (Coming soon)
G-Core Hosting
Go to G-Core Hosting →
  • VPS Hosting
  • Dedicated Servers
  • SSL Certificates

What is HTTP/3, and how is it different from HTTP/2?

What is HTTP/3?

HTTP/3 is the third and latest version of the HTTP protocol.

What is HTTP and how does HTTP work? HTTP (hypertext transfer protocol) is an application-layer protocol to transfer most data on the web. It is a set of rules and principles that define how to request, transfer, and process any content.

How does HTTP/3 work, and why do we need it?

Adopted in the mid-1990’s, the HTTP protocol was subsequently upgraded to HTTP/1.1. This new version was able to concurrently send multiple requests, send data in small portions and cache them, and serve multiple domains with the same IP address over a single Transmission Control Protocol (TCP) connection.

However, after about fifteen years, HTTP/1.1 eventually stopped meeting the growing demand of web services and users as it was unable to transfer data-intensive media content, adequately balance network load, or encrypt data securely.

In 2015, the next major upgrade was delivered—HTTP/2. Designed to eliminate the biggest drawbacks, this version improved the load rate and performance of web sites. However, HTTP/2 failed to fully solve the problems because of HTTP’s underlying TCP transport protocol.

The application protocols run on top of transport protocols, e.g., HTTP & HTTP/2 run over TCP. This transport protocol ensures reliable and well-ordered content delivery, yet does not meet user expectations for data transfer rates anymore. Theoretically, TCP could be upgraded, but having its new version implemented on all IP devices globally sounds challenging.

This problem was solved by another protocol—universal and reliable QUIC. Still, you cannot simply use HTTP/2 over this protocol because:

  • Data streams will overlap. HTTP/2 sends multiple data streams in a single connection, while QUIC handles its own streams. If combined, HTTP/2 + QUIC would work with two different stream abstractions (i.e. layers).
  • Network devices cannot identify or use this new protocol.

Luckily, QUIC runs over UDP—another popular transport protocol, which looks like a solution, once HTTP/2 is duly corrected.

Here is why UDP + HTTP/3 + QUIC together can reliably deliver data:

  • As a bare-bones transport protocol, UDP (User Datagram Protocol) handles destination port numbers only and ensures high data transfer rates.
  • QUIC establishes a connection using a complex system of handshakes. To make data transfer reliable, this protocol confirms that a packet is received and, if required, resends lost packets.
  • HTTP/3, which is an enhanced version of HTTP/2, uses QUIC’s data streams instead of its own stream logic.

Think of the Internet as a highway network, where high-speed cars (HTTP/3) hurry along a newly renovated highway (transport-layer UDP+QUIC), compared to trucks (HTTP/2) dragging across a country road (TCP).

Why is HTTP/3 better than HTTP/2, and what do users gain?

Still, was HTTP/3 worth implementing? In a nutshell, a vanilla HTTP/3 addresses all the HTTP/2 problems, for which features run poorly or which needed workarounds.

HTTP/3 runs over UDP with QUIC in between

With TCP that sends packets in strict order, HTTP/2 risks head-of-line (HOL) blocking for the application layer, which means that an entire stream must be reloaded even if a single packet is lost or corrupted.

HTTP/2, which supports stream multiplexing, can identify that different file fragments come from streams with different IDs. However, TCP can see only a string of bytes to send from a source to a destination address. If TCP is used to send three packets and the first one is lost, the protocol puts the other two packets on hold, which is the case of HOL blocking mentioned before.

From a web service perspective, the performance drops dramatically once a server-client or client-server stream encounters a slight inconsistency due to the HOL blocking.

Instead, UDP just sends packets to a destination address and doesn’t care if they are corrupted on the way. Multiplexing works differently: running over UDP and QUIC, HTTP/3 sends data slower but in multiple streams through a single channel. The batch integrity is checked at a higher layer. If some packets are lost, the protocol resends them to speed up load time.

What do users gain? Performance of web services soars. With HTTP/3, web sites are loaded faster and more smoothly. Even with a poor Internet connection, users no longer have to wait for a web page which first loads the text, then layout and background images, and finally video and ad banners.

A stable connection with a single handshake

A handshake is an exchange of special packets to open a connection between a client and server. You can think of it as a greeting:

— Hello! I’m client X.

— Hello, I verified you. What do you need?

Even with multiple handshakes to establish a connection between a website and client, HTTP/2 still requires more handshakes every time a file—picture or script—is loaded. A web page can take dozens of seconds to load if the network is slow, e.g. in case of an overloaded or unstable connection or a distant server.

Offering its cunningly designed QUIC protocol, HTTP/3 overcomes this problem with only one handshake. QUIC opens a session with a unique Connection ID for both a server and client to communicate uninterruptedly while needed. Moreover, the client can restore this session even if a physical connection is lost.

What do users gain? With fewer handshakes, website performance soars. Even reconnections do not interrupt your session.

For example, if a smartphone or notebook switches to a different network (between two Wi-Fi access points or between a Wi-Fi and mobile network) while delivering a video stream, the rendering will resume even without buffering. Before HTTP/3, you had to reload the web page or hopelessly wait until the video player reconnects. The same applies to website-based audio and video conferences, document download, or cloud services.

TLS is delivered by default

TLS provides data encryption, authentication, and integrity. Being optional in HTTP/2, TLS is embedded in QUIC, where it is not purely an encryption layer. TLS encrypts most payload and service data to mitigate the risks of tracking and attacking users, or stealing their data.

What do users gain? Essentially, data security improves as HTTP/3 never sends unencrypted data.

Summary: should we use HTTP/3?

All popular web browsers support HTTP/3 in their latest versions: Mozilla Firefox, Safari 14, Google Chrome, and other Chromium-based browsers.

Adapting your web services to HTTP/3 would be wise—your users will appreciate obviously better performance and user experience.

Because of being implemented eventually, many of the HTTP/3 benefits seem to smear the feeling of revolution. But, previous solutions were just workarounds—based on a custom or flawed off-the-shelf solution, almost every web site tried to bypass issues like failed downloads. Alternatively, some web sites added code into media players to support segmented video stream download—which is not a silver bullet. Now, even the vanilla HTTP/3 completely prevents such a resource waste.

The QUIC architecture is easily upgradable without having to adapt network equipment to all the improvements—for hardware, it is still the same old UDP. Therefore, HTTP/3 can get new features easier and faster and will someday be ready for a brand-new protocol.

Share this article

Subscribe to a useful newsletter

Favorable offers and important news once a month. No spam.