When HTTP/2 was released in 2015 as an official IETF standard it was a major improvement over the old HTTP/1.1 protocol that had been in use since the ’90s. At Seravo we rolled HTTP/2 out for all of our customers in 2016 and we are following with interest the developments around the next major step in the evolution of HTTP: the upcoming HTTP/3 standard.
HTTP stands for Hypertext Transfer Protocol and it was originally designed to transfer HTML pages from servers to browsers. In the past 30 years, the use of HTTP has expanded to almost all sorts of transfers on the Internet including not only web site traffic but also APIs, IoT devices, file transfers, etc. Any improvements to the HTTP protocol affect pretty much the entire internet.
HTTP/2 Was for Browsers, HTTP/3 Is for Traffic Routers and Firewalls
HTTP/2 introduced many optimizations to the way browsers load web pages, rendering legacy techniques like asset concatenation and minification mostly obsolete. In HTTP/3 the main optimization is about switching from TCP in the transport layer to the simpler UDP protocol, and implementing the features TCP has on the HTTP level, like packet ordering and re-submission (if packets were lost).
The effects of this will be a faster HTTP for browsers and all other software using HTTP, but unlike HTTP/2, the upcoming HTTP/3 has fewer browser visible “new features” for website developers. The HTTP/3 benefits are more visible on the transport layer level and they are actually very profound from a network router and switch point of view.
This is also the biggest engineering challenge. HTTP/3 developers need to consider the upgrade path form HTTP/2 to HTTP/3 and how all the network routers, firewalls and other devices out there on the Internet behave. First of all network owners are unlikely to renew their hardware any soon, so the backward compatibility needs to be implemented very one-sided from by HTTP/3. Also, there is a huge range of optimizations built into routers and firewalls that have various assumptions about what kind of traffic HTTP normally is (blocking or filtering unusual HTTP traffic) and HTTP/3 needs to consider many quirks to be successful in the real world.
This will also have major implications on operating systems, since so far their network stacks have been heavily optimized for TCP and HTTP, and now when the use of UDP will increase the OS kernels need to have their UDP code reviewed and optimized so UDP will be faster than TCP in real life.
The roll-out of HTTP/2 was partly successful due to the use of encryption. All routers and firewalls out there were already ignoring HTTPS traffic (since they cannot see inside it) and there were not many special optimizations for HTTPS filtering and routing due to the encryption. Thus all the new HTTP/2 changes were feasible to roll-out in production without changes to networking hardware and software since everything new was encapsulated inside the encrypted payloads. This also naturally leads that pretty much all future HTTP traffic will be encrypted since that is the only way to use HTTP/2 in real life. Encryption will also play a central part in the HTTP/3 story – in fact, HTTP/3 will have TLS 1.3 embedded in the protocol.
Is it QUIC enough?
HTTP/3 is partially based on QUIC, a transport layer network protocol developed initially by Google where userspace congestion control is used over the User Datagram Protocol (UDP). This is the main idea that still holds, but in HTTP/3 the QUIC implementation is very much something else than what the original QUIC by Google was. HTTP/3 is not just QUIC and actually, the first working name for HTTP/3 was “HTTP-over-QUIC”.
Thanks to using UDP and QUIC, HTTP/3 will be faster because of:
- Faster handshakes
- Early data that works (no waiting TCP ramp-up anymore)
- Independent streams (more data in parallel without head-of-line blocking)
The standard is currently in the state of a “working draft”. One of the IETF working group members, Daniel Stenberg (author of curl) has commented that the final version will be ready by summer 2020.
Currently, there are very few benchmarks available. In fact, there is no official HTTP/3 support in any of the major HTTP servers like Apache or Nginx yet.
As of early 2020, no major browser uses HTTP/3 by default yet.
As the chart above illustrates, this is not something web developers can benefit from in a while. Due to a lack of UDP optimizations in operating systems, we will probably need to wait for new Linux kernel versions before the benefits of HTTP/3 will materialize in production.
The Latest Report on HTTP/3 in Main Track at Fosdem This Weekend
If you are interested in the technical details of HTTP/3 and the current developments, we warmly recommend checking out Daniel Stenberg’s presentation on HTTP/3 at FOSDEM 2020 this weekend or either remotely via the video stream or in person. If you are there, remember to greet our staff as well!
Expect HTTP/3 in the Latter Half of 2020
However, since this optimization happens on the network level, the good news for web developers is that there are no code changes required on any website. Just make sure your server environment provider follows the scene and upgrades to HTTP/3 when it has matured.
At Seravo we rolled-out HTTP/2 in 2016, and as a customer of Seravo, you can expect us to make HTTP/3 available when it is feasible, so you and your website visitors can benefit of it – without having to do anything yourself!