HTTP/2 Protocol

In the previous posts in the curriculum, we talked about Networking. This is also a part of Networking, and is called by many as HTTP/2 Protocol.

HTTP Today

HTTP 1.1 has become a protocol used for virtually everything on the Internet. Significant investments have been made in protocols and infrastructure that leverage this, to the extent that it is often easier today to build things on top of HTTP rather than create something entirely new.

The density of HTTP 1.1

When HTTP was initially created and released, it was likely perceived as a simple and straightforward protocol. However, time has proven that perception false. HTTP 1.0, as defined in RFC 1945, was a 60-page specification released in 1996. RFC 2616, which describes HTTP 1.1, was released just three years later in 1999 and had grown significantly to 176 pages. The subsequent update, developed within the IETF, split the specification into six documents, resulting in a much larger total page count (RFC 7230 and family). By any measure, HTTP 1.1 is extensive, including numerous details, subtleties, and a significant number of optional components.

A lot of Options

The nature of HTTP 1.1, with its numerous intricate details and options designed for future extensions, has fostered a software ecosystem where virtually no implementation fully implements every aspect of the protocol. Indeed, precisely defining "everything" is even problematic. This has resulted in a situation where features that were initially underutilized received limited implementation support, and those that did implement these features subsequently saw little practical use.

Subsequently, this created an interoperability challenge when clients and servers began to increase their use of these less common features. HTTP pipelining serves as a prime example of this.

Inadequate Utilization of TCP

HTTP 1.1 struggles to fully leverage the potential power and performance that TCP provides. Consequently, HTTP clients and browsers must employ innovative solutions to reduce page load times.

Parallel efforts over the years have reinforced the difficulty in replacing TCP, thus motivating continued work on improving both TCP itself and the protocols built upon it.

In essence, TCP's capabilities could be better utilized to minimize pauses or wasted intervals that could otherwise be used for data transmission and reception. The subsequent sections will detail some of these shortcomings.

Transfer Sizes and the Number of Objects

An examination of popular websites and the resources required to load their front pages reveals a clear trend. Over time, the volume of data required has steadily increased, reaching and surpassing 1.9 MB. Even more significantly, on average, displaying a single page requires over 100 individual resources.

As the accompanying graph illustrates, this trend has been consistent for some time, with no indication of any imminent change. The graph demonstrates the growth of the total transfer size (shown in green) and the total number of requests (shown in red) needed, on average, to serve the most popular websites globally over the past four years.

HTTP 1.1 exhibits significant latency sensitivity, partly because HTTP pipelining continues to suffer from substantial issues, leading to its widespread deactivation among a large percentage of users.

While bandwidth availability has increased considerably for many users in recent years, similar improvements in reducing latency have not been observed. High-latency connections, common in many current mobile technologies, impede a satisfactory and rapid web experience, even with high-bandwidth connections.

Furthermore, low latency is critical for certain real-time video applications, such as video conferencing and gaming, where pre-generated streams are not the sole mode of content delivery.

Head-of-Line blocking

HTTP pipelining enables the transmission of subsequent requests while awaiting responses to prior requests. This mechanism bears a notable resemblance to queuing at a service counter, such as in a bank or supermarket. In such scenarios, one cannot predict whether the preceding customer will be served expeditiously or experience significant delays. This inherent limitation is known as head-of-line blocking.

While one might attempt to select the most promising queue, or even initiate a new queue altogether, ultimately, a decision must be made. Once a queue is chosen, it cannot be changed.

The creation of a new queue also incurs performance and resource overhead, thus rendering it impractical for scaling beyond a limited number of queues. Consequently, there is no ideal resolution to this problem.

As a testament to these issues, the majority of desktop web browsers currently ship with HTTP pipelining disabled by default.

Addressing Latency Challenges

When confronted with problems, individuals often collaborate to devise workarounds. While some of these workarounds demonstrate ingenuity and utility, others are simply inadequate and poorly conceived solutions.

