HTTP/3, based on UDP, is the new version of the HTTP protocol. The IETF (Internet Engineering Task Force) met in Bangkok in November 2018 to adopt this new Internet draft.
What is HTTP/3?
The HTTP/3 protocol is the new version of the Hypertext Transfer Protocol (HTTP) and is based on the UDP protocol. It became a standard in June 2022. Nevertheless, companies like Google, Microsoft or Facebook had already been using it to accelerate the web for a while. According to data about the use of HTTP/3 on W3Techs, about 25% of websites already use HTTP/3 as of September 2022.
HTTP/3 was previously known as HTTP-over-QUIC. The network protocol QUIC was initially developed by Google and will replace HTTP/2. The development of HTTP/3 started years ago and its goal is to accelerate the Internet speed by making some important changes in the way data is transferred.
This protocol benefits from the features of the UDP protocol and defines many of the new features that were in previous HTTP versions on the TCP layer. This allows to remove the limitations existing within the Internet’s infrastructure. While HTTP/1.1 and HTTP/2 used TCP on the transport layer, HTTP/3 uses QUIC, aiming to solve one of the main problems of HTTP/2 regarding the linear progression of the downloads.
Although HTTP/2 mitigates the “head-of-line-blocking” problem thanks to multiplexing, it is still limited by TCP. Since, despite enabling the use of a unique TCP connection for multiple transmissions, when one of them suffers a packet loss, the whole connection stops while waiting for TCP to retransmit the lost packet. HTTP/3 is not limited by this blocking problem, thanks to its integration on the connectionless UDP protocol.
By providing multiplexing natively, QUIC allows that lost packets only impact those transmissions where data has been lost. So, new streams within a QUIC connection do not need to wait for the others to finish. Moreover, TCP handshake overhead is also removed and, as a consequence, latency is reduced. Regarding reliability, QUIC does not include some of the features of the TCP protocol, but it makes up for it above the UDP layer, providing retransmitting of packets, ordering, etc.
Transport layer: TCP vs UDP
TCP: Transport Control Protocol
TCP is the acronym for Transport Control Protocol. This protocol is over the Internet Protocol (IP) layer. TCP is the basis for many Internet protocols and services and it is in charge, among other things, of:
- Providing the necessary reliability for the web, file transfer, etc.
- Establishing multi-step connection, guaranteeing the order of packets and offering lost packet retransmission.
- Offering a checksum computation for error detection.
Nevertheless, in terms of reliability, the TCP protocol also entails an important limitation: the overhead of all the round trips required to ensure the correct delivery of the information. Because of this, TCP has become a bottleneck for improving speed. Although HTTP/2 offers some improvements on this matter, as explained later on.
The TCP protocol specification goes back to 1974 and 1981 (RFC 675 and RFC 793 respectively). Since then, this protocol has not suffered significant changes since it is deeply integrated into operating systems, firmware, etc., and modifying it is not an easy task.
UDP: User Datagram Protocol
UDP is the acronym for User Datagram Protocol. UDP is a connectionless protocol based on datagrams; without delivery guarantees. Information delivery, data integrity, etc., are delegated to the application layer. The UDP protocol is mainly used for applications such as VoIP, DNS, DHCP and BOOTP, among others. UDP packet format specifications are minimal. Its header consists of:
- Source and destination port,
- length (in bytes) of packet header and packet data,
- and the checksum for data integrity verification (optional with IPv4 and compulsory with IPv6).
The UDP protocol specification dates from 1980 (RFC 768) and it is also widely used. So, any substantial improvement would also entail important changes on the firmware of devices connected to the Internet and on operating systems.
QUIC network protocol
QUIC is the acronym for Quick UDP Internet Connections. QUIC, designed by Jim Roskind at Google in 2012, is a network protocol over the UDP transport layer. Google’s QUIC version was only focused on HTTP transport, using HTTP/2’s syntax. However, for its standardisation, the IETF goes further.
With QUIC, the limits of network layers, communications, reliability features and security features in “user space” are redefined. This allows to avoid the need to upgrade the kernels of internet-wide systems. Nevertheless, the use of UDP brings both advantages and disadvantages to QUIC and HTTP/3. One of the challenges is CPU load, which can double with QUIC, compared to HTTP/2, according to some estimations. This is due to the fact that operating systems and software are not optimized for using UDP; since TCP has been the main protocol for a long time.
Furthermore, using TLS is mandatory for QUIC connections; in order to impede devices in the middle to alter or detect traffic. QUIC streams have an ID that identifies who starts the transmission and they are sent over unidirectional or bidirectional QUIC connections.
Implementation of HTTP/3
The implementation of HTTP/3 promoted by the IETF also includes previous versions; for compatibility reasons. As defined in the RFC 7838, a header informs the client about the availability of HTTP/3, together with the port details. As of May 2021, the browsers Google Chrome, Firefox, Safari and Microsoft Edge already support HTTP/3 — at least as an experimental feature, while waiting for its standardisation. As well as servers like Litespeed Web Server, HAProxy 2.3 or Caddy web server.
Moreover, there are some open source libraries of implementations of HTTP-over-QUIC, such as: neqo by Mozilla, Cronet by Google, proxygen by Facebook, lsquic by LiteSpeed, aioquic, quic-go or nghttp3. On GitHub there is a complete list of the libraries available, developed using different programming languages (C, C++, Rust, Python…).
HTTP versions
The first version of HTTP was released in 1991 as HTTP/0.9. HTTP/1.0 and HTTP/1.1 came after it in 1996 and 1997 respectively. With the evolution of the Internet and the web, the protocol has been constantly upgraded to improve data transfer over the network. But, until the release of HTTP/2 in 2015, there had not been any substantial change. This new version improved data transfer and, as a consequence, allowed to significantly accelerate web pages load speed. Finally, HTTP/3 is the next version and it is expected to further improve the Internet speed.
HTTP/2 improvements
The HTTP/2 protocol already added some interesting improvements, such as:
- Overcoming some limitations of the TCP protocol with improvements like non-blocking downloads, pipelining and server push.
- Minimizing the number of request-response cycles and, as a consequence, improving load speed.
- Multiplexing or sending several resources using a unique TCP connection.
- Improving flexibility when downloading static resources and removing the linear progression of the downloads limitation. This means that a large JavaScript resource does not necessarily have to affect the load of other static resources.
To that list, we must add HTTP/2 header’s HPACK compression and default binary format for data transfer. This considerably improved the protocol’s efficiency.
Furthermore, in order to make the most of HTTP/2, the main browsers made the use of SSL mandatory; which made speed improvements insignificant in some cases.
To sum up, the evolution of essential protocols such as HTTP is indispensable in the ever changing context of the Internet and the web. With respect to the new version of this protocol, there are diverse approaches. Some people think that, considering that the HTTP/2 standard has not still been adopted completely, it might be too soon to launch a new version. Nevertheless, the success of the tests carried out with HTTP/3 is encouraging, since it would be very advantageous for all users. As we mentioned earlier, the main browsers already support HTTP/3 and some companies like Google, Mozilla, Facebook or Akamai have been using this new protocol for years.
Sources: W3Techs.
