Author: Sreeni Tellakula
Translator: Wang Kunxiang
Editor: Wan Jia
During last year’s Cloudflare birthday week, we announced the initial support for the next-generation protocol HTTP/3, which is based on HTTP/2. Our goal is to work towards building a better internet. Collaboration in standard-setting is crucial, and we are honored to be involved in the standardization process.
Although HTTP/3 is still in draft status, there is significant interest from users. As of now, over 113,000 domains have activated HTTP/3, and if you are using an experimental browser, you can access these sites using the new protocol! It is encouraging to see so many users enabling HTTP/3.
In collaboration with Google, we initiated support for HTTP/3, while Google also launched experimental support for HTTP/3 in Google Chrome. Since then, we have seen more and more browsers adding experimental support for HTTP/3, such as the Nightly version of Firefox and other Chromium-based browsers like Opera, Edge, and the technical preview of Safari.
Current Status of HTTP/3 Development
The IETF standardization process develops the protocol into a series of draft documents, aiming to determine the final version and publish an RFC based on that version. Members of the QUIC working group collaborate on analyzing, implementing, and inter-operating specifications to identify issues promptly and optimize the protocol.
We currently support Draft-23 of HTTP/3, and we will continue to follow and adapt to future draft versions. As of this writing, the latest draft version number is 27. With each draft version update, the quality of the QUIC protocol content improves to ensure that the protocol content maintains a “basic consensus” with its performance. To avoid stagnation in the analysis of upgrades during the iterative development of the protocol, or endless adjustments due to changes, the threshold for proposing modifications to existing specifications has been raised with each new draft. This means that changes between versions are smaller, and the final RFC should closely relate to the protocol we are currently running in production, with minimal differences.
Advantages of HTTP/3
One of the main advantages of HTTP/3 is the performance improvement, especially when fetching multiple objects simultaneously. With HTTP/2, any interruption in the TCP connection (packet loss) blocks all data streams (Head of Line Blocking). Since HTTP/3 is based on the UDP protocol, if a packet is lost, only one data stream is interrupted, not all streams.
Additionally, HTTP/3 provides 0-RTT support, which means that by eliminating the TLS handshake with the server during connection establishment, subsequent connections can start faster. Compared to using a full TLS negotiation, the client can start requesting data more quickly, allowing the website to begin loading sooner.
The following diagram illustrates the packet loss situation and its impact when multiplexing two requests with HTTP/2. The client sends requests to the server via HTTP/2, requesting two resources (we color the requests and their associated responses green and yellow). The responses are broken down into multiple packets, but unfortunately, if one packet is lost, both requests will fail to respond.
The above shows the situation of multiplexing two requests using the HTTP/3 protocol. When a yellow response packet is lost, it only affects the response of the yellow packet and does not impact the response represented by the green packet.
The improvement in session startup means that the “connection” startup speed with the server is faster, allowing the browser to fetch data more quickly. We were curious about how significant the improvement was, so we conducted some tests. To measure the improvement brought by 0-RTT support, we ran some benchmarks to measure the time to first byte (TTFB). On average, using HTTP/3, we received the first byte after 176ms. With HTTP/2, this time was 201ms, indicating a performance improvement of 12.4% for HTTP/3!
Interestingly, not every aspect of the protocol is constrained by drafts or RFCs. The choice of how to implement the protocol, such as effective packet transmission and congestion control algorithms, will affect its performance. Congestion control is a technique used by user computers and servers to adapt to overloaded networks: by dropping packets, subsequent data transmission is limited. Since QUIC is a new protocol, correctly designing and implementing congestion control requires experimentation and adjustments.
From the perspective of simplicity and security, loss detection and congestion control specifications recommend using the Reno algorithm but allow users to choose any algorithm based on their circumstances. Our implementation started with the New Reno algorithm, and based on past experience, we know that better performance can be achieved through other means. We have recently migrated to the CUBIC algorithm, which shows significant performance improvements over the New Reno algorithm in networks with high data transmission and frequent packet loss.
For the existing HTTP/2 technology stack, we currently support BBR V1 (TCP). This means that in our tests, we cannot make precise comparisons, as these congestion control algorithms behave differently between small and large data transmissions. Nevertheless, compared to HTTP/2, we have already observed faster speeds with HTTP/3 for smaller content transfers. For larger areas, the improved congestion control of HTTP/2 shines in performance.
For a 15KB small test webpage, HTTP/3 takes an average of 443ms to load, while HTTP/2 takes 458ms. However, once we increase the page size to 1MB, the advantage disappears: HTTP/3 is only slightly slower than HTTP/2 on today’s networks, taking 2.33 seconds to load compared to HTTP/2’s 2.30 seconds.
Benchmarking is interesting, but we are more curious about how HTTP/3 performs in the real world.
To measure this, we wanted a third party to load websites on our network like a browser. WebPageTest is a universal framework that displays page load times through beautiful waterfall charts. To analyze the backend, we used our own Browser Insights to capture white screen time. We then combined these two sets of data in an automated manner.
As a test case, we decided to monitor the performance of our company blog. We configured WebPageTest instances globally to load the site simultaneously via HTTP/2 and HTTP/3. We also enabled HTTP/3 and Browser Insight. Therefore, whenever our test script detects a browser accessing the site that supports HTTP/3, the browser will return the report data. We cleaned the data and compared it with the report data from HTTP/2.
The following diagram shows the page load times of the real page (blog.cloudflare.com) to compare the performance of HTTP/3 and HTTP/2. We also conducted these performance evaluations from different geographical locations.
As seen in the above diagram, in North America, HTTP/3 performance still lags behind HTTP/2 performance, with an average performance gap of about 1-4%. Similar conclusions were reached in Europe, Asia, and South America. We suspect this may be due to the different congestion algorithms: HTTP/2 on BBR v1 differs from HTTP/3 on CUBIC. In the future, we will strive to support the same congestion algorithm on both to achieve a more accurate performance comparison.
Conclusion
Overall, we are pleased to be involved in promoting the development of this standard. Our implementation performs well, providing better performance in some cases, and in the worst cases, performance is comparable to HTTP/2. As the standard is finalized, we look forward to browsers adding support for HTTP/3 in mainstream versions. For us, we will continue to support the latest drafts while seeking more ways, such as congestion tuning, priority allocation, or system capacity (CPU and raw network throughput), to leverage HTTP/3 for better performance.
Meanwhile, if you want to give it a try, just enable HTTP/3 on our dashboard and download a browser that supports the protocol. For instructions on how to enable HTTP/3, please refer to our developer documentation.
https://developers.cloudflare.com/http3/intro/
Further Reading:
https://blog.cloudflare.com/http-3-vs-http-2/
The InfoQ reader group is now online! You can scan the QR code below to add the InfoQ assistant and reply with the keyword “Join Group” to apply for group membership. Everyone can freely express their opinions with InfoQ readers and editors, and valuable technical gifts await you. There are also exciting activities for you to participate in, so come join us!
Click to see fewer bugs 👇