HTTP/3 deep dive

HTTP/3 deep dive

HTTP3 is the latest iteration of the original HTTP protocol, which powers the World Wide Web (WWW). From its inception, HTTP was the preferred application layer protocol chosen for exchanging hypertext documents. But over the years, HTTP has had a few significant upgrades to keep pace with the growth of the Internet, and the sheer variety of content exchanged over WWW.

This article is a deep dive on HTTP/3, the latest and soon to be standardized version of HTTP. It presents the evolutionary journey of the HTTP protocol with a focus on HTTP/3’s features and provides a peek into the future of an Internet powered by HTTP/3.

Background

At the time of its conception, the World Wide Web was merely a cluster of computers serving hypertext documents. Exchanging these documents between computers was a simple procedure consisting of request followed by a response. A simple text-based protocol was framed based on this procedure. Thus the HTTP (Hypertext Transfer Protocol) came into existence. Later it was drafted as a standardized IETFprotocol defined in RFC 1945, also known as HTTP/1.0.

Over the years, HTTP has evolved from HTTP/1.0 to HTTP/1.1 and then to HTTP/2. At every iteration, new features have been added to the protocol to handle a plethora of needs, such as application layer requirements, security considerations, session handling, and media types. For an in-depth look at HTTP/2 and its evolution from HTTP/1.0, take a look at our HTTP/2 concept piece.

In spite of the several revisions, the underlying transport mechanism of HTTP has fundamentally remained the same. However, with burgeoning Internet traffic, powered by the adoption of mobile phones, the transport mechanism of HTTP has become strained in ensuring a smoother web browsing experience.

HTTP/3 is the culmination of an effort to straighten out the transport-related issues of HTTP/2.0 and forecasts faster access to the Web across all forms of devices. It envisages a new transport layer protocol called QUIC (Quick UDP Internet Protocol), which works atop UDP. This choice is in stark deviation from the earlier versions of HTTP, which are all based on TCP. TCP is a more reliable protocol than UDP, so why redesign the transport layer of HTTP atop UDP?

Let’s look at the limitations of running HTTP over TCP, and dive into the design considerations for HTTP/3 based on the QUIC protocol.

What is HTTP/3

When IETF formally standardized HTTP/2, Google was independently building a new transport protocol called gQUIC. It was later accepted as an internet draft in IETF and christened as QUIC. The initial experiments with gQUIC proved to be very encouraging in enhancing the web browsing experience under poor network conditions. Hence gQUIC was gaining momentum, and an overarching majority of IETF members voted in favor of building a new specification for HTTP that runs over QUIC. This new initiative came to be known as HTTP/3 to differentiate it from the current HTTP standard, HTTP/2.

Both syntax-wise and semantically, HTTP/3 is similar to HTTP/2. HTTP/3 follows the same sequence of request and response message exchanges with a data format that contains methods, headers, status codes, and body. However, a significant deviation in HTTP/3 lies in the stacking order of protocol layers on top of UDP.

How Does HTTP/3 Work?

The crux of HTTP/3 functionality revolves around the underlying QUIC protocol. Before we talk about QUIC and UDP it’s worthwhile to list certain limitations of TCP, which led to the development of QUIC in the first place.

TCP can intermittently hang your data transmission

TCP’s receiver sliding window does not progress if a segment with a lower sequence number is yet to be received, even though other segments with higher sequence numbers are already received. This causes the TCP stream to hang momentarily, and under worse conditions can lead to connection closure even if one out of all segments was not received. This problem is known as Head Of The Line (HoL) blocking of the TCP stream.

TCP does not support stream level multiplexing

While TCP does allow multiple logical connections to and from the application layer, it doesn’t allow multiplexing of data packets within a single TCP stream. With HTTP/2 the browser can open only one TCPconnection with the server and uses the same connection to request multiple objects, such as CSS, JavaScript, and other files. While receiving these objects, TCP serializes all the objects in the same stream. As a result, it has no idea about the object level partitioning of TCP segments.

TCP incurs redundant communication

A TCP connection handshake undergoes a redundant message exchange sequence, even if the connection is established with a known host.