Spriting

"Spriting" is a term commonly used to describe the practice of combining multiple small images into a single, larger image. Subsequently, using either JavaScript or CSS, specific portions of this larger image are extracted and displayed as individual smaller images.

Websites frequently employ this technique to enhance performance. Retrieving a single, larger image in HTTP 1.1 is significantly faster than retrieving numerous smaller, individual images.

This technique, however, introduces certain drawbacks. Pages on the website that only require a limited number of the small images incur a penalty for loading the larger combined image. Additionally, spriting results in the simultaneous removal of all sprited images when the cache is cleared, rather than permitting the retention of frequently accessed images.

Inlining

"Inlining" represents an alternative technique to circumvent the transmission of individual image files, which involves embedding data URLs directly within a CSS file. This approach yields comparable advantages and disadvantages to the previously described image spriting method.

.icon1 {

   background: url(data:image/png;base64,<data>) no-repeat;

}



.icon2 {

   background: url(data:image/png;base64,<data>) no-repeat;

}

JavaScript Concatenation

Large websites often accumulate numerous distinct JavaScript files. To mitigate this, developers can employ front-end tools to concatenate, or combine, multiple scripts, thereby enabling browsers to retrieve a single, larger file rather than multiple smaller ones. However, this approach can lead to the transmission of excessive data when only a subset is required, as well as the need to reload substantial amounts of data following even minor modifications.

This practice primarily presents an inconvenience for the developers involved in the process.

Resource Sharding

The final performance technique to be discussed is commonly referred to as "sharding." This involves distributing aspects of a service across as many distinct hosts as possible. While seemingly counterintuitive at first, there is a logical rationale behind this approach.

The initial HTTP 1.1 specification stipulated a maximum of two TCP connections per host for each client. In order to circumvent this limitation without violating the specification, sophisticated websites employed numerous distinct host names, effectively enabling more concurrent connections and reducing page load times.

While this limitation has since been removed, with modern clients now typically utilizing six to eight connections per host name, they still operate under a connection limit. Therefore, websites continue to employ resource sharding to further increase the number of concurrent connections. As the volume of objects requested over HTTP continues to rise—as previously illustrated—the increased number of connections is leveraged to enhance HTTP performance and facilitate rapid page loading. It is not uncommon for sites to now utilize well over 50, or even upwards of 100, concurrent connections for a single website by using this approach. Recent data from httparchive.org indicates that the top 300,000 URLs globally require, on average, 40 TCP connections to display the website, and the trend suggests this number is gradually increasing over time.

Another motivation for resource sharding is to host images and similar resources on a separate host name that does not transmit cookies, as cookie sizes can be substantial. By using cookie-free image hosts, performance can be improved by significantly reducing HTTP request sizes.

The accompanying figure illustrates a packet trace from browsing a popular Swedish website, demonstrating how requests are distributed across multiple host names.

is a protocol developed and championed by Google. While its development occurred openly with invitations for participation from the broader community, it is evident that Google benefited from controlling both a popular browser implementation and a substantial server infrastructure supporting well-utilized services.

When the HTTPbis group initiated work on HTTP/2, SPDY had already established itself as a viable concept, demonstrating its deployability across the Internet. Furthermore, published data validated its performance capabilities. The HTTP/2 effort commenced with the SPDY/3 draft, which was subsequently transformed into the HTTP/2 draft-00 through a relatively straightforward find-and-replace process.

Core Concepts of HTTP/2

What, then, are the key achievements of HTTP/2? And what were the boundaries established by the HTTPbis group for their development efforts?

The boundaries imposed were, in fact, quite stringent, placing significant constraints on the team's capacity for innovation. Specifically:

• HTTP/2 had to maintain established HTTP paradigms. It remains a protocol where clients transmit requests to servers over TCP.


• http:// and https:// URLs were mandated to remain unchanged, with no new schemes permitted. The vast amount of existing content using these URLs precluded their modification.


