Akamai has acquired Guardicore to extend its Zero Trust solutions and help stop ransomware. Read more

Blog

RSS

A QUICk Introduction to HTTP/3

Written by

Javier Garza

April 14, 2020

Javier Garza is a developer advocate at Akamai Technologies where he helps the largest companies on the internet run fast and secure apps by leveraging web performance, security, and DevOps best practices. Javier has written many articles on HTTP/2 and web performance, and is the co-author of the O'Reilly Book, Learning HTTP/2. In 2018, Javier spoke at more than 20 developer-related events around the world, including well-known conferences like Velocity, AWS Re:Invent, and PerfMatters. His life's motto is: share what you learn, and learn what you don't. In his free time he enjoys challenging workouts and volunteering for nonprofits that support children and education.

HTTP/3 is the newest iteration of the HTTP protocol that improves web security and performance. The first in a three-part series, this blog will discuss the HTTP protocol timeline, QUIC revolution, how HTTP/3 differs from HTTP/2, and the ways you can benefit from HTTP/3. 

The HTTP protocol

HTTP protocol (also known as web protocol), powers most websites, mobile apps, and videos. It was created by Tim Berners-Lee at CERN in 1989, and has been enhanced over the years to keep up with the ever-changing World Wide Web. Each new version of the protocol provides features that improve the performance, usability, and security of the web. A timeline of the protocol’s evolution is shown in Figure 1.

Figure 1. HTTP protocol timeline. Although the IETF HTTP/3 draft started in 2016, HTTP/3 was officially coined in December 2018 with draft version 17 and has not been finalized as of this publication. See the IETF email archive for more details. Figure 1. HTTP protocol timeline. Although the IETF HTTP/3 draft started in 2016, HTTP/3 was officially coined in December 2018 with draft version 17 and has not been finalized as of this publication. See the IETF email archive for more details.

Currently, the web is a mixed bag of HTTP/1.1 and HTTP/2 adoption. Most well-known websites are running HTTP/2, while smaller websites and late adopters plan to migrate to HTTP/2 in the near future as it is relatively easy to implement. HTTP/2 is used by about 45% of websites and supported by all major web browsers. In contrast, HTTP/3 is only used by about 5% of websites now and not well-supported by web browsers yet.

HTTP/2 provides on average a 5% to 15% performance improvement on page load times. Moreover, the performance improvements of HTTP/2 are impacted by several factors that can be tweaked by developers and webmasters. For example, practices such as domain sharding, number of objects downloaded, and third-party domains. Other factors cannot be adjusted easily because they change with the client connection — such as packet loss or network latency — and are outside of your control.

In my research on HTTP/2, testing shows that the delivery of large objects over HTTP/2 can be slower than over HTTP/1.1 when there is packet loss. This is because HTTP/2 uses a single TCP connection, versus about six connections which most web browsers open over HTTP/1.1. In addition, the TCP congestion control algorithms reduce the TCP congestion window size, resulting in fewer bytes sent over the wire when using just one TCP connection. Read “Will HTTP/2 make my site faster?” for more details.

The solution to this problem is to use HTTP/2 over a different transport protocol that provides more efficient congestion control. That, in essence, is what HTTP/3 is: HTTP/2 over User Datagram Protocol (UDP)-based Quick UDP Internet Connections (QUIC). 

The QUIC revolution

QUIC is a transport layer protocol designed in 2012 by Jim Roskind at Google with the intention of reducing connection and transport latency as well as providing bandwidth estimation in each direction to avoid congestion. The initial QUIC implementation (now known as Google-QUIC, or gQUIC) garnered attention from the web performance community when Google shared performance results indicating that QUIC reduced latency of desktop Google Search responses by 8.0% and rebuffer rates of YouTube playbacks by 18.0%. 

The QUIC working group was established in 2016 to standardize the protocol within the Internet Engineering Task Force (IETF) and, in October 2018, the IETF's HTTP and QUIC Working Groups jointly decided to call the HTTP mapping over QUIC "HTTP/3" in advance of making it a worldwide standard. The IETF forked QUIC into what is known as the “IETF-QUIC (or iQUIC)” which bases its encryption and security on TLS 1.3 instead of the custom approach used by gQUIC.

Differences between HTTP/2 and HTTP/3

There are several differences between HTTP/2 and HTTP/3 (see “HTTP/3 Explained” for more details), but the main one is that HTTP/3 runs over a transport layer network protocol called QUIC that uses UDP as the transport layer protocol instead of TCP, resulting on performance and security improvements.

The table below shows some of the differences between HTTP/2 and HTTP/3:

Feature HTTP/2 HTTP/3
Header compression algorithm HPACK QPACK
Handshake protocol TCP + TLS iQUIC
Handshake negotiation At the certificate stage via ALPN=Application-Layer Protocol Negotiation (ALPN) protocol After certificate negotiation via “Alt-Svc:” HTTP response header  
HTTP scheme HTTP (not well adopted) / HTTPS HTTPS
Prioritization Yes No, although HTTP/3 streams can have a "PRIORITY" frame to implement it.

Why HTTP/3 matters

HTTP/3 is the newest iteration of the HTTP protocol that’s designed to address some of the limitations of HTTP/2 in order to improve both the security (HTTPS is required) and performance (thanks to iQUIC) of the HTTP protocol. Using HTTP/3 solves the TCP head-of-line blocking problem that was still present in HTTP/2, which should translate to perceived improvements for small, time-sensitive requests that are very common with API and mobile app traffic.

The main drawback of HTTP/3 today is high CPU usage both on the client and server sides — this consumption is more noticeable on the server side as most web servers monitor CPU and number of requests per second, while most clients do not. However, this overhead is expected to diminish over time as the technology evolves, just as when the web moved from HTTP to HTTPS. 

If you’re planning to implement HTTP/3, expect changes to come to the protocol until it is approved by the IETF. Until then, deploying it on Akamai will minimize rework as we continuously update the server-side code with new drafts of the protocol. 

In the next blog in this series, I will explain how you can enable HTTP/3 on the Akamai network. Stay tuned!

Learn more

Here are great resources you can read to learn more about HTTP/3:



Written by

Javier Garza

April 14, 2020

Javier Garza is a developer advocate at Akamai Technologies where he helps the largest companies on the internet run fast and secure apps by leveraging web performance, security, and DevOps best practices. Javier has written many articles on HTTP/2 and web performance, and is the co-author of the O'Reilly Book, Learning HTTP/2. In 2018, Javier spoke at more than 20 developer-related events around the world, including well-known conferences like Velocity, AWS Re:Invent, and PerfMatters. His life's motto is: share what you learn, and learn what you don't. In his free time he enjoys challenging workouts and volunteering for nonprofits that support children and education.