Source: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

The QUIC protocol solves these problems by introducing a few changes in the underlying transmission mechanism, based on the following design choices:

• UDP as the choice for underlying transport layer protocol: Building a new transport mechanism over TCP will inherit all the above disadvantages of TCP. Hence UDP is a smart choice. Moreover, QUIC is built at the user level, so it doesn’t require changes in the kernel with every protocol upgrade.
• Stream multiplexing and flow control: QUIC introduces the notion of multiple streams multiplexed on a connection. QUIC by design implements a separate, per-stream flow control, which solves the problem of head of line blocking of the entire connection.

• Flexible congestion control: TCP’s congestion control mechanism is rigid. Every time the protocol detects congestion, it reduces the congestion window size by half. In comparison, QUIC’s congestion control is designed to be more flexible and makes more efficient use of the available network bandwidth resulting in better traffic throughput.
• Better error handling: QUIC proposes to use enhanced loss recovery mechanism and forward error correction to deal with erroneous packets in a better way. This feature is a boon for web users whose only access to the Internet is via patchy and slow wireless networks that perennially witness high rates of error in transmission.
• Faster handshaking: QUIC uses the same TLS module for a secured connection. However, unlike TCP, QUIC’s handshake mechanism is optimized to avoid redundant protocol exchanges every time two known peers establish communication with each other.

Source: https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.htm

By stacking the HTTP/3 based application layer over QUIC, you get all the advantages of an enhanced transport mechanism while retaining the same syntax and semantics of HTTP/2. However, you must also note that HTTP/2 cannot be directly integrated with QUIC as the underlying frame mapping from application to transport is incompatible. Therefore, IETF’s HTTP working group suggested HTTP/3 as the new HTTP version with modified frame mapping as per the frame format requirement of QUIC protocol.

In addition to this, HTTP/3 also uses a new header compression mechanism called QPACK, which is a modification of HPACK used in HTTP/2. Under QPACK, the HTTP headers can arrive out of order in different QUIC streams. Unlike in HTTP/2, where TCP ensures in-order delivery of packets, QUIC streams are delivered out of order and may contain different headers in different streams. Therefore, QPACK uses a lookup table mechanism for encoding and decoding the headers.

Why is HTTP/3 Important?

TCP has been around for over four decades. It was initially standardized way back in 1981 through RFC793. Over the years, it has undergone updates and has proven to be a very robust transport protocol for supporting the growth of Internet traffic. However, by design, TCP was never suitable for handling data transmission in lossy wireless medium. In the early days of the Internet, wired connections linked every computer in a network.

Now with the number of smartphones and portable devices surpassing the number of desktops and laptop computers, more than 50% of Internet traffic is already being delivered over wireless. This trend poses a problem for the overall web browsing experience, most important of them being the head of line blocking in TCP under inadequate wireless coverage.

Some of the initial experiments performed by Google prove that implementing QUIC as the underlying transport protocol for some of the popular Google services greatly improved the speed and user experience. By deploying QUIC as the underlying transport protocol for streaming YouTube videos, Google reported a 30% drop in rebuffering rates, which have a direct impact on the video viewing experience of the user. Similar improvements were seen in displaying Google search results.

These results were conspicuous when operating under poor network conditions, prompting Google to work more aggressively on refining the protocol, before eventually proposing it to IETF for standardization.

With all the improvements resulting from these early trials, QUIC has emerged as an essential ingredient for taking the World Wide Web into the future. A facelift for HTTP from HTTP/2 to HTTP/3, with the support of QUIC is a logical step in this direction.

The best use cases of http/3

HTTP/3 is slated to improve the overall web surfing experience, especially in regions where high-speed wireless internet access is still unavailable. Even though HTTP/2 is well suited for some of these applications, HTTP/3 adds value to some use cases.

Internet of Things (IoT)

HTTP may not be the preferred protocol for IoT, but there are cases where HTTP based communication is well-suited for specific applications. HTTP/3 can address the issues of lossy wireless connection for mobile phones that gather data from attached sensors. This problem is equally applicable for standalone IoT devices mounted on vehicles or movable assets. With the robust transport layer of HTTP/3, access to and from such devices via HTTP is more reliable.