• HTTP/1.1 servers and clients are expected to remain in use for decades; therefore, proxying them to HTTP/2 servers is a fundamental requirement.


• Consequently, proxies must be capable of performing one-to-one mappings between HTTP/2 features and HTTP/1.1 clients.


• The removal or reduction of optional protocol components was strongly encouraged. This was not a strict requirement but rather a guiding principle derived from SPDY and the Google team. Ensuring mandatory implementation of all features would prevent future compatibility issues due to partial or selective implementations.


• Minor versions were explicitly disallowed. It was determined that clients and servers would either be fully compatible with HTTP/2 or not at all. Should the need arise to extend or modify the protocol, HTTP/3 would be initiated. HTTP/2 will not include minor version increments.

HTTP/2's Compatibility with Existing URI Schemes

As previously stated, the existing URI schemes cannot be altered; therefore, HTTP/2 must operate using these existing schemes. Given their current usage with HTTP 1.x, a mechanism is required to upgrade the protocol to HTTP/2 or, alternatively, to explicitly request that a server utilize HTTP/2 rather than older protocols.

HTTP/1.1 defines the Upgrade: header for this purpose, which enables a server to respond using a new protocol when such a request is received over an older protocol. This, however, incurs the overhead of an additional round-trip.

This round-trip penalty was deemed unacceptable by the SPDY team, and considering their implementation of SPDY exclusively over TLS, they developed a novel TLS extension to significantly expedite the negotiation process. This extension, termed Next Protocol Negotiation (NPN), allows a server to inform the client which protocols it supports, enabling the client to then select its preferred protocol.

HTTP/2 and TLS

A significant emphasis in HTTP/2 development was placed on ensuring its proper operation over TLS. While SPDY mandated TLS, and there was considerable advocacy for making TLS mandatory for HTTP/2, consensus could not be achieved, and HTTP/2 was ultimately released with TLS as an optional component. However, the lead developers for two leading web browsers—Mozilla Firefox and Google Chrome—have explicitly stated their intention to implement HTTP/2 exclusively over TLS.

The reasons for opting for TLS-only implementations include a commitment to user privacy and early data demonstrating a higher success rate for these new protocols when used with TLS. This is attributed to the prevalent assumption that traffic on port 80 is exclusively HTTP/1.1, leading some intermediate network devices to interfere with or disrupt traffic when other protocols are used on that port.

The subject of mandatory TLS has generated considerable debate and strong opinions within mailing lists and meetings—with opinions divided as to its merits and drawbacks. It remains a highly contentious issue, and it is prudent to approach the subject with sensitivity when discussing it with an HTTPbis participant.

Similarly, a protracted debate has revolved around whether HTTP/2 should mandate a specific list of ciphers when using TLS, or whether it should blacklist certain cipher suites, or whether it should abstain from any requirements concerning the TLS "layer," deferring that to the TLS working group. The final specification stipulates that TLS must be at least version 1.2 and includes cipher suite restrictions.

TLS Protocol Negotiation for HTTP/2

Next Protocol Negotiation (NPN) was the initial protocol used to negotiate SPDY connections with TLS servers. Recognizing its limitations as a non-standard protocol, it was submitted to the IETF, resulting in the development of Application Layer Protocol Negotiation (ALPN). ALPN is now the recommended protocol for HTTP/2, while SPDY clients and servers continue to utilize NPN.

The initial prevalence of NPN and the extended standardization process for ALPN led many early HTTP/2 clients and servers to implement both extensions when negotiating HTTP/2. Furthermore, as NPN is used for SPDY and many servers support both SPDY and HTTP/2, the implementation of both NPN and ALPN on such servers is logically consistent.

ALPN differs from NPN primarily in the mechanism used to determine the negotiated protocol. With ALPN, the client presents the server with an ordered list of preferred protocols, and the server selects the protocol it will use, whereas with NPN, the client retains the final selection.

