HTTP Series - Part-2: HTTP/2.0

Continuing our journey of the HTTP series, the previous part explored into the progression of HTTP leading up to HTTP/1.1. In this segment, we will begin by examining certain limitations of HTTP/1.1, and subsequently, delve into the intricacies of HTTP/2.0, which looks to overcome these limitations.

Limitations of HTTP/1.1 that lead to HTTP/2.0:

• Head-of-Line Blocking:
• In HTTP/1.1, multiple HTTP requests are transmitted over a single TCP connection. However, the caveat is that they are sent sequentially. In other words, the next HTTP request cannot be sent until the response to the current HTTP request is received.
• If getting one of the resources is delayed, subsequent resources are also blocked, even if they are independent and could be fetched more quickly.

• Limited Multiplexing:
• The sequential execution of HTTP requests over a TCP connection introduces latency, especially when fetching numerous resources. To mitigate this, modern browsers employ a workaround, allowing a maximum of 6 distinct TCP connections. This enables parallel fetching of resources through these connections, improving overall performance.
• Nevertheless, given the substantial load current browsers handle, even this limit of 6 connections has proven insufficient.
• Please be aware that each TCP connection can still process multiple HTTP requests sequentially. The distinction lies in the fact that, instead of relying on a single TCP connection between the browser and server, we now have six TCP connections in parallel.

• Header Overhead:
• Each HTTP request and response carries headers containing metadata. In HTTP/1.1, headers are sent with every request and response, contributing to increased data overhead.
• A webpage fetching multiple resources results in redundant transmission of headers in each HTTP call, consuming additional bandwidth.
• While HTTP/1.1 does provide data compression, there remains a notable amount of redundant header data, particularly when many headers are supported in HTTP/1.1.

HTTP/2.0:

HTTP/2.0 (RFC-7540) was developed to address some limitations and challenges posed by the earlier version. Some of its key features are:

• Multiplexing:
• HTTP/2.0 achieves multiplexing by allowing multiple streams of data to be sent and received concurrently over a single TCP connection. This is a significant improvement over HTTP/1.1, where multiple parallel connections were needed for concurrency.

• In HTTP/2.0, communication is divided into multiple independent streams, each carrying its own set of requests and responses. A stream represents a unidirectional flow of data within the connection
• The data within each stream is transmitted in small units called frames. HTTP/2.0 defines different types of frames for various purposes, such as headers, data, settings, etc.
• Each stream is assigned a unique identifier, known as the "stream identifier." The stream identifier is included in the header of each frame. Each concurrent request is identified by this stream identifier. This helps the server to return the response for each request on the associated stream identifier.
• The stream identifier is an internal field and is not seen by the client/users of HTTP/2.0.
• Because multiple streams can exist within a single connection, requests and responses can be interleaved and processed concurrently. This enables more efficient use of the available network resources.
• Each stream has its own flow control window, which helps regulate the amount of data that can be sent before receiving an acknowledgment.
• HTTP/2.0 introduces a mechanism for prioritizing streams as well. This allows the server and client to prioritize the delivery of critical resources.
• Single Connection to handle concurrent requests:
• HTTP/2.0 enables multiple concurrent requests and responses over a single connection.
• Header Compression:
• With multiple streams, requests and responses can be interleaved and processed concurrently in a single TCP connection. This helps to compress the header data as well, especially when there are repeated headers across requests and responses.
• Binary Protocol:
• HTTP/2.0 uses a binary protocol instead of plain text, making it more compact and easier to parse. It reduces parsing complexity and contributes to faster data transmission.
• Backward Compatible:
• HTTP/2.0 is designed to be backward compatible with HTTP/1.1.
• It helps in a smooth transition for existing websites, allowing gradual adoption of HTTP/2.0 features.

Limitaions of HTTP/2.0:

• HTTP/2.0 uses a single connection for multiple streams, and dependencies between streams can impact overall performance. If a stream is blocked, it might affect other dependent streams. It means head-of-line blocking can still occur in HTTP/2.0.
• Implementing and debugging HTTP/2.0 can be more complex compared to HTTP/1.1 due to its framing layer and the use of header compression. This complexity may pose challenges for developers. It might not be worth the effort to transition from HTTP/1.1 for smaller websites with limited resources.
• Using a single, persistent connection for multiple streams may lead to increased resource usage on servers and clients. Servers might need to handle more concurrent connections.
• While HTTP/2.0 is designed to be backward-compatible with HTTP/1.1, some network intermediaries may not fully support or correctly handle the new protocol. This can lead to compatibility issues.