Big data

Enterprises across the world are waking up to the potential of amassing data from multiple departments and framing them into a larger canvas of information sharing APIs for both internal and external audiences. These APIs also pave the way for monetizing the data by hosting them as streaming APIservices. They are also a data firehose, spitting out enormous amounts of data over time. Soon such streaming APIs hosted via HTTP/3 are going to make them more robust and resilient for consumption, compared to HTTP/2.

Web VR

With the improved abilities of browsers, the content landscape is changing fast. One area is web-based VR. Although still in its infancy, there are plenty of use cases where VR plays a pivotal role in enhancing collaboration. The web holds the center stage in facilitating such VR rich interactions. VR applications demand more bandwidth to render intricate details of a virtual scene and will surely benefit from migrating to HTTP/3 powered by QUIC.

Adopting HTTP/3: considerations & limitations

Transitioning to HTTP/3 involves not only a change in the application layer but also a change in the underlying transport layer. Hence adoption of HTTP/3 is a bit more challenging compared to its predecessor HTTP/2, which required only a change in the application layer alone. The transport layer undergoes much scrutiny by the middleboxes in the network. These middleboxes, such as firewalls, proxies, NAT devices, perform a lot of deep packet inspection to meet their functional requirements. As a result, the introduction of a new transport mechanism has a few ramifications for IT infrastructure and operations teams.

Yet another problem with widespread adoption of HTTP/3 is the fact that it is based on QUIC, which runs over UDP. A majority of web traffic, as well as well known services defined by IETF, runs on top of TCP. That’s why a prolonged UDP session running HTTP/3 can be frowned upon by a firewall’s default packet filtering policies.

With the standardization efforts underway at IETF, these issues will eventually be ironed out. Moreover, given the positive results shown by Google’s early experiments with QUIC, there is overwhelming support in favor of HTTP/3, which will eventually force middlebox vendors to standardize.

One possible scenario where HTTP/3 might become too cumbersome to adopt is for constrained IoT devices. Many IoT applications deploy devices that are very low on form factor. Hence they have limited RAM as well as CPU power. This requirement is enforced to make the devices operate efficiently under constrained conditions, such as battery power, low bit rate, and lossy connectivity. HTTP/3’s additional transport layer processing, in the form of QUIC, on top of existing UDP, adds to the footprint of the overall protocol stack. It makes HTTP/3 bulky enough to be unsuitable for those IoT devices. But such situations are scarce, and specialized protocols exist, which obviates the need to support HTTP directly on such devices. Plus there are IoT-focused protocols such as MQTT.

Getting Started with HTTP/3

The HTTP Working Group at IETF is working on releasing the HTTP/3 during the later part of 2020. So it’s not yet officially supported by popular web servers such as NGINX and Apache. However, several software libraries are available to experiment with this new protocol, and unofficial patches are also provided.

Here is a list of the popular software libraries that support HTTP/3 and QUIC transport. Note that these implementations are based on one of the internet draft standard versions, which is likely to be superseded by a higher version leading up to the final standard published in an RFC.

Quiche (https://github.com/cloudflare/quiche)

Quiche provides a low-level programming interface for sending and receiving packets over QUICprotocol. It also supports an HTTP/3 module for sending HTTP packets over its QUIC protocol implementation. In addition to that, it also provides an unofficial patch for NGINX server to install and host a web server capable of running HTTP/3. Apart from this, additional wrappers are available for supporting HTTP/3 on Android and iOS mobile apps.

Aioquic (https://github.com/aiortc/aioquic)

Aioquic is a pythonic implementation of QUIC. It also supports an inbuilt test server and client library for HTTP/3. Aioquic is built on top of the asyncio module, which is Python’s standard asynchronous I/O framework.

Neqo (https:/github.com/mozilla/neqo)

Neqo is Mozilla’s implementation of QUIC and HTTP/3 using Rust.

If you want to play around with QUIC, check out this link of open source implementation of QUICprotocol, maintained by the QUIC working group. https://github.com/quicwg/base-drafts/wiki/Implementations