HTTP/2 Negotiation over Plain-Text HTTP

As previously noted, when using plain-text HTTP/1.1, the mechanism for negotiating HTTP/2 involves presenting the server with an Upgrade: header. If the server supports HTTP/2, it responds with a "101 Switching Protocols" status, and the connection then operates using HTTP/2. This upgrade procedure, while requiring an additional network round-trip, is offset by the enhanced possibility of maintaining persistent HTTP/2 connections for greater reuse than typical HTTP/1.1 connections.

While some browser developers have indicated that they will not implement this method of negotiating HTTP/2, the Internet Explorer team once expressed their intent to support it, although this feature was never implemented. The curl utility and a few other non-browser clients do support clear-text HTTP/2.

Currently, no major web browser supports HTTP/2 without TLS.

The HTTP/2 Protocol: A Detailed Examination

With sufficient background established, including the historical context and the political considerations that have led to the current state, we shall now proceed to a detailed examination of the HTTP/2 protocol. This examination will encompass the specific technical elements and concepts that constitute its framework.

Binary Framing in HTTP/2

HTTP/2 is a binary protocol.

This decision warrants a moment of consideration. Those with prior experience in internet protocols might instinctively react negatively to this choice, citing arguments in favor of text-based protocols, particularly their human-readable nature, which allows for manual request crafting using tools like Telnet.

However, HTTP/2 employs a binary format to simplify framing. Determining the start and end of frames poses a considerable challenge in HTTP/1.1 and, indeed, in text-based protocols generally. By eliminating optional whitespace and multiple ways of representing the same data, implementation complexity is significantly reduced.

Furthermore, this binary structure facilitates a cleaner separation of the protocol's core components from the framing, an aspect that is confusingly intermixed in HTTP/1.1.

The inherent compression of HTTP/2, along with its frequent use over TLS, diminishes the utility of text-based protocols since the data is not likely to be transmitted in plaintext. We must, therefore, adapt to using tools such as Wireshark's inspector for accurate protocol-level analysis of HTTP/2.

Debugging of this protocol will likely require specialized tools like curl or network stream analysis via Wireshark's HTTP/2 dissector and comparable utilities.

The Binary Frame Structure

maintained on the HTTP/2 website.

A significant number of implementations were developed early in the process, and this number has steadily increased throughout the HTTP/2 development effort. At the time of writing, there are over 40 implementations listed, with the majority conforming to the final specification.

HTTP/2 Support in Web Browsers

Firefox has consistently been at the forefront in supporting early drafts of the HTTP/2 protocol. Twitter has also actively adopted HTTP/2, providing its services through the protocol. Google initiated HTTP/2 support in April 2014 on a limited number of test servers and, as of May 2014, integrated HTTP/2 support into its development versions of Chrome. Microsoft has demonstrated a technical preview with HTTP/2 support for its next version of Internet Explorer. Both Safari (with iOS 9 and Mac OS X El Capitan) and Opera have also announced their intention to support HTTP/2.

HTTP/2 Support in Web Servers

There is already a significant number of server implementations of HTTP/2 available.

The popular Nginx server has included HTTP/2 support since version 1.9.5, released on September 22, 2015. This implementation replaces the SPDY module, preventing them from being used concurrently within the same server instance.

Apache's httpd server has offered HTTP/2 support through the mod_http2 module since version 2.4.17, released on October 9, 2015.

Furthermore, H2O, Apache Traffic Server, nghttp2, Caddy, and LiteSpeed have all released HTTP/2 capable servers.

Other HTTP/2 Implementations and Tools

curl and libcurl support both insecure and TLS-based HTTP/2 connections, utilizing a variety of different TLS libraries.

Wireshark also provides support for HTTP/2, making it an ideal tool for analyzing HTTP/2 network traffic.

Common Criticisms of HTTP/2

