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.

Latency Sensitivity

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,) no-repeat;
}

.icon2 {
   background: url(data:image/png;base64,) 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.

Updating HTTP

It would be advantageous to develop an improved protocol that:

• Exhibits reduced latency sensitivity
• Resolves pipelining issues and the head-of-line blocking problem
• Eliminates the need to continually increase the number of connections to each host
• Retains all existing interfaces, content, URI formats, and schemes
• Is developed within the IETF's HTTPbis working group

The Internet Engineering Task Force (IETF) and HTTPbis

The Internet Engineering Task Force (IETF) is an organization responsible for developing and promoting internet standards, primarily at the protocol level. They are widely recognized for the Request for Comments (RFC) series of documents that detail various protocols, such as TCP, DNS, and FTP, as well as best practices, HTTP, and numerous protocol variants, some of which have not seen widespread adoption.

Within the IETF, dedicated "working groups" are established with specific scopes and objectives. These groups define a "charter" outlining guidelines and limitations for their deliverables. Participation in discussions and development is open to everyone, and all contributions are weighted equally, irrespective of an individual's company affiliation.

The HTTPbis working group (the name of which will be explained later) was formed in the summer of 2007 with the aim of updating the HTTP 1.1 specification. It was within this group that discussions concerning a next-generation HTTP protocol truly commenced in late 2012. The HTTP 1.1 update was finalized in early 2014, resulting in the RFC 7230 series.

The concluding interoperability meeting for the HTTPbis working group took place in New York City in early June 2014. Subsequent discussions and adherence to IETF procedures to finalize the official RFC extended into the following year.

Notably, certain prominent entities within the HTTP field have been absent from working group discussions and meetings. While I will refrain from mentioning specific company or product names, it is apparent that some stakeholders in the current Internet ecosystem are confident that the IETF can achieve success without their direct involvement.

Origin of "bis" in HTTPbis

The working group is designated HTTPbis, with the suffix "bis" originating from the Latin adverb for "two." Within the IETF, "bis" is commonly used as a suffix or part of a name to denote an update or a second iteration of a specification; in this particular case, it signifies the update to HTTP 1.1.

HTTP/2's Origins in SPDY

SPDY 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

HTTP/2 transmits data using binary frames. Various frame types are defined, each sharing a common structure comprising: Length, Type, Flags, Stream Identifier, and a frame payload.

The HTTP/2 specification defines ten distinct frame types, with the DATA and HEADERS frames being the most fundamental in their mapping to HTTP/1.1 features. Further details on some of these frame types will be provided subsequently.

Multiplexed Streams in HTTP/2

The Stream Identifier, introduced in the preceding section, associates each frame transmitted over HTTP/2 with a specific "stream." A stream is defined as an independent, bidirectional sequence of frames exchanged between the client and server within a single HTTP/2 connection.

A single HTTP/2 connection can support multiple concurrently open streams, enabling either endpoint to interleave frames from different streams. Streams can be initiated and utilized unilaterally or shared between the client and server, and they can be terminated by either endpoint. The order in which frames are transmitted within a stream is significant, as recipients process frames according to their reception sequence.

Multiplexing streams involves intermixing data packets from multiple streams over a single connection. Two or more independent data sequences are combined into a single stream and then separated at the receiving end.

Stream Priorities and Dependencies

Each stream in HTTP/2 is assigned a priority, also referred to as a "weight," which informs the peer about the relative importance of the stream. This enables a server, in the event of resource constraints, to prioritize the transmission order of streams.

Through the use of the PRIORITY frame, a client can also declare a dependency between one stream and another. This mechanism allows for the construction of a hierarchical priority structure, wherein multiple "child streams" may depend on the completion of designated "parent streams."

These priority weights and dependencies can be dynamically modified at runtime. This allows browsers to specify the relative importance of resources, for example, when users scroll down a page containing numerous images. In this case, the browser can prioritize the download of images currently in view or when switching tabs, a browser can shift focus to a new set of streams that have become active.

Header Compression in HTTP/2

HTTP is fundamentally a stateless protocol. This inherent characteristic necessitates that each request contain all the requisite details for the server to process that request, without relying on stored information or metadata from prior requests. As HTTP/2 maintains this paradigm, it operates under the same constraint.

This stateless nature leads to a degree of redundancy. When a client requests multiple resources from the same server, as is typical with web page images, a series of almost identical requests is generated. Such repetition suggests that compression could be beneficial.

The increase in the number of objects per web page has been accompanied by a corresponding growth in the size of HTTP requests, driven by factors such as cookie usage. These cookies must also be transmitted in each request, further exacerbating this redundancy.

The size of HTTP/1.1 requests has become so considerable that they now frequently exceed the initial TCP window, leading to slow transmission due to the requirement of a full round-trip before the complete request can be sent. This provides a further justification for implementing header compression.

The Complexities of Compression

HTTPS and SPDY compression have been shown to be vulnerable to BREACH and CRIME attacks. By injecting known text into the data stream and analyzing the corresponding changes in the output, an attacker can potentially ascertain the contents of an encrypted payload.

Implementing compression for dynamic content within a protocol—without becoming susceptible to these types of attacks—requires careful planning and meticulous execution. This was a central concern for the HTTPbis team.

The solution they devised is HPACK, Header Compression for HTTP/2, which, as its name suggests, is a compression format specifically designed for HTTP/2 headers. HPACK is being specified in a separate Internet-Draft. This new format, combined with several other countermeasures (such as a bit that prohibits intermediaries from compressing specific headers and optional frame padding), is intended to increase the difficulty of exploiting compression vulnerabilities.

Stream Resets in HTTP/2

A notable limitation of HTTP/1.1 is the difficulty in terminating an HTTP message once it has been transmitted with a specified Content-Length. While it is often possible to terminate the underlying TCP connection, this incurs the overhead of renegotiating a new TCP handshake.

A more efficient solution is to simply terminate the message and initiate a new transmission. This functionality is provided by HTTP/2's RST_STREAM frame, which helps conserve bandwidth and eliminate the need to tear down and re-establish connections.

Server Push Mechanism

This feature, also known as "cache push," enables a server to proactively transmit resources to a client that are likely to be requested. If a client requests resource X, the server may anticipate a subsequent request for resource Z and preemptively sends resource Z to the client without it being explicitly requested. This expedites client performance by placing resource Z into its cache, ensuring its availability when needed.

Server push is a mechanism that clients must explicitly authorize. Even with such authorization, clients retain the ability to promptly terminate any pushed stream using the RST_STREAM frame should a particular resource not be desired.

Flow Control Mechanisms in HTTP/2

In HTTP/2, each individual stream has its own advertised flow control window that specifies the amount of data the peer is authorized to transmit. This mechanism exhibits similarities in style and function to flow control in SSH.

For every stream, both endpoints must inform their peer of the available buffer space for incoming data. The peer is then restricted from transmitting more data than the advertised window size until the flow window is extended. It is important to note that flow control applies exclusively to DATA frames.

Envisioning an HTTP/2 Environment

As HTTP/2 gains adoption, what will the implications be? And indeed, will it achieve widespread adoption?

Impact of HTTP/2 on User Experience

HTTP/2 is not yet widely deployed, and as such, the precise outcomes of its implementation remain uncertain. However, drawing upon our observations of SPDY and extrapolating from past and ongoing experiments, we can reasonably speculate about its potential impact.

HTTP/2 is designed to minimize the number of necessary network round-trips, and through multiplexing and rapid stream termination, it completely circumvents the head-of-line blocking issue.

It facilitates a large number of parallel streams that exceeds the capabilities of even the most aggressively sharded websites currently in use.

With the proper application of stream prioritization, it is more likely that clients will receive critical data before less-important data. Consequently, it is anticipated that this will lead to faster page load times and more responsive websites, ultimately providing an enhanced web experience.

While the magnitude of these improvements is still indeterminate, it is important to note that HTTP/2 is still an emerging technology. Furthermore, we have yet to witness clients and servers optimized to fully exploit the capabilities offered by this new protocol.

Implications of HTTP/2 for Web Development

Over time, web developers and development environments have amassed an extensive array of techniques and tools designed to mitigate the limitations of HTTP/1.1. As previously outlined, some of these workarounds were, in fact, a justification for the development of HTTP/2.

It is anticipated that many of these workarounds, which are now used routinely and often without conscious consideration, will either impede HTTP/2 performance or, at the very least, fail to leverage its advanced capabilities. Specifically, techniques like image spriting and inlining are likely to be counterproductive in HTTP/2, and sharding may be detrimental, as HTTP/2 is designed to benefit from fewer, more efficient connections.

A significant challenge is that web developers must create and deploy websites that serve both HTTP/1.1 and HTTP/2 clients, at least in the near term. Optimizing performance for all users can prove difficult without the maintenance of two distinct front-end implementations.

For these reasons, it is likely that some time will pass before the full potential of HTTP/2 is realized.

HTTP/2 Implementations

Attempting to document specific implementations in a text such as this is inherently impractical and will invariably become outdated very quickly. Therefore, instead of detailing specific implementations, I will provide a general overview of the situation and direct readers to the list of implementations 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.