This guide describes how to enable QUIC and HTTP/3 on your Fastly services.
IMPORTANT: This feature is part of a beta release. For more information, see our product and feature lifecycle descriptions.
About QUIC and HTTP/3
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 not yet ratified and may still undergo minor changes, Fastly has implemented QUIC and HTTP/3 support of end user connections for the purposes of limited customer beta testing.
To use QUIC and HTTP/3 on Fastly’s edge cloud services, you will need:
- a Fastly user account assigned the role of superuser
- relevant domains you will be using to test HTTP/3 added to a properly configured Fastly service
- access privileges to modify DNS records for the domains you will be using
- a client with the ability to generate QUIC and HTTP/3 end user requests to your Fastly services that is compliant with the latest IETF drafts
Moving your domains to QUIC-enabled Fastly IP addresses
Fastly currently restricts which end user requests will be allowed to connect to our edge cloud services using HTTP/3 to a subset of Fastly’s IP addresses.
Once you’ve identified the domain names to be used for beta testing HTTP/3 and then added them in the Fastly services you’ll use for testing, email email@example.com and request that the domains be hosted on HTTP/3-enabled Fastly IP addresses. Be sure to list the exact domain names in the support ticket as they appear in the Fastly service configurations.
When the support request is completed, Fastly support will provide you with a hostname to use when updating the CNAME record for your domains with your DNS provider. Once you update your DNS provider’s CNAME records with the hostname provided by Fastly, end user requests to the domains will start connecting to Fastly on the HTTP/3-enabled IP addresses.
Configuring your Fastly service to offer HTTP/3
Once your domains begin using the HTTP/3-enabled Fastly IP addresses, you must configure the Fastly service you will be using for HTTP/3 testing to offer the new protocols to end user clients. The HTTP/3 protocol is offered via the alt-svc header in the HTTP responses to end user client connection requests. Because the actual value used in this header may change as both the QUIC and HTTP/3 protocols become finalized standards, Fastly has created a function that will automatically fill in the appropriate alt-svc header values for you.
To add the alt-svc header with the correct value for HTTP/3 traffic, configure your Fastly test service by following the instructions in our guide to Adding or modifying headers on HTTP requests and responses using the following values:
- In the Name field, enter a descriptive name that will help you recognize this header addition rule.
- From the Type menu, select Response and from the Action menu select Set.
- In the Destination field, enter
- In the Source field, enter
- Leave the Ignore if set menu set to the default value, No.
- Leave the Priority field set to the default value.
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. In addition to the existing connection-related logging variables, Fastly provides the following new HTTP/3-related VCL variables:
||Whether or not this was an HTTP/3 request.|
||Whether or not this was an HTTP/3 push request.|
Disabling QUIC and HTTP/3
You can temporarily disable QUIC and HTTP/3 support on the service by either activating a previous version of the service configuration that does not include the alt-svc header or by creating a new service configuration version and deleting the alt-svc header before activation.
To permanently disable the QUIC capability of a service or a domain, revert your DNS records to the previous (non-QUIC) CNAME records.
Fastly contributes to an open source H2O client that can provide detailed logs of its interaction with Fastly’s QUIC and HTTP/3 beta services. Fastly recommends beta participants use this client to provide logs to Fastly when requested to facilitate troubleshooting. Check out the client from its source repository following these steps:
- Clone https://github.com/h2o/h2o.
- Check out the
Compile it by entering the following command in any terminal application:
cmake . && make -j $(nprocs).
You should now have a binary file named
Make a request with the client and have it generate logs of the request by typing the following command in any terminal application:
./h2o-httpclient -3 -E quic.log <URL OF REQUEST>