RFC 7540

RFC 7540 is the specification that defines HTTP/2, a major revision of the Hypertext Transfer Protocol used for communication on the World Wide Web. Published in May 2015 by the Internet Engineering Task Force, it was developed to address performance limitations inherent in the previous HTTP/1.1 standard. The protocol introduces a binary framing layer, multiplexing, and header compression to reduce latency and improve the efficiency of web communications.

● Overview

RFC 7540 was developed by the HTTP Working Group of the Internet Engineering Task Force, building upon the earlier experimental SPDY protocol developed by Google. The primary goal was to maintain the high-level semantics of HTTP/1.1—such as HTTP methods, status codes, and URIs—while fundamentally changing how data is formatted and transported between clients and servers. This revision was driven by the increasing complexity of modern web pages and applications, which strained the capabilities of the older protocol. The specification was ratified as a Proposed Standard and has since progressed to Internet Standard.

● Technical specifications

At its core, RFC 7540 replaces the text-based message formatting of HTTP/1.1 with a binary protocol. Communication occurs over a single TCP connection using streams, which are independent, bidirectional sequences of frames. The specification defines several frame types, including HEADERS, DATA, and SETTINGS, which carry different aspects of the HTTP exchange. A critical component is the use of HPACK, a specialized compression format for HTTP header fields that reduces overhead. The protocol also mandates the use of TLS for all HTTP/2 connections in web browsers, though the RFC itself defines both encrypted and cleartext versions.

● Key features

The multiplexing capability allows multiple request and response messages to be interleaved and processed concurrently on one connection, eliminating head-of-line blocking at the HTTP layer. Server push enables a server to proactively send anticipated resources to a client's cache before they are explicitly requested. The binary framing layer makes parsing more efficient and less error-prone compared to text-based protocols. Flow control and stream prioritization mechanisms, similar to those in SPDY, allow administrators to manage resource allocation and ensure critical resources are delivered first. These features collectively aim to make more efficient use of network bandwidth and reduce page load times.

● Differences from HTTP/1.1

Unlike HTTP/1.1, which relies on multiple TCP connections and plain-text headers, HTTP/2 uses a single connection with binary, compressed frames. The older protocol is susceptible to head-of-line blocking, where a slow request delays others on the same connection, an issue largely mitigated in the new specification. While HTTP/1.1 requires explicit client requests for all resources, HTTP/2's server push can anticipate needs. The methods, status codes, and semantics from RFC 7230 are preserved, ensuring compatibility at the application layer, but the underlying transport mechanism is entirely redesigned for performance.

● Implementation and adoption

Major web servers and clients quickly adopted the standard, with early implementations appearing in Apache HTTP Server, nginx, and Microsoft IIS. Browser support was led by Google Chrome, Mozilla Firefox, and Microsoft Edge, which enabled HTTP/2 by default. The Cloudflare and Akamai content delivery networks played a significant role in accelerating adoption by offering the protocol to their customers. As of the mid-2020s, a large majority of websites support HTTP/2, making it the dominant version of the protocol on the Internet. The transition was facilitated by the protocol's ability to be negotiated during the TLS handshake using the Application-Layer Protocol Negotiation extension.

● Security considerations

RFC 7540 emphasizes the importance of TLS, and the major browser vendors only implement the encrypted version. The specification discusses potential attack vectors such as compression oracle attacks related to HPACK and advises on mitigations. It also warns about the risks of naive server push implementations overwhelming client resources. The extended use of a single TCP connection can increase the impact of congestion control issues and requires careful management of flow control settings. Overall, while the protocol introduces new complexities, it is designed to be no less secure than HTTP/1.1 when used over TLS.

Category:Internet standards Category:Internet protocols Category:World Wide Web Consortium standards