HTTP/3
The HyperText Transfer Protocol (HTTP) is a data communications protocol and acts as the foundation of the World Wide Web. Originally released in 1991 (HTTP/0.9), it has been through several minor revisions, as well as a major revision to HTTP/2, which was published in 2015. HTTP/3 is the next major revision of the protocol to be developed and released.
This major revision to the standard changes the underlying transport layer network protocol from the Transmission Control Protocol (TCP) to QUIC (“Quick UDP Internet Connections”). The original proposal was named “HTTP/2 Semantics Using The QUIC Transport Protocol”, then “Hypertext Transfer Protocol (HTTP) over QUIC”, and finally HTTP/3.
Status
Currently the specification for HTTP/3 is still an IETF draft. However, it is already supported by the majority of web browsers and is running on millions of websites.
The QUIC protocol and limitations with TCP
The Quick UDP Internet Connections (QUIC) protocol was developed by Google and after SPDY, which became HTTP/2, it is the next experimental technology from Google to become a standard. It is a multiplexed communication algorithm that is built on top of the UDP protocol.
The initial goal of QUIC was to offer an alternative to HTTP/2 using TCP for data transmission and TLS for security. TCP was not originally built with a focus on efficiency. For instance, initiating a HTTP Connection requires a full network round trip to ensure that the client and server are available and prepared to exchange data. Depending on the distance between client and server, as well as the number of intermediaries, the latency and resulting transmission times become more noticeable.
Another common problem is head-of-line blocking, which was supposed to be rectified using the pipelining approach that was implemented for HTTP/2. Pipelining allows for multiple HTTP requests using the same TCP connection, but this was inadequate because of how TCP transmits data. TCP perceives and works with data as a single-byte stream, even in cases where several mutually exclusive files are sent concurrently. The problem presents itself when packets containing data “at the head of the line” are lost because the remaining packets are consequently delayed until the missing ones are found.
Limitations with TCP can theoretically be addressed by updating the protocol. However, its entrenchment is solidified by the extant low-level implementations in operating systems and middleboxes. Widely deploying changes to TCP is simply not practical, in part due to scope, but also because middleboxes such as routers and load-balancers cannot always be as easily updated. As QUIC is built on top of UDP, it is not directly affected by the limitations of TCP.
HTTP/3 essentially relies on QUIC for security and integrity of data, peer authentication, and reliable, in-order data delivery with improved performance. These are improvements on top of HTTP/2 that cannot be easily accommodated by TCP, which is why it is necessary to switch the underlying protocol.
Performance
In the context of protocol transmission, performance gauges transmission speed, which is a combination of bandwidth and latency. Bandwidth refers to the volume of data that can be sent at one time, whereas latency refers to the time spent moving data from one endpoint to another. Two-way latency is the length of time that it takes to complete a full network round trip. Each intermediary along the path may have different bandwidth limitations and ultimately, performance is limited by the slowest connection between intermediaries or an intermediary and an endpoint.
Ideal performance is realized through a reliable and consistent series of high-bandwidth, low-latency connections for the length of the full network round trip. Performance is a critical measure because it is directly related to packet loss, which in turn requires a reliable approach to congestion control.
QUIC uses compressed Headers, as does HTTP/2. However, QUIC utilizes the QPACK algorithm for header compression, whereas HTTP/2 uses HPACK. The difference is that QPACK is designed to work with streams.
In the context of CPU load, QUIC takes more CPU time than the same volume of data using HTTP/2 secured with TLS. This is because UDP is not as optimized, generally, as TCP, from an implementation standpoint. Whether as part of the operating system or finding a hardware implementation, UDP support is simply not as broad or advanced. However, this is something that will change over time as QUIC becomes more widespread.
Congestion control
TCP and QUIC use similar methods to control congestion and limit both the likelihood and effects of packet loss during transmission. Each starts by sending data at a relatively slow rate and then increases the speed as acknowledgments are received about what and how much data is being received by the endpoint. This is an area of active development, and where QUIC has a clear advantage.
As previously mentioned, it is difficult to deploy updates to TCP. However, at this early stage, QUIC implementations are typically at the application level, where modifications and extensions are easy to implement and put into production. One such example of this is the Sender Control of Acknowledgment Delays in QUIC extension.
This extension was motivated by the fact that UDP transmissions can be CPU-intensive and therefore slower on certain platforms. By reducing the number of acknowledgment packets in certain environments, large benefits can be realized in terms of speed. This extension, and others like it, are relatively easy to implement in QUIC, yet are considerably more difficult to implement in TCP. This will facilitate improvements to congestion control and ultimately, may lead to an algorithm that works superior in all cases.
Simplified setup
QUIC does not require the same number of network round trips as HTTP/2 using TCP and TLS, lowering the overhead for each HTTP Connection. This is because TCP does not allow for the sending of non-TCP data during the initial handshake, so the TLS connection needs a separate network round trip to secure the TCP connection. As QUIC was designed with such security concerns in mind, the two operations are done together. In some cases, depending on which version of TLS is being used, using QUIC will save more than one full network round trip yielding even better performance.
Session resumption
When a HTTP Connection is established and secured, it is reasonable to assume under certain circumstances that the client will again connect within a short time. The QUIC algorithm takes advantage of this knowledge by preparing for a second HTTP Connection before the first one is terminated. By doing this preparation in advance, it saves at least one full network round trip when establishing the new HTTP Connection. This is referred to as Zero Round Trip Time Resumption, or 0-RTT.
QUIC has certain limits in place when replying to 0-RTT requests to thwart certain types of DDoS attacks. This data throttling is known as the anti-amplification limit and refers to the amount of data that it can send in response before the client is verified. The limit is set to three times the amount of data received from that address.
Connection migration
Another performance enhancement supported by the QUIC protocol is connection migration, which can maintain a HTTP Connection when transferring from one network to another. For example, moving from a cellular network into an office or home and joining the local Wi-Fi network will mean a new IP address assignment. This changes at least one of the parameters that make up the TCP 4-tuple, which is the aggregation of client IP address, client source port, server IP address, and server destination port. To identify HTTP connections, QUIC introduces a new parameter called the connection identifier (CID) that does not change when transferring between networks.
Technically, the CID, in this context, is not a single identifier. It is instead a list of randomly generated identifiers known to both the server and client that identify the same HTTP Connection. Each time a new network is used, the CID changes to another one in the list. The purpose of this is to further protect the privacy of the originator.
Even pre-QUIC, there was a period of overlap between the first network dropping a HTTP Connection and the second network taking over, but the switch was not always transparent. Especially in the case of streaming audio or video, such as a video conference, the user is not aware of the network switch.
It is pertinent to take note that when a HTTP Connection is migrated to another network, the data transfer resumes but the protocol has to again test the rate at which it can safely continue. This means that the congestion control algorithm starts at the beginning and slowly adjusts the bandwidth until it reaches the optimal rate for the new network. The connection will not be dropped, although even when moving to a network of the same or higher bandwidth, the rate of transfer will drop momentarily.
For this reason, connection migration’s contribution to performance is not so much about speed in the average case, as it is for preventing a more serious hit due to connection churn. It may be of little consequence, however, because this type of network transfer does not occur very often. For example, a new IP address is not created when switching between access points in a mesh network inside a large office building.
Security
Although there has been much attention to improving performance with the adoption of QUIC, there is also an advantage from a security and data privacy perspective. It is helpful to consider that a secure HTTP Connection (i.e. HTTPS) is made using the Transport Layer Security (TLS) protocol on top of the HTTP Connection. This two-layer approach has been in place since the early days of the internet when there was less of a priority when it came to encrypting traffic. With QUIC, the security has been merged, and TLS 1.3 is part of the protocol. It is no longer a multilayer approach. One of the only parts of a QUIC connection that are not encrypted is the CID, which helps to direct traffic.
Middleboxes such as load-balancers and routers are unaware of the contents of a QUIC packet, and as such, it means that updates to the protocol are required only on the endpoints. Although this adds a degree of flexibility that allows it to scale much easier than TCP, it detracts from the traffic monitoring capabilities that are employed by firewalls.
End-users have the benefit of HTTP connections that are inherently more secure and it further simplifies the connection process. However, there are some disadvantages to the additional security provided by QUIC, not the least of which is the additional overhead. Also, packet inspection and much of the other connection-level tracking that is done by middleboxes such as firewalls can no longer be done due to the encryption.
Another security-related issue is that QUIC only works with official TLS certificates. The rationale is that if traffic may be decrypted by a middlebox for monitoring purposes, then ultimately, middleboxes will have custom QUIC implementations. This will negate the effort that went into creating a more scalable protocol in the first place. Therefore, self-signed certifications, for example, cannot be used.
Programming resources
Software developers working to implement QUIC into their projects will recognize that it is a rather complex algorithm and a considerable effort is required to implement it from scratch. To assist with the task, there are a variety of open-source QUIC implementations available for different environments, programming languages, and roles.
Takeaway
HTTP/3 represents a major revision to the protocol over the previous release. It relies on a new underlying protocol, QUIC, built on top of UDP, rather than TCP. It is intended to be more robust and provide better security than previous versions of HTTP, and includes an additional parameter to help identify and maintain HTTP connections when changing networks. Although many of the features are duplicated from HTTP/2, a new underlying protocol was necessary to address the shortcomings of TCP.