Introducing QUIC for Web Content

October 10, 2018 · by Medhat Yakan and Akhil Jayaprakash ·

Most web content is served over the true and trusted TCP protocol. However, TCP is not without its faults, especially when it comes to performance. Enter QUIC, a new protocol which promises to provide better performance than TCP in certain conditions.

QUIC, short for Quick UDP Internet Connections, is an experimental transport layer network protocol which provides security comparable to TLS/SSL with lower connection and transport latency. What’s different about QUIC is that it supports a set of multiplexed connections between two peers over UDP. QUIC also includes bidirectional bandwidth estimation that is used in the congestion control mechanism, which is implemented in user space rather than in the kernel space. This allows for more rapid iteration and updates.

We initially enabled QUIC for our video delivery products, today we’re expanding this support to secure web applications, APIs, and images too.

Although QUIC support is not universally supported in browsers or servers, adoption is skyrocketing. Akamai enabled QUIC on Media products starting in March 2018, and as you can see from the graph below, the number of IPv4 addresses that are capable of speaking QUIC has increased drastically (as observed by Jan Ruth).



There are several implementations of QUIC. The Chrome browser has QUIC support which uses Google’s own QUIC implementation (gQUIC). The IETF currently has a QUIC Working Group that is working on creating a unified QUIC specification. Akamai is supporting gQUIC vs IETF QUIC, with plans to migrate to IETF QUIC once the standard is ratified. Our decision to provide gQUIC support is to empower our customers with a usable technology that they can test in the real world with real users and observe the benefits of it.

Quicker than QUIC?

So how much faster is QUIC? Google published a paper about QUIC performance on their search pages across both desktop and mobile. They looked at the time it took from the point where a user enters a search term up until all the search-result content is generated, referring to this time as search latency. Based on the data collected over a billion samples, Google saw search latency reduce by 8% across desktop devices, and a 16.7% decrease in search latency for the 99th percentile.


Caption: Google search latency reduction while using QUIC


A Note on PCI Compliance and SNI-only clients

One of the challenges with providing QUIC support is the lack of PCI compliance. Akamai will initially be offering QUIC in an opt-in tech preview. If you opt in, you need to ensure that you do not enable it on sites that require PCI compliance.

The main reason behind that is because QUIC is still in development, and it’s difficult and resource intensive to maintain a PCI compliance during the development lifecycle for the SDLC and the evolving crypto implementation. These issues will naturally go away once the IETF QUIC implementation is finalized.

As of this writing, majority of browsers in the market supports server name indication during the SSL handshake process. Our QUIC offering only works on certificates that entertain SNI-only connections from clients.

Validating QUIC Performance with mPulse

You can validate QUIC performance improvement using the mPulse dashboard. For example, you can use the protocol field in the Page Construction dashboard dropdown to show performance metrics with and without QUIC. Naturally, you need to have mPulse behavior added in Luna in your properties, and also have boomerang version 1.571 or higher. The following is an example:

Perceived Performance with QUIC  protocol filter selected:


If you decide to enable QUIC only on selected resources/scopes of your website (e.g. static resources such as images or CSS or specific subpages), you’d need to do appropriate value confirmation using mPulse data for those resources/scopes and not for the main page.

The Gritty Details - How QUIC Connections are Established

If you’ve read this far, you might be interested in how QUIC connections are established.

  1. A client, typically an end user’s browser, makes a request using HTTPS over TCP/TLS.

  2. The origin server, or the edge server in case of a CDN, terminates the TCP connection. If QUIC support is enabled, it respond to the HTTP request and includes an alternative services header “Alt-svc”. The “Alt-svc” header contains an indication that QUIC is supported by the server along with the QUIC versions the server supports and a max-age “ma” for the Alt-svc which is the equivalent of a TTL. For example:  alt-svc: quic=":443"; v="41,39,38,37,35"; ma=3600

  3. When the client detects the Alt-svc header, it will cache it for the specified “ma”. E.g. in Chrome, you can check the cached Alternate Service Mappings via chrome://net-internals/#alt-svc.

  4. If an Alternate Service Mappings record exists on the client for the target origin, it will attempt to use QUIC to establish a connection to the server on subsequent requests (e.g. when reloading the page or navigating to another same-origin link). Successful QUIC connection can be identified by the presence of “http/2” and “quic/<version>” in the protocol field. E.g. In Chrome, QUIC connections can be seen identified via chrome://net-internals/#quic or via the protocol field under the Network pane in the dev console would display something like in the following image: 


  5. When the “Alt-svc” timer expires, the client will revert to using TCP until the process repeats.

Product Availability

Akamai initially enabled QUIC on Media products, but has expanded support to the following: Ion Premier, Ion Media Advanced, Ion Standard, Dynamic Site Accelerator, Rich Media Accelerator and Dynamic Site Delivery.

Additional Resources

- If you’re interested in where QUIC is headed, check out the working group

- Interested in learning how servers can inform clients about what protocols to use, check out the RFC for Alt-svc

QUIC, a multiplexed stream transport over UDP - The Chromium Projects