The Evolution of HTTP: A Developer's Guide from HTTP/1.1 to HTTP/3 and QUIC

Earlier Versions of HTTP

HTTP 2.0 (2015)

HTTP 2.0 brought a lot of major improvements that saw websites reporting 30-40% faster loading times. So many tricks that developers employed prior, to take advantage of parallelism through multiple connections (like css and image-sprites) were also no longer needed.

1. Multiplexing—not only the orders need not be processed sequentially, the server can also process them simultaneously. The client can place multiple requests on a single connection, the server can process them parallely and return them in any order, even in chunks, as they are completed. The HTTP/2 would label those chunks so that it can reassemble them all in the correct order before finally delivering it to the client.
2. Server Push—The server can push certain types of files automatically without the client requesting them. For example, if an html file is requested, the server knows the browser will eventually request the linked css file as well.

Another significant change it brought was the implementation of binary data exchange (instead of text). This made the raw data less human readable but more efficient for the machines to parse.

The new design elegantly solved the problem of the HOL blocking, but at the server (application) level. The TCP delivery guy is still adamant to deliver the responses in the correct order only. If any response packet goes missing, it blocks delivering the "subsequent" ones as well until the server resends the missing packet. Thus the same problem of HOL blocking still persisted, but at the TCP level.

The TCP was intentionally designed this way—to ensure and deliver "every" response in the order they were requested. And it actually made sense back then, you do not want to get a css or a font file without an html or a text, it would be useless.

Another problem that emerged with the TCP design was the need for extra "handshakes" so that the TLS (Transport Layer Security) protocol (HTTPS) can be implemented over it.

The TLS implementation, now non-negotiable to protect user data and privacy, requires creation and exchange of cryptographic keys between the client and the server, so that the data can be encrypted, transmitted and decrypted at both ends. The entire process results in, at the very least 2 extra round trips before even a single byte of request (or response) can be exchanged.

Thus, while HTTP/2.0 improved server application architecture, challenges persisted within the communication channel, TCP itself. The bottleneck inherent in TCP's design led to its removal in HTTP/3.0, which instead introduced an entirely new communication channel called QUIC.

Nonetheless, around 65% of active websites today still employ HTTP 1.1 and 2.0 which are built over TCP.

How to Upgrade the HTTP Version of Your Website

Most modern websites are hosted on servers where the hosting service would already be running at least HTTP/2. However, this last-year data from HTTP Archive suggests a good ~20% of websites still running HTTP/1.1, so encountering one is not uncommon.

Upgrading to HTTP/3 directly from the endpoint or origin is complex. The simplest approach is to utilize a Content Delivery Network (CDN). Most widely used CDNs, including those offered by hosting providers, typically enable HTTP/3 by default.

When you read claims that 30-35% of websites use HTTP/3, excluding major entities like Google, Amazon, and the CDNs themselves, a significant portion of these websites implement HTTP/3 through CDNs or edge servers, rather than directly from their own origin server. The communication with the origin still runs on HTTP/2 or 1.1.

The reason for that is, as of this writing, except for Nginx, there is no support for HTTP/3 with other server frameworks—Apache, Node/Express, Django etc. Though Django does have a third-party library support, check django-http3.

Still, if you wish to implement settings explicitly (like on unmanaged platforms), there are configuration text files you have to tweak.

server {
    listen 443 ssl http2;
    server_name example.com;
      
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/private-key.pem;
      
    # Optimize
    http2_max_field_size 16k;
    http2_max_header_size 32k;
      
    # Enable compression
    gzip on;
    gzip_vary on;
    gzip_types text/css application/javascript;
      
    location / {
        root /var/www/html;
        index index.html;
    }
}

server {
    listen 443 ssl http2;
    listen 443 quic reuseport;
      
    server_name example.com;
      
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/private-key.pem;
    ssl_protocols TLSv1.3;
      
    # announce
    add_header Alt-Svc 'h3=":443"; ma=86400';
      
    # QUIC-specific settings
    ssl_early_data on;
    quic_retry on;
}

LoadModule http2_module modules/mod_http2.so

<VirtualHost *:443>
    ServerName example.com
      
    SSLEngine on
    SSLCertificateFile /path/to/certificate.pem
    SSLCertificateKeyFile /path/to/private-key.pem
      
    # Enable HTTP/2
    Protocols h2 http/1.1
      
    # Optimize settings
    H2Push on
    H2PushPriority * after
    H2PushPriority text/css before
    H2PushPriority application/javascript interleaved
</VirtualHost>

const http2 = require('http2');
const fs = require('fs');

const server = http2.createSecureServer({
    key: fs.readFileSync('private-key.pem'),
    cert: fs.readFileSync('certificate.pem')
});

server.on('stream', (stream, headers) => {
    if (headers[':method'] === 'GET') {
        stream.respond({
            'content-type': 'text/html',
            ':status': 200
        });
          
       //... other response data
    }
});

server.listen(443);

How to Test & Evaluate Performance Yourself

It is important to see in numbers how much performance % is improved on different HTTP versions. Fortunately, testing this is pretty simple. You can perform a detailed test on any website, including your own, using just the browser developer tools.

Here are the detailed steps (I'll be using Google Chrome)—

1. Copy the url of the website you want to test. Preferably one that runs fully on HTTP/3 (from origin). I'm using Cloudfare's homepage for this — https://www.cloudflare.com/en-in/
2. Go to developer tools > network and "disable cache" at the top. If you're testing some other website that employs service workers, then you need to disable the cache loading from there as well. Go to the application tab and check "Bypass for network".
3. Close all instances of your browser. Open command terminal and run the command:

   start chrome --disable-quic --disable-http2 --incognito https://www.cloudflare.com/en-in/

   The above command will open that url in the chrome's incognito mode and since both http/3 (quic) and http/2 are disabled, it will load the webpage using http/1.1.

4. Open developer tools again, click the network tab. Right click on any tab (Name, Status etc.) and check protocol. Reload the page again. You'll see resources loading one-by-one with http/1.1.
5. Note the performance of these important metrics—
   • DOMContentLoaded time at the bottom
   • Click on the homepage's document (most likely the 1st one in the list), go to the timing tab and note the time for Initial connection (this is the time to complete the server-client handshake). Note the waiting time as well, the TTFB (time to first byte) is the sum of waiting and handshake times.
   • Click on the performance tab at the top and note the LCP (Largest Contentful Paint).
6. Repeat the steps 3,4 and 5 for HTTP/2 and HTTP/3 as well.
   • Disable only quic to run HTTP/2:

     start chrome --disable-quic --incognito https://www.cloudflare.com/en-in/

   • For HTTP/3:

     start chrome --incognito https://www.cloudflare.com/en-in/

Here are my test results:

I tested many websites (including my own) while writing this article and in many cases, the HTTP/1.1 outperformed HTTP/2! This is not to say, you should give HTTP/1.1 a try. Ideally it should underperform. What this suggests however is the HTTP/2 on those servers is not optimised.

It does tell us an important thing—a poorly optimised configuration will not give the results we expect just by upgrading HTTP.

Conclusion

The easiest way to upgrade to HTTP/3 is currently through a CDN like Cloudflare or BunnyCDN. While this might not offer full HTTP/3 from your server's origin, using a CDN is adequate and provides better security. Another option is a solution from your hosting provider; however, it's recommended to test websites that already use those CDNs (for example, your hosting provider's homepage).