Author｜Alessandro Ghedini, Rustam Lalkaka
Translator｜Wang Qiang
Editor｜Wang Wenjing
The HTTP protocol has driven the development of the Web, starting with HTTP/0.9 in 1991, evolving to HTTP/1.1 in 1999, and standardized by the IETF (Internet Engineering Task Force). HTTP/1.1 has existed for a long time, but the ever-changing demands of the Web required a better protocol, leading to the emergence of HTTP/2 in 2015. At the end of last year, the IETF released the new version, HTTP/3. For some, this was a surprise, but it also left them a bit confused. To better understand the past, present, and future of HTTP/3, this latest article from the Cloudflare blog will guide you.
During last year’s “birthday week,” we announced preliminary support for the new web standard QUIC and HTTP/3 (then referred to as “HTTP over QUIC”), enabling faster, more reliable, and more secure connections to web endpoints such as websites and APIs. We also invited customers to join a waiting list so they could try QUIC and HTTP/3 as soon as it became available.
Since then, we have been collaborating with industry peers through the Internet Engineering Task Force (including Google Chrome and Mozilla Firefox) to iterate on the HTTP/3 and QUIC standard documents. As the standards become more refined, we are also working to improve network support.
We are excited to announce that Cloudflare’s edge network now supports QUIC and HTTP/3. We are thrilled to have worked with two leading browser vendors and partners, Google Chrome and Mozilla Firefox, to make this happen, creating a faster and more reliable internet for everyone.
In the words of Google Senior Software Engineer Ryan Hamilton, “HTTP/3 will improve everyone’s experience using the Web. The Chrome and Cloudflare teams have worked closely together to evolve HTTP/3 and QUIC from nascent standards to widely adopted web technology improvements. The strong partnership among industry leaders drives innovation in internet standards, and we look forward to continuing our collaboration.”
What does this mean for Cloudflare’s customers? You choose our services and edge network to make the Web faster and more secure. Once you enable HTTP/3 support for your domain in the Cloudflare dashboard, your customers can interact with your website and APIs using HTTP/3. We have been inviting customers in the HTTP/3 waiting list to enable this feature, and we will open it up to everyone in the coming weeks.
If you are an internet user interacting with websites and APIs through clients like browsers, what does this announcement mean for you? Starting today, you can use Chrome Canary to interact with Cloudflare and other servers via HTTP/3. If you prefer command-line clients, curl also provides support for HTTP/3. The following sections will explain how to use HTTP/3 with Chrome and curl.
Chickens and Eggs
Innovation in internet standards has always been a challenge, akin to the chicken or egg dilemma: does the server support the new standard first (like Cloudflare or its large response data sources), or do clients (like browsers and operating systems) support it first? Both ends of the connection need to support the new communication protocol to work properly.
Cloudflare has a long history of driving the evolution of web standards, from HTTP/2 (the version before HTTP/3) to TLS 1.3, and encrypted SNI, among others. We collaborate with like-minded organizations to push the evolution of standards, all of which share our desire to “help build a better internet.” Our efforts to bring HTTP/3 to the mainstream are no different.
Throughout the development of the HTTP/3 standard, we have worked closely with industry partners to establish and validate HTTP/3 client support compatible with our edge support. We are pleased to have collaborated with Google Chrome and curl, both of which can now make requests to the Cloudflare edge via HTTP/3. Mozilla Firefox is also expected to provide support for its nightly version.
In summary, today is a great day for internet users. The widespread adoption of HTTP/3 will bring a faster web experience for everyone, and the support work done today is a significant step in that direction.
More importantly, today is a good day for the internet: Chrome, curl, and Cloudflare, along with Mozilla soon, have rapidly rolled out experimental yet practical HTTP/3 support, indicating that the creation of internet standards is on the right track. Under the coordination of the Internet Engineering Task Force, industry partners, competitors, and other key stakeholders can work together to establish standards that benefit the entire internet, not just a few giants.
Firefox’s CTO Eric Rescorla provided a great summary: “Developing new web protocols is difficult, and getting them on track requires everyone’s collective effort. Over the past few years, we have been testing TLS 1.3 with Cloudflare and other industry partners, leading to the current HTTP/3 and QUIC. Cloudflare’s early server-side support for these protocols has helped us resolve interoperability issues in the client Firefox implementation. We look forward to these collaborations improving the security and performance of the internet together.”
Development History
Before delving into HTTP/3, let’s take a quick look at the evolution of HTTP over the years to better understand why the internet needs HTTP/3.
It all began with the release of the HTTP/1.0 specification in 1996, which defined the basic HTTP text connection format we know today (for the sake of discussion, I will pretend HTTP/0.9 does not exist). In HTTP/1.0, each request/response exchanged between the client and server creates a new TCP connection, meaning all TCP/TLS handshakes are completed before each request, resulting in delays for all requests.
Worse still, TCP does not send all outstanding data as soon as the connection is established; it requires a “slow start” warm-up time, allowing the TCP congestion control algorithm to determine how much data can be transmitted at any time, preventing congestion in the network path and avoiding overwhelming the network with unmanageable packets. However, since new connections must go through a slow start process, they cannot immediately utilize all available network bandwidth.
Years later, the HTTP specification’s HTTP/1.1 revision attempted to introduce the concept of “keep-alive” connections to address these issues, allowing clients to reuse TCP connections, thus sharing the costs of establishing the initial connection and the slow start for multiple requests. But this was not a panacea; although multiple requests could share the same connection, they still had to be serialized one by one, meaning that at any given time, the client and server could only perform one request/response exchange per connection.
As the web evolved, the resources required by websites (CSS, JavaScript, images, etc.) grew over the years, and browsers needed more concurrency to fetch and render web pages. However, since HTTP/1.1 only allowed a single HTTP request/response exchange at a time, the only way to gain concurrency at the network layer was to parallelize multiple TCP connections to the same origin, sacrificing most of the benefits of active connections. Although connections would still be reused to some extent (but not significantly), we were back to square one.
More than a decade later, SPDY and HTTP/2 finally emerged; the latter first introduced the concept of HTTP “streams”: an abstraction that allows HTTP implementations to concurrently multiplex different HTTP exchanges over the same TCP connection, enabling browsers to reuse TCP connections more efficiently.
But this was not a panacea either! HTTP/2 solved the initial problem of inefficient use of a single TCP connection—now multiple request/response exchanges could be transmitted simultaneously over the same connection. However, even if only a single request lost data, all requests and responses would be affected by packet loss (for example, due to network congestion). This is because, although the HTTP/2 layer can isolate different HTTP exchanges on different streams, TCP does not understand this abstraction and only sees a byte stream with no special meaning.
TCP’s role is to deliver the entire byte stream from one endpoint to another in the correct order. When a TCP packet carrying certain bytes is lost on the network path, it creates gaps in the stream, and TCP needs to retransmit the affected packets upon detecting the loss to fill this gap. In doing so, even if the data following the lost data belongs to completely different HTTP requests, which themselves have not lost any data and can be successfully transmitted, they still cannot be delivered to the application correctly. Thus, they can only unnecessarily introduce delays because TCP cannot know whether the application can handle the subsequent data when it is missing the lost packets. This problem is known as “head-of-line blocking.”
Understanding HTTP/3
This is where HTTP/3 comes into play: it does not use TCP as the transport layer for sessions but instead uses QUIC (a new internet transport protocol). This protocol introduces streams as first-class citizens at the transport layer. Multiple QUIC streams share the same QUIC connection, so there is no need for additional handshakes and slow starts to create new QUIC streams. However, QUIC streams are delivered independently, so in most cases, packet loss affecting one stream does not impact other streams. This is because QUIC packets are encapsulated in UDP datagrams.
Using UDP provides greater flexibility compared to TCP and allows QUIC implementations to exist entirely in user space—the protocol implementation updates do not rely on operating system updates like TCP. With QUIC, HTTP-level streams can be simply mapped to the top of QUIC streams, thus enjoying all the benefits of HTTP/2 while avoiding head-of-line blocking.
QUIC also combines the typical 3-way TCP handshake with the TLS 1.3 handshake. Combining these steps means encryption and authentication can be provided by default, and connections can be established more quickly. In other words, even if the initial request in an HTTP session requires a new QUIC connection, the waiting delay before data starts flowing is lower than that of TCP using TLS.
But why not use HTTP/2 over QUIC instead of creating an entirely new version of HTTP? After all, HTTP/2 still provides stream multiplexing capabilities. It turns out that doing so is much more complex than one might imagine.
It is indeed possible to easily map some HTTP/2 features onto QUIC, but not all features can be mapped in this way. In particular, a header compression scheme called HPACK in HTTP/2 relies heavily on the order in which different HTTP requests and responses are delivered to the endpoint. QUIC enforces the order of byte delivery within a single stream but does not guarantee the order between different streams.
This behavior necessitates the creation of a new HTTP header compression scheme called QPACK, which can solve the problem but requires changes to the HTTP mapping. Additionally, QUIC itself already provides certain features of HTTP/2 (such as stream control by stream), so we removed these features from HTTP/3 to eliminate unnecessary complexity in the protocol.
HTTP/3, Powered by Delicious Quiche
QUIC and HTTP/3 are exciting standards that promise to address many shortcomings of previous standards and usher in a new era of web performance. So how did we evolve from exciting standard documents to viable implementations?
Cloudflare’s QUIC and HTTP/3 support is powered by quiche, our own open-source implementation written in Rust.
You can find it on GitHub at github.com/cloudflare/quiche.
We released quiche a few months ago, adding support for the HTTP/3 protocol on top of existing QUIC support. Our design allows quiche to be used to implement HTTP/3 clients and servers or just for a regular QUIC server implementation.
How to Enable HTTP/3 for My Domain?
As mentioned above, we have started providing services to customers on the waiting list. If you are on the list and have received an email notification indicating that you can now enable this feature for your website, simply go to the Cloudflare dashboard and manually enable this switch from the “Network” tab:
We hope to make the HTTP/3 feature available to all customers in the near future. Once enabled, you can try HTTP/3 in various ways:
Using Google Chrome as an HTTP/3 Client
To connect to your website via HTTP/3 using the Chrome browser, you first need to download and install the latest Canary version, then launch Chrome Canary with the command-line parameters “–enable-quic” and “–quic-version=h3-23”.
After launching Chrome with the required parameters, simply enter your domain in the address bar and check if it loads via HTTP/3 (you can check the protocol version used in the “Network” tab of Chrome Developer Tools). Note that due to the way browsers and servers negotiate HTTP/3, HTTP/3 may not be used for the first few connections to the domain, so you should try reloading the page a few times.
If this seems too complicated, rest assured that over time, Chrome’s support for HTTP/3 will become more stable, and enabling HTTP/3 will become easier.
This is what the “Network” tab in Developer Tools shows when browsing this blog via HTTP/3:
Note that due to the experimental nature of Chrome’s support for HTTP/3, the protocol is actually identified in Developer Tools as “http2+quic/99”, but do not be misled; it is indeed HTTP/3.
Using curl
The curl command-line tool also supports the experimental HTTP/3 feature. You need to download the latest version from git and follow the instructions to enable HTTP/3 support.
https://github.com/curl/curl/blob/master/docs/HTTP3.md#quiche-version If you are running macOS, we can also easily install a curl version with HTTP/3 via Homebrew:
% brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rbTo perform HTTP/3 requests, all you need to do is add the “–http3” command-line flag to the regular curl command:
% ./curl -I https://blog.cloudflare.com/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 517b128df871bfe3-MANUsing the http3-client based on quiche
Finally, we also provide an example of an HTTP/3 command-line client built on quiche (as well as a command-line server) that you can use to try out HTTP/3.
https://github.com/cloudflare/quiche/blob/master/examples/http3-client.rs To run it, first clone the quiche GitHub repository:
$ git clone --recursive https://github.com/cloudflare/quicheThen build it. First, you need a working Rust and Cargo environment (we recommend using rustup to easily set up a proper Rust development environment).
$ cargo build --examplesFinally, you can execute HTTP/3 requests:
$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/What’s Next?
In the coming months, we will focus on improving and optimizing our QUIC and HTTP/3 implementations, ultimately making this new feature available to everyone without waiting in line. As the standards evolve, we will continue to update our implementations, potentially introducing significant updates as drafts evolve into standards.
Here are some particularly exciting features on our roadmap:
Connection Migration
A significant feature brought by QUIC is the ability to seamlessly and transparently migrate connections between different networks (for example, from your home WiFi network to your carrier’s mobile network when you go to work) without creating a brand new connection.
This feature requires some additional changes to our infrastructure, but we are very much looking forward to providing this improvement to customers in the future.
Zero Round Trip Time Resumption
Like TLS 1.3, QUIC supports an operational mode that allows clients to start sending HTTP requests before the connection handshake is complete. We have not yet supported this feature in QUIC deployments, but just as we did with TLS 1.3 support, we will strive to implement this improvement.
HTTP/3 is Here!
We are excited to support HTTP/3 and allow customers to experiment with QUIC and HTTP/3 during the standardization phase. We will continue to collaborate with other organizations (including Google and Mozilla) to finalize the QUIC and HTTP/3 standards and encourage widespread adoption in the industry.
HTTP/3 will provide everyone with a faster, more reliable, and more secure web experience.
Original English Version: https://blog.cloudflare.com/http3-the-past-present-and-future/