Throughout the development of this protocol, there has been considerable debate, and some stakeholders believe that the final specification is fundamentally flawed. I will now present some of the more common criticisms, along with the counterarguments that have been made against them.

Google's Alleged Influence on HTTP/2 Development

A common criticism is that HTTP/2 is designed or controlled by Google, with some variations of this assertion implying that the protocol makes the internet further dependent on or controlled by Google. This is inaccurate. The protocol was developed within the IETF, adhering to the established procedures that have been utilized for over 30 years. However, it is essential to recognize and acknowledge Google's significant contribution through SPDY, which not only demonstrated the feasibility of deploying a new protocol but also provided quantitative data that illustrated the potential performance gains.

In a public announcement, Google stated their intention to remove support for SPDY and NPN from Chrome in 2016, advocating for a migration of servers to HTTP/2 instead. In February 2016, they further announced that SPDY and NPN would be definitively removed in Chrome 51. Consequently, Chrome versions since 51 have been released without SPDY and NPN support.

HTTP/2's Limited Utility Beyond Browsers

There is some validity to the argument that HTTP/2's benefits are primarily geared toward web browsers. A key motivation for the development of HTTP/2 was the resolution of issues related to HTTP pipelining. If a particular use case does not inherently require pipelining, then the adoption of HTTP/2 may not result in significant advantages. While pipelining is not the only improvement within the protocol, it is a notable one.

However, as services start to fully realize the capabilities offered by multiplexed streams over a single connection, it is likely that we will see increased application of HTTP/2 beyond the browser.

Small REST APIs and other simple programmatic uses of HTTP/1.x may not find the transition to HTTP/2 to be particularly advantageous, yet the implementation of HTTP/2 should present minimal disadvantages for most users.

HTTP/2's Alleged Exclusivity for Large Sites

This assertion is inaccurate. The multiplexing capabilities of HTTP/2 are designed to significantly enhance the user experience on high-latency connections, which are frequently encountered with smaller sites that lack broad geographical distribution. In contrast, larger sites often already benefit from greater speed and distribution, which lead to shorter round-trip times for users.

The Binary Nature of HTTP/2 is Unacceptable

It is acknowledged that the human-readable nature of text-based protocols is advantageous for debugging and tracing purposes. However, text-based protocols are also more susceptible to errors, posing greater challenges for parsing and introducing potential parsing issues. Furthermore, binary protocols are designed to be universally accessible across various programming languages, not solely English.

The concern surrounding the binary nature of HTTP/2 is somewhat mitigated by the fact that the prevalence of TLS and compression in HTTP/1.x already obscures the underlying text format, yet they have been extensively used for many years.

Looking Beyond HTTP/2

The development of HTTP/2 involved numerous difficult decisions and compromises. With HTTP/2 deployment underway, a formal mechanism for transitioning to subsequent protocol versions has been established, laying a foundation for future protocol revisions. This also introduces the framework and infrastructure necessary to handle multiple versions concurrently. Perhaps it is no longer necessary to entirely phase out older versions when introducing new ones?

HTTP/2, however, still retains a significant amount of HTTP/1 "legacy" in order to enable seamless proxying of traffic between HTTP/1.1 and HTTP/2. Some of this legacy may impede further development and innovation. Perhaps HTTP/3 could remove some of these constraints?

In your opinion, what key features are still lacking in HTTP?

Introduction to HTTP/3

QUIC is no longer considered an acronym; it is now established as the name of a transport protocol that operates over UDP. This protocol is documented across four specifications: RFC 8999 through RFC 9002. HTTP/3 is the next iteration of the HTTP protocol currently under development, designed to operate on top of the QUIC protocol.

Personal Opinions

While the majority of websites continue to operate on HTTP/1.1, development of HTTP/3, a subsequent generation, is already underway. It is also evident that many web developers and websites are not actively pursuing a transition to HTTP/2 or HTTP/3. This partly explains the continued popularity of services such as Cloudflare.