Overview Of HTTP/2 Protocol

HTTP/2

HTTP was originally proposed by Tim Berners-Lee, the pioneer of the World Wide Web who designed the application protocol with simplicity in mind to perform high-level data communication functions between Web-servers and clients.

The first documented version of HTTP was released in 1991 as HTTP0.9, which later led to the official introduction and recognition of HTTP1.0 in 1996. HTTP1.1 followed in 1997 and has since received little iterative improvements.

In February 2015, the Internet Engineering Task Force (IETF) HTTP Working Group revised HTTP and developed the second major version of the application protocol in the form of HTTP/2. In May 2015, the HTTP/2 implementation specification was officially standardized in response to Google’s HTTP-compatible SPDY protocol.

Why do we need HTTP/2?

In the early days, bandwidth was the limiting factor. But today, the average internet user in the US has a bandwidth of 11Mbit/s
Latency is the new bandwidth. End users will not worry about the bandwidth as long as they get better responsive applications.

HTTP 0.9 - Initial version of the protocol was introduced in 1991. Required a new TCP connection per request. Only the GET method is supported.

HTTP 1.0 - Improved version with POST, HEAD methods for transferring more rich content. New header fields are introduced to identify the request (ex: Content-Length). Still uses a connection per request.

HTTP1.1 - New methods like PUSH, DELETE, and OPTIONS are added. Keep alive (persistent) connections became the default. Improved latency.

HTTP 1.1 Challenges

When loading web pages with multiple resources, browsers will send parallel requests to reduce the latency. But this needs more resources since it needs to create new connections and latency will be affected, even though there are hacks like HTTP pipelining by sending multiple requests through the same TCP connection asynchronously. But in this case, the server will respond synchronously and reduce the latency and block the application if one of the resources slows down to respond.

How HTTP/2 addresses the challenges of HTTP/1.1

The major design goals of the HTTP/2 protocol were to address the issues which were present in the HTTP/1.1 protocol.

Reduce the latency
Reduce the total number of open sockets (TCP connections)
Maintain high-level compatibility with HTTP/1.1

In addition to addressing these challenges, HTTP/2 has introduced several new features which were not there in the HTTP/1.1 and will improve the performance of the web.

What is new in HTTP/2

Multiplexing
Multiple requests can be sent over a single TCP connection asynchronously.

This approach presents an array of benefits of HTTP/2 explained below:

The parallel multiplexed requests and response do not block each other.
A single TCP connection is used to ensure effective network resource utilization despite transmitting multiple data streams.
No need to apply unnecessary optimization hacks – such as image sprites, concatenation, and domain sharding, among others – that compromise other areas of network performance.
Reduced latency, faster web performance, better search engine rankings.
Reduced OpEx and CapEx in running network and IT resources.

Server Push
The server can asynchronously send resources to the client's cache for future use.

HTTP/2 implementation presents a significant performance for pushed resources, with other benefits of HTTP/2 explained below,

The client saves pushed resources in the cache.
The client can reuse these cached resources across different pages.
The server can multiplex pushed resources along with originally requested information within the same TCP connection.
The server can prioritize pushed resources – a key performance differentiator in HTTP/2 vs HTTP1.
The client can decline pushed resources to maintain an effective repository of cached resources or disable Server Push entirely.
The client can also limit the number of pushed streams multiplexed concurrently.

Header compression
Clients will not need to send the same headers for each and every request. Only the new headers need to be sent. It uses the HPACK specification as a simple and secure approach to header compression.

HPACK header compression for HTTP/2 implementation presents immense performance advantages, including some benefits of HTTP/2, explained below,

Effective stream prioritization.
Effective utilization of multiplexing mechanisms.
Reduced resource overhead – one of the earliest areas of concerns in debates on HTTP/2 vs HTTP1 and HTTP/2 vs SPDY.
Encodes large headers as well as commonly used headers which eliminate the need to send the entire header frame itself. The individual transfer size of each data stream shrinks rapidly.
Not vulnerable to security attacks such as CRIME exploiting data streams with compressed headers.

Request prioritization
Some requests can have more memory, CPU, bandwidth in the same TCP connection,

An intelligent and widely adopted stream prioritization mechanism presents benefits of HTTP/2 explained as follows,

Effective network resource utilization.
Reduced time to deliver primary content requests.
Improved page load speed and end-user experience.
Optimized data communication between client and server.
Reduced negative effect of network latency concerns.

Binary protocol
Data will be transmitted as binary frames. Not as text form in the HTTP/1.1.

Using binary commands to enable key business advantages for internet companies and online business as detailed with the benefits of HTTP/2 explained below:

Low overhead in parsing data – a critical value proposition in HTTP/2 vs HTTP1.
Less prone to errors.
Lighter network footprint.
Effective network resource utilization.
Eliminating security concerns associated with the textual nature of HTTP1.x such as response splitting attacks.
Enables other capabilities of the HTTP/2 including compression, multiplexing, prioritization, flow control and effective handling of TLS.
Compact representation of commands for easier processing and implementation.
Efficient and robust in terms of processing of data between client and server.
Reduced network latency and improved throughput.

Similarities with HTTP1.x and SPDY

Underlying application semantics of HTTP including HTTP status codes, URIs, methodologies, and header files remain the same in the latest iteration of the HTTP/2. HTTP/2 is based on SPDY; Google’s alternative to HTTP1.x. Real differences lie in the mechanisms used to process client-server requests. The following chart identifies a few areas of similarities and improvements among HTTP1.x, SPDY, and HTTP/2,

HTTP1.x	SPDY	HTTP2
SSL not required but recommended.	SSL required.	SSL not required but recommended.
Slow encryption.	Fast encryption.	Even faster encryption.
One client-server request per TCP connection.	Multiple client-server requests per TCP connection. Occurs on a single host at a time.	Multi-host multiplexing. Occurs on multiple hosts at a single instant.
No header compression.	Header compression introduced.	Header compression using improved algorithms that improve performance as well as security.
No stream prioritization.	Stream prioritization introduced.	Improved stream prioritization mechanisms used

How do I use HTTP/2?

Almost all browsers already support HTTP/2 in their most current release, and current data shows that over 50% of users are on HTTP/2-capable browsers already. On the server, IIS running on Windows 10 or Windows Server 2016 supports HTTP/2. IIS currently supports HTTP/2 only over TLS. When making an HTTPS connection to a web server running IIS on Windows 10, HTTP/2 is used if the client and server both support it.

Follow these simple steps to set up HTTP/2 for your website.

Step 1

Ensure HTTPS is enabled: Purchase an SSL or TLS certificate from a valid issuing authority or utilize free SSL from Let’s Encrypt if available.
Activate the security certificate.
Install the Certificate.
Update the website to enable the HTTPS protocol.

Step 2

Make sure the underlying network infrastructure including server software support HTTP/2. Nginx servers support HTTP/2 natively whereas Apache added native support in October 2015 (in 2.4) which means apache servers might require additional modules to enable data communication using HTTP/2 browser support.

Step 3

Update, configure and test your servers to support HTTP/2.