Why you should upgrade to HTTP/3

When you stop and think about it, it’s hard not to be blown away by the awesome complexity and unfathomable breadth of the web. By that same token, it’s easy to take for granted the intricate mesh of technologies that make the internet possible.

In this guide, we’ll focus on one of the internet’s foundational building blocks: HTTP. We’ll discuss exactly what it does and explain why you should upgrade to HTTP/3 if you haven’t already.

What is HTTP?

Put simply, HTTP is the protocol that enables you to access information and files from another web server.

HTTP stands for Hypertext Transfer Protocol, which is the set of rules that defines how webpages are delivered from server to browsers. It’s the same protocol that facilitates encryption.

According to Mozilla, “HTTP is a client-server protocol: requests are sent by one entity, the user-agent (or a proxy on behalf of it). Most of the time the user-agent may be a browser, but it is often anything, for instance, a robot that crawls the online to populate and maintain a search engine index.”

All this communication happens over TCP networks. TCP is a protocol that handles data delivery from one IP address to another. It covers both servers and clients.

A brief history of HTTP

If you’re familiar with the Open Systems Interconnections (OSI) specification, HTTP is an application-layer protocol, meaning it can be upgraded and improved with increasing bandwidth, etc. This has given rise to multiple versions of the protocol.

HTTP/1

The earliest version of HTTP features the following.

Browser-friendly protocol
Header fields that include rich metadata about both request and response (HTTP version number, status code, content type)
Response is not limited to hypertext; the Content-Type header enabled transmission of files in formats other than plain HTML (e.g., scripts, style sheets, media, etc.)
Support for GET, HEAD, and POST methods
Connection terminated immediately after the response

The main cause of latency within the HTTP/1 protocol is the head-of-line blocking problem. Webpages require multiple resources: CSS, JavaScript, fonts, images, AJAX/XMR, etc., which requires the browser to make multiple requests to the server. However, not all of those resources are required all the time, so all the extra loading can be a waste of time.

With HTTP/1.0, it was necessary for browsers to complete a request, including fully receiving the response, before starting the next request. This also results in increased load time for because everything had to be done in succession.

HTTP/1.1 tackled this issue by introducing pipelining, which enabled web browsers to start new requests without needing to wait for previous requests to complete. This helped accelerate load times over low-latency environments.

HTTP/2

The standard right now is HTTP 2, which uses TCP as its main protocol for communication.

With HTTP/2, multiple requests and responses can be transmitted over the same connection simultaneously. The downside is that all requests and responses can be affected by packet loss due to network congestion.

TCP delivers the entire stream of bytes from one endpoint to the other in the correct order. Occasionally, network or connection issues can result in lost or corrupted packets of bytes. TCP will attempt to fill a lost packet by resending the request. This single action can cause unnecessary delays in the process, which naturally affects the speed and performance of the communication. This, in essence, is the head-of-line blocking problem.

HTTP/3

HTTP/3 aims to eliminate the head-of-line blocking problem once and for all. Instead of using TCP as the transport layer for the communication, it introduces a brand new transport layer called Quick UDP Internet Connections (QUIC).

QUIC, which is encrypted by default, is designed to both accelerate and secure HTTP traffic. It aims to eventually replace TCP and TLS.

Cloudflare lists some advantages of using QUIC over traditional TCP and UDP, including:

Built-in security
No head-of-line blocking
QPACK, a new header compression scheme
Deflecting reflection
UDP performance

Combining QUIC and HTTP/3 promises to solve the head-of-line-blocking problem and address many other shortcomings associated with previous standards, ushering in a new era of performance on the web.

Over 200k developers use LogRocket to create better digital experiences

Learn more →

Why you should upgrade to HTTP/3

The benefits of switching from TCP to QUIC include but are not limited to:

Lower latency. A study by Google found that using QUIC accelerated search results by 3.6 percent and YouTube load time by 15 percent
Switching between networks has little to no effect on speed; with QUIC, that handover or renegotiate’ process is no longer necessary.
Handshake optimization. QUIC supports a single handshake on a connection instead of two or more, which increases the connection time for the communication
Multiplexing. QUIC addresses the head-of-line blocking problem
Forward error correction (FEC)
Improved congestion control. It’s not clear what’s the final option will be, but seems that it will be based on TCP NewReno

Now that you understand the basics of HTTP, the history of the protocol’s versions, and the QUIC protocol’s potential to improve performance, you should have the fundamental knowledge and motivation to switch over to HTTP/3.

Get set up with LogRocket's modern error tracking in minutes:

Visit https://logrocket.com/signup/ to get an app ID

Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not server-side

npm
Script tag

$ npm i --save logrocket 

// Code:

import LogRocket from 'logrocket'; 
LogRocket.init('app/id');

// Add to your HTML:

<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>