Enabling HTTP/3 for Fastly services

This guide describes how to enable QUIC and HTTP/3 on your Fastly services. In summary, you must create a dedicated testing service, configure that testing service to offer HTTP/3, move your test domains to the HTTP/3-enabled Fastly IP addresses, and then start sending your HTTP/3 test traffic to Fastly.

About QUIC and HTTP/3 implemented at Fastly

QUIC is a new web transport protocol that, when used with the Hypertext Transfer Protocol (HTTP) to deliver web content, will be officially designated as HTTP/3. Both QUIC and HTTP/3 are in the process of becoming IETF standards. Although the IETF standards are still undergoing revisions as part of the IETF standardization process and new drafts are being released periodically, Fastly has implemented QUIC and HTTP/3 support of end user connections for the purposes of limited customer testing.

During the IETF standardization process, we plan to align HTTP/3 IETF draft version support with the Chrome browser until the final draft of the protocol is available. To accommodate a wide variety of web clients and their various releases, we will support two IETF draft versions at any given time: the newest draft version supported by Chrome Canary and the draft previously supported by Chrome browsers.

Keep in mind that Fastly currently only supports HTTP/3 for end user connections, as that is where we expect the primary benefits of these new protocols will be seen. While we investigate future uses for HTTP/3 in backend connections, connections to origin servers from Fastly will continue using HTTP/1.1.

Prerequisites

To use QUIC and HTTP/3 on Fastly’s edge cloud services, you will need:

Enabling HTTP/3 for Fastly services

To enable HTTP/3 for Fastly services, follow these steps.

Creating a Fastly service for testing HTTP/3

Like HTTP/2, HTTP/3 allows clients to reuse connections between different domains as long as the domains are on the same TLS certificate, a mechanism sometimes referred to as connection coalescing. To restrict your HTTP/3 testing to a subset of your domains being served by Fastly and guarantee your intended domain separation will be honored by end user clients:

  • create a new Fastly service specifically dedicated to the domains with which you will be testing HTTP/3.
  • configure that dedicated test service to support HTTPS for end user connections. You can use any of the Fastly TLS service options to complete this.
  • use a unique and valid TLS certificate dedicated only to the domains you will be using for HTTP/3 testing.

Sending your HTTP/3 traffic to Fastly

Unless you use Fastly's dedicated IP addresses, then as a final step to enabling HTTP/3, you must update the DNS records of your HTTP/3 test domains so requests to them are routed to your Fastly HTTP/3 test service.

0RTT enabled? IPv4 and IPv6 dual stack routing IPv4-only routing
Yes dualstack.n.sni.global.fastly.net n.sni.global.fastly.net
No dualstack.m.sni.global.fastly.net m.sni.global.fastly.net

Configuring your Fastly service to offer HTTP/3

HTTP/3 is designed as an optional upgrade to end user client connections. This means that end user clients will initially connect to your Fastly service using an earlier version of HTTP and will only attempt to use HTTP/3 if the Fastly server offers it via the HTTP Alternative Services (Alt-Svc) response header. The Alt-Svc header value must identify an IETF draft version supported by both the Fastly server and the client for the client to successfully upgrade to HTTP/3. As part of our HTTP/3 implementation, Fastly has created a new VCL function, h3.alt_svc(), which will automatically add the Alt-Svc response header and the appropriate header values when configured on a Fastly service.

To add the Alt-Svc response header with an HTTP/3 offer to your Fastly test service, follow the instructions in our guide to using regular VCL Snippets with the following values:

  • In the Name field, enter a descriptive name that will help you recognize this header addition rule (for example, HTTP3 offer).
  • From the Type controls, select within subroutine.
  • From the Select subroutine menu, select recv (vcl_recv).
  • In the VCL field, enter h3.alt_svc();.

If you use custom VCL to configure your Fastly services, you can add the following VCL in the vcl_recv subroutine to add the Alt-Svc header for HTTP/3:

h3.alt_svc();

Testing client compatibility with your Fastly test service

To test that your Fastly service is configured to serve HTTP/3 properly, make a request to your HTTP/3 test content from a client that supports HTTP/3 and is configured to use it. Check your test client’s documentation to determine which IETF draft versions it supports and how to enable HTTP/3. Even though a growing number of publicly available browsers support HTTP/3, Fastly recommends using the Google Chrome browser for HTTP/3 testing with your Fastly services if you are not developing your own client.

Fastly has created a publicly available HTTP/3 test page to verify that your test client is properly configured to support HTTP/3. Using the test client, navigate to https://http3.is and the resulting page will let you know whether or not HTTP/3 was successfully used to request the page. If the request did not use HTTP/3, the page will also let you know which IETF draft versions are currently being used by Fastly. You can use that information to update your client or client configurations to use one of those supported versions.

Keep in mind that even if correctly configured, the first request from a browser (or its first request after a time-out period set by the browser’s developers) to any HTTP/3 enabled web site will always use a lower version of HTTP because it has not yet seen the Alt-Svc HTTP/3 offer. If you don't see the HTTP/3 success page on your first request, be sure to perform a reload in the browser to give it an opportunity to use HTTP/3 for subsequent requests.

Serving HTTP/3 traffic

Once you’ve configured your services appropriately, requests made to the domains on those services should be capable of supporting QUIC and HTTP/3 if they are being made from a client that supports these protocols.

The QUIC and HTTP/3 protocols provide optional upgraded connections to clients, which means that even HTTP/3-capable clients will initially connect on the standard TCP port 443 using HTTP/1.1 or HTTP/2 with TLS for security. HTTP/3-capable clients making their initial connections will see the HTTP/3 offer in the Alt-Svc response header from Fastly and then attempt the same requests by setting up QUIC connections and using HTTP/3.

If the QUIC connections and HTTP/3 requests are successful, the clients will continue using them for all subsequent requests and connections for those domains. Should problems occur with the QUIC connections or HTTP/3 requests, clients are expected to automatically fall back to a standard HTTP/1.1 or HTTP/2 connection over TCP. You should verify that your chosen test client implements this fallback if this is a priority for you.

Monitoring your HTTP/3 traffic

You can monitor HTTP/3 requests using Fastly’s Real-Time Log Streaming feature and the Historic stats. We have added the following HTTP/3 and QUIC related variables to the connection-related logging variables:

Disabling QUIC and HTTP/3

You can disable HTTP/3 support on a Fastly service by either activating a previous service version that does not include the Alt-Svc header configuration or by creating a new service configuration version and deleting the Alt-Svc header before activation.

Back to Top