Get best of the week

HTTP / 3 and HTTP / 2 performance comparison



We at Cloudflare announced HTTP / 3 support last September when we were celebrating our ninth birthday . Our goal has always been to improve the Internet. Collaboration in the field of standards is an important part of the process, and we are fortunate to be involved in the development of HTTP / 3.

Although HTTP / 3 is still at the draft stage, we noticed a great interest in the new protocol from our users (Cloudflare infrastructure serves more than 10% of Internet sites - approx. Per.). To date, more than 113,000 zones have activated HTTP / 3 support, and if you have an experimental browser, now you can access these zones using the new protocol! It's great that so many people have included it: working on HTTP / 3 of a large number of real websites means that you can test more various properties from browsers.

We initially launched HTTP / 3 in partnership with Google, which also included experimental support for Chrome Canary. Since then, more and more browsers have added experimental support: it appeared in Firefox Nightly builds , in various Chromium-based browsers such as Opera and Edge (via the Chromium base engine), and in Safari pre-builds . We closely monitor these developments and help wherever we can. Having a large network of sites that have enabled HTTP / 3 gives browser developers an excellent testing ground to validate the code.

So what is the current status?


The IETF standardization process involves a series of drafts to prepare a “final draft” ready for labeling as an RFC standard. QUIC team members work together on analysis, implementation, and interoperability to identify potential problems. We launched protocol support at the stage of the 23rd version of the draft, and then we followed all the changes, and at the time of writing (April 14, 2020) the last was the 27th version. With each draft, the quality of the QUIC definitions improves and approaches a “rough consensus” about how the protocol should behave. To avoid perpetual analysis with endlessly dopilivaniya settings to the ideal, with each new version of the draft the bar for making changes to the specification increases. This means that with each version there are fewer changes, and the final RFC will closely correspond to the protocol that we have already launched in production.

Benefits


One of the main advantages of HTTP / 3 was the increase in performance, especially when requesting multiple objects at the same time. In HTTP / 2, any interference (packet loss) in a TCP connection blocks all flows at once (blocking the beginning of a line). Since HTTP / 3 is based on UDP, only one stream is interrupted when a packet is lost, but not all.

In addition, HTTP / 3 supports 0-RTT (zero receive-transmit time), that is, subsequent connections can start much faster than the first, eliminating the need to confirm TLS from the server when establishing a connection. This means that the client begins to request data much earlier than with full TLS negotiation, that is, the website starts loading in the browser earlier.

The animations below show the effect of packet loss. In the first example, requests are received from the client to the server over HTTP / 2 to receive two resources. Requests and related responses are colored in green and yellow. Responses are broken into several packets. Alas, one packet is lost - as a result, the transfer of both resources is delayed.



In the second example, requests for two resources are received via HTTP / 3. One packet is lost, blocking the transfer of the yellow resource, but without affecting the green one.



Improvements in the procedure for negotiating a session mean that “connections” with servers are established much faster, that is, data arrives faster in the browser. We were curious how much this was reflected in real traffic, so we conducted several tests. To evaluate the contribution of 0-RTT, we launched several control tests to measure the time to the first byte (time to first byte, TTFB). On average, over HTTP / 3, the first byte appears after 176 ms. In the case of HTTP / 2, we see 201 ms, that is, HTTP / 3 here reduces the delay by 12.4%!



Interestingly, drafts and RFCs do not regulate all aspects of the protocol. For example, the packet transfer method affects performance.and traffic congestion control algorithm. Congestion control is a method of adapting to congested networks on the client and server side: when packets are lost, the quality of communication decreases. Since QUIC is a new protocol, experimentation and tuning are required to properly design and implement an overload management system.

As a simple and safe starting point, the Loss Detection and Congestion Control specification recommends the Reno algorithm , but any other can be used. We started with the New Reno algorithm , but based on experience, we assumed that it was not optimal. We recently switched to CUBIC - And in a network with oversized transmissions and greater packet loss, CUBIC performed better than New Reno. Soon we will talk more about this, stay tuned for a blog update.

In the current HTTP / 2 stack, we have BBR v1 (TCP). This means that the tests do not perform an exact comparison of apples with apples, as these congestion control algorithms behave differently on different gear sizes. However, when switching from HTTP / 2 to HTTP / 3, we already see an improvement on smaller sites. In large areas, brilliant performance is shown by our finely tuned and optimized HTTP / 2 stack.

A small 15K test page loads over HTTP / 3 on average in 443 ms, compared to 458 ms for HTTP / 2. But if you increase the page size to 1 MB, this advantage disappears: specifically in our network, the HTTP / 3 protocol now works a little slower than HTTP / 2 - 2.33 s versus 2.30 s.







Synthetic benchmarks are interesting, but it is interesting how HTTP / 3 shows itself in the real world.

For comparison, we wanted to attract a third-party service that can download sites from our network, simulating a web browser. WebPageTest is a common framework for measuring page load time, with good cascading diagrams (waterfall). To analyze the backend, we used our own Browser Insights system , fixing the timings at the edge of our network. Then they connected both parts by a little automation.

As a test case for measuring performance, we took our own blog . We set up our WebPageTest instances to load the site from locations around the world, both over HTTP / 2 and over HTTP / 3. Included HTTP / 3 and Browser Insights. Thus, every time a browser with HTTP / 3 support loaded the page, test scripts requested collected analytics data from the browser. The same procedure was repeated for HTTP / 2 so that it could be compared.

The following graph shows the loading time of the actual blog.cloudflare.com page with a comparison of the HTTP / 3 and HTTP / 2 metrics. We have such metrics for different geographical points.



As you can see, HTTP / 3 performance is still inferior to HTTP / 2 performance. The difference is about 1-4% on average in North America. Similar results in Europe, Asia and South America. We suspect that this may be due to a difference in congestion control algorithms: BBR v1 works on HTTP / 2, and CUBIC on HTTP / 3. In the future, we will try to implement the same overload control algorithm on both protocols in order to get a more accurate comparison of apples with apples.

Conclusion


Overall, we are very happy to help advance the new standard. Our implementation holds well, in some situations shows better performance, and in the worst case - similar HTTP / 2. As the standard is finalized, we look forward to browsers adding HTTP / 3 support in major versions. As for us, we will support the latest drafts and will look for new ways to optimize HTTP / 3 to further improve performance, whether it is setting up congestion control, prioritization or system configuration (CPU and channel bandwidth).

In the meantime, if you want to try HTTP / 3 in action, just activate it on our dashboard and download the test assembly (Nightly, Canary) of any of the main browsers. See our developer documentation for instructions on enabling HTTP / 3 .

More articles:


